Primäre Ursache für den in der Frage dargestellten Fehler ist, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, mehrere Zeichen verwendet, die nicht von der US-ASCII-Codierung abgedeckt sind. Bei Paketen wird ausdrücklich empfohlen, dies nicht zu tun. Je nach verwendeter Eingabecodierung können diese Zeichen gültig oder auch ungültig sein. So verschwindet besagte Fehlermeldung beispielsweise, wenn man vor `gmeometric` das Paket `inputenc` mit Option `latin1` lädt. Allerdings gibt es dann die Fehlermeldung: /usr/local/texlive/2013/texmf-dist/tex/latex/gmutils/gmbase.sty:2328: Undefined control sequence. \GenericError ... #4 \errhelp \@err@ ... l.2328 } % of |\@whilenum| und das gleich so oft, dass `pdflatex` mit einer *»Fatal error occured«*-Meldung abbricht. Und bereits das folgende [VM](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses): \documentclass{article} \usepackage[latin1]{inputenc} \usepackage{gmbase} \begin{document} \end{document} liefert denselben Fehler. Daraus schließe ich, dass mehrere von `gmeometric` verwendete Pakete Fehler bzw. Abhängigkeiten von der Eingabecodierung aufweisen, die deren Verwendung nicht ratsam erscheinen lässt. Das gilt dann natürlich auch für Pakete, die darauf aufbauen. Darüber hinaus unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, beispielsweise `\GM@checkbool`, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Das Paket `gmeometric` kann also mit `geometry` ab Version 5.0 gar nicht mehr funktionieren. Daher muss von der Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 dringend abgeraten werden! Leider unterstützt `geometry` selbst nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Primäre Ursache für den in der Frage dargestellten Fehler ist, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, mehrere Zeichen verwendet, die nicht von der US-ASCII-Codierung abgedeckt sind. Bei Paketen wird ausdrücklich empfohlen, dies nicht zu tun. Je nach verwendeter Eingabecodierung können diese Zeichen gültig oder auch ungültig sein. So verschwindet besagte Fehlermeldung beispielsweise, wenn man vor `gmeometric` das Paket `inputenc` mit Option `latin1` lädt. Allerdings gibt es dann die Fehlermeldung: /usr/local/texlive/2013/texmf-dist/tex/latex/gmutils/gmbase.sty:2328: Undefined control sequence. \GenericError ... #4 \errhelp \@err@ ... l.2328 } % of |\@whilenum| und das gleich so oft, dass `pdflatex` mit einer *»Fatal error occured»*-Meldung abbricht. occured«*-Meldung abbricht. Und bereits das folgende [VM](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses): \documentclass{article} \usepackage[latin1]{inputenc} \usepackage{gmbase} \begin{document} \end{document} liefert denselben Fehler. Daraus schließe ich, dass mehrere von `gmeometric` verwendete Pakete Fehler aufweisen, die deren Verwendung nicht ratsam erscheinen lässt. Das gilt dann natürlich auch für Pakete, die darauf aufbauen. Darüber hinaus unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, beispielsweise `\GM@checkbool`, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Das Paket `gmeometric` kann also mit `geometry` ab Version 5.0 gar nicht mehr funktionieren. Daher kann die muss von der Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. dringend abgeraten werden! Leider unterstützt `geometry` selbst nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. Aufgrund der geschilderten Probleme sollte besser man weder das Paket `gmcommand` noch ein darauf aufbauendes Paket verwenden. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Primäre Ursache für den in der Frage dargestellten Fehler ist, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, mehrere Zeichen verwendet, die nicht von der US-ASCII-Codierung abgedeckt sind, wie sind. Bei Paketen wird ausdrücklich empfohlen, dies für Pakete der Fall sein sollte. nicht zu tun. Je nach verwendeter Eingabecodierung können diese Zeichen gültig oder auch ungültig sein. So verschwindet besagte Fehlermeldung beispielsweise, wenn man vor `gmeometric` das Paket `inputenc` mit Option `latin1` lädt. Allerdings gibt es dann die Fehlermeldung: /usr/local/texlive/2013/texmf-dist/tex/latex/gmutils/gmbase.sty:2328: Undefined control sequence. \GenericError ... #4 \errhelp \@err@ ... l.2328 } % of |\@whilenum| und das gleich so oft, dass `pdflatex` mit einer *»Fatal error occured»*-Meldung abbricht. Darüber hinaus unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. Aufgrund der geschilderten Probleme sollte besser man weder das Paket `gmcommand` noch ein darauf aufbauendes Paket verwenden. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Dessen ungeachtet, Primäre Ursache für den in der Frage dargestellten Fehler ist, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, in der aktuellen Version 0.996 vom 12. Oktober 2011 offenbar einen Encoding-Bug hat (in mehreren Zeilen werden Zeichen verwendet, die nicht von der US-ASCII-Codierung abgedeckt sind, wie `Ť` verwendet, die je dies für Pakete der Fall sein sollte. Je nach Encoding verwendeter Eingabecodierung können diese Zeichen gültig oder auch durch mehre Bytes codiert sein können), ungültig sein. So verschwindet besagte Fehlermeldung beispielsweise, wenn man vor `gmeometric` das Paket `inputenc` mit Option `latin1` lädt. Allerdings gibt es dann die Fehlermeldung: /usr/local/texlive/2013/texmf-dist/tex/latex/gmutils/gmbase.sty:2328: Undefined control sequence. \GenericError ... #4 \errhelp \@err@ ... l.2328 } % of |\@whilenum| und das gleich so oft, dass `pdflatex` mit einer *»Fatal error occured»*-Meldung abbricht. Darüber hinaus unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. Aufgrund der geschilderten Probleme sollte besser man weder das Paket `gmcommand` noch ein darauf aufbauendes Paket verwenden. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometryhttp://www.ctan.org/pkg/geometry

Dessen ungeachtet, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, in der aktuellen Version 0.996 vom 12. Oktober 2011 offenbar einen Encoding-Bug hat (in den mehreren Zeilen 650 und 657 wird ein werden Zeichen wie `Ť` verwendet), verwendet, die je nach Encoding auch durch mehre Bytes codiert sein können), unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Das Dessen ungeachtet, dass das Paket `gmcommand`, das von [`gmeometric`][1] via `gmutils` verwendet wird, in der aktuellen Version 0.996 vom 12. Oktober 2011 offenbar einen Encoding-Bug hat (in den Zeilen 650 und 657 wird ein `Ť` verwendet), unterstützt `gmeometric` in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Das Paket `gmeometric` [`gmeometric`][1] unterstützt in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die `geometry`-Versionen [`geometry`][2]-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird.wird. [1]: http://www.ctan.org/pkg/gmeometry [2]: http://www.ctan.org/pkg/geometry

Das Paket `gmeometric` unterstützt in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die `geometry`-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `\gmeometric` `gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird.

Das Paket `gmeometric` unterstützt in der aktuellen Version 0.73 vom 22. November 2008 laut Anleitung nur die `geometry`-Versionen 3.2 und 4.1. Seit Version 5.0 unterstützt `geometry` mit `\newgeometry` selbst eine Möglichkeit, die Verteilung von Rändern und Satzspiegel auch noch innerhalb des Dokuments zu ändern. Um dies zu ermöglichen, wurde `geometry` erheblich verändert, so dass die internen Makros, auf die sich `\gmeometric` stützt, nicht mehr existieren oder nicht mehr in kompatibler Weise arbeiten. Daher kann die Verwendung von `gmeometric` zusammen mit `geometry` ab Version 5.0 nicht mehr empfohlen werden. Leider unterstützt `geometry` nicht, das Papierformat innerhalb des Dokuments zu ändern. Hier bietet sich als Alternative das KOMA-Script-Paket `typearea` an, wie dies in [meiner Antwort](http://texwelt.de/wissen/fragen/1791/wie-kann-ich-innerhalb-eines-dokuments-seitengroe-und-rand-andern/1811) auf die Frage [»Wie kann ich innerhalb eines Dokuments Seitengröße und Rand ändern?«](http://texwelt.de/wissen/fragen/1791) gezeigt wird.