Häufige Fragen und ihre Antworten#

Es gibt immer wieder Anwender, die der Meinung sind, dass die Voreinstellungen nicht den Benutzererwartungen entsprechen oder aus sonstigen Gründen nicht optimal gewählt wurden. Manche dieser Einwürfe sind dabei durchaus gut begründet.

KOMA-Script wurde, wie in der Einleitung zur Anleitung erwähnt ist, Anfang der 90er Jahre des vorigen Jahrhunderts aus dem LaTeX-2.09-Paket Script 2.0 entwickelt. Zwar hatte ich bereits zu Script 2.0 ein paar Kleinigkeiten beigetragen, insgesamt handelte es sich dabei jedoch um ein Paket von Frank Neukam, der auch alle Design- und Implementierungsentscheidungen traf. Ich selbst traf 1993 die Entscheidung, KOMA-Script möglichst kompatibel zu Script 2.0 zu entwerfen. Das betraf insbesondere auch die Voreinstellungen.

Gleichzeitig musste KOMA-Script bezüglich des Funktionsumfangs erst noch wachsen. 1994 hatte KOMA-Script einen Bruchteil der Möglichkeiten, die es heute bietet. Einige Dinge wurden also erst im Laufe der Zeit möglich. Die Voreinstellung richtete sich dann nach dem, was zuvor fest eingestellt war, also nach dem Zustand vor Einführung der neuen Möglichkeit. Bei Dingen, die zuvor nicht einmal als Festeinstellung vorhanden waren, habe ich mich an den Benutzeranfragen aus dem Support, am Gesamtbild der Voreinstellungen und in Ausnahmefällen auch an fremden Paketen orientiert.

Kompatibilität war mir immer wichtig. Soweit möglich sollte ein Dokument nach Jahren mit der dann aktuellen Version von KOMA-Script noch genauso aussehen, wie mit der Version, mit der es ursprünglich erstellt wurde. Bis Version 3.00 galt hier lediglich die Einschränkung, dass die Kompatibilität nicht die Fehlerbeseitigung und Verbesserung behindern sollte.

Während mein Umfrage zur Kompatibilität eher gegen eine Abkehr von der Kompatibilitätsregel sprechen, habe ich während des Wechsels von KOMA-Script 2.9 zur Quellcode-Basis von KOMA-Script 3.00 festgestellt, dass andere Paketautoren selbst der Kompatibilität wenig Bedeutung beimessen. Mehrere meiner älteren Dokumente wurden teils erheblich neu umbrochen, obwohl ich versuchsweise nicht nur die Kompatibilitätseinstellung version=first, sondern sogar eine alte KOMA-Script-Version verwendet habe. Damit nützt es also in der Realität wenig, wenn KOMA-Script selbst Dokumente sehr kompatibel umbrechen könnte. Man muss zu diesem Zweck ohnehin alle verwendeten Pakete archivieren. In diesem Fall kann natürlich auch KOMA-Script eingeschlossen werden.

Diese Erfahrung kann jedoch nicht bedeuten, dass nun alle Voreinstellungen auf einen Schlag auf den Prüfstand gestellt und generell geändert werden. Einzelne Voreinstellungen wurden aber bereits geändert (beispielsweise der voreingestellte Seitenstil von Vakatseiten). Bei anderen gibt es Überlegungen in diese Richtung.

Übrigens habe ich bereits in den 90er-Jahren des vorigen Jahrhunderts beim Versuch, eine Voreinstellung zu ändern, Schiffbruch erlitten: Weil verschrägte Schriften – in LaTeX \slshape – in der Typografie eher verpönt sind, wollte ich die Kopfzeilenvoreinstellung in kursiv – in LaTeX \itshape – ändern. Die Protestwelle war nach der Release so groß, dass ich die Änderung bereits zur nächsten Release zurückgenommen habe – und damals gab es Releases wesentlich häufiger als heute. Nach dieser Erfahrung überlege ich selbst bei gut begründeten Änderungswünschen zweimal, ob ich diese umsetze.

Trotzdem: Wer einen wohlbegründeten Änderungsvorschlag hat, der kann den im Issue-Tracker gerne als Vorschlag unterbreiten. Nach Möglichkeit sollte man sich aber auch Gedanken über mögliche Nebenwirkungen machen. Dazu gehört auch die Frage, ob der Anwender einfach zur alten Voreinstellung zurückkehren kann. So würde ich beispielsweise kaum die Größe oder Schrift einer einzelnen Überschriftenebene ändern.

Es gibt eine ganze Seite, die sich mit dem Thema vollständiges Minimalbeispiel beschäftigt. Auch die einschlägigen LaTeX-Foren bieten häufig ausführliche Informationen zur Erstellung eines Minimalbeispiels. Beispielsweise ist auf TeXwelt ausführlich erklärt, wie selbst ein Anfänger aus einem Dokument mit einem realen Problem ein vollständiges Minimalbeispiel erstellen kann. Bei aller Mühe, die der Anwender hat, sei daran erinnert, dass so nicht nur die Möglichkeiten zu effektiver Hilfe deutlich verbessert werden, Minimalbeispiele ersparen auch unnötige Diskussionen und Ärger.

Ein vollständiges Minimalbeispiel zu einem LaTeX-LaTeX-Problem ist ein möglichst kleines LaTeX-Dokument, bei dem das entsprechende Problem auftritt bzw. mit dem das Problem verdeutlicht werden kann. Das Attribut vollständig ist dabei wichtig. Eine Dokumentpräambel ist kein vollständiges Beispiel. Eine Hauptdatei, die diverse andere Dateien oder Grafiken lädt ist ohne diese anderen Dateien und Grafiken nicht vollständig. Am besten werden Unterdateien direkt in die Hauptdatei eingefügt. Bei \includegraphics-Anweisungen empfiehlt sich die Verwendung eines der Beispielbilder aus dem Paket mwe. Auch eine Datei, an der erst Änderungen vorgenommen werden müssen, damit man das Problem sieht, sind kein vollständiges Beispiel für das Problem. Zur Vermeidung langer Fülltexte können gerne Pakete wie blindtext oder lipsum verwendet werden. Diese werden von allen LaTeX-Distributionen über deren Paketmanager angeboten. Teilweise kann man Text auch durch \vspace-Anweisungen ersetzen.

Obwohl der Name „vollständiges Minimalbeispiel“ eigentlich impliziert, das es das kleinste LaTeX-Dokument für diesen Zweck ist, relativiere ich dies bewusst. Das kleinste Dokument muss nicht unbedingt auch das beste sein. Auch wird ein weniger versierter Anfänger eventuell bei optimaler Anstrengung nicht unbedingt das kleinst mögliche Dokument finden, das dieses Problem zeigt. Er sollte sich dennoch um ein möglichst kleines LaTeX-Dokument bemühen.

Mir ist wichtig, dass ich mit dem Minimalbeispiel arbeiten kann, ohne mir um Dutzende unerheblicher Definitionen und Pakete Gedanken machen zu müssen. Ich mag es auch, wenn mir jemand bei einer Frage, die scheinbar nicht an einem Minimalbeispiel gezeigt werden kann, ein solches mitliefert. Ich kann dann genau an diesem Beispiel meine eigenen Tests vornehmen und das Beispiel für meine Lösungsvorschläge verwenden. An einem Minimalbeispiel kann ich oft auch erkennen, wie fortgeschritten der Anwender ist, wie ausführlich ich also bei Antworten sein sollte. Gerade Anfänger haben oft Probleme, für die eine Frage dann nur ein Symptom zeigt. Mit einem Minimalbeispiel kann ich das eventuell erkennen und so wesentlich bessere Hilfe leisten. Kein Minimalbeispiel, bedeutet für mich, dass der Anwender auch nur eine minimale Antwort benötigt.

Im Endeffekt signalisiert mir ein Minimalbeispiel, dass eine Frage wichtig ist, und ermöglicht mir gleichzeitig, meine best mögliche Antwort zu geben. Ohne Minimalbeispiel lautet meine best mögliche Antwort eventuell nur „verstehe ich nicht, kann ich so nicht beantworten.“ Das gilt ebenso, wenn sich der Fragesteller erkennbar wenig Mühe mit dem Minimalbeispiel gegeben hat oder in unübersichtlicher Weise mehrere Probleme schwer erkennbar in einem Beispiel miteinander vermischt wurden. Nach Möglichkeit sollte jedes einzelne Problem in einem einzelnen Minimalbeispiel (und möglichst einem eigenen Beitrag) eingegrenzt werden. Nur, wenn sich dabei zeigt, dass Probleme untrennbar zusammen gehören, also dass es sich um Teilaspekte eines größeren Problems handelt, ist ein einziges Minimalbeispiel sinnvoll. Die Teilprobleme und deren Abhängigkeiten sollten dann aber auch deutlich genannt werden.

Das macht zweilerlei Hinsicht einen Unterschied. Zum einen werden size<Größe>.clo-Dateien nur bei Verwendung in \documentclass geladen, da KOMA-Script keine Kontrolle darüber hat, was genau diese aus fremden Quellen stammenden Dateien enthalten und sie häufig zu einem späteren Zeitpunkg nicht mehr fehlerfrei geladen werden können. Bei Verwendung von \KOMAoptions oder \KOMAoption wird also auch in einigen Fällen eine Berechnung der Schriftgrößeneinstellungen verwendet, in denen beim Setzen der Grundschriftgröße über das optionale Argument von \documentclass eine Einstellungsdatei verwendet wird.

Zum anderen passt eine Änderung der Grundschriftgröße nach dem Laden der Klasse keineswegs alle Längen, die von der Klasse oder gar von zuvor geladenen Paketen verwendet werden, an die neue Grundschriftgröße an. Das ist auch technisch kaum möglich. Die Information ob eine Länge von der Grundschriftgröße abhängt oder nicht, ist nicht einmal beim Setzen der Länge eindeutig. Nach dem Setzen der Länge ist sie überhaupt nicht mehr verfügbar. Daher sollte die eigentliche Grundschriftgröße des Dokument auch bei KOMA-Script immer beim Laden der Klasse angegeben werden. Eine spätere Änderung sollte sich wirklich nur auf Ausnahmefälle beschränken. In der Anleitung wird beispielsweise der Fall eines (eher kurzen) Anhangs in anderer Schriftgröße genannt.