Große Vorlage und kleines Minimalbeispiel zusammenbringen

Du sprichst mit der Frage eigentlich verschiedene Dinge an.

1. Die Erwähnung einer nicht näher bezeichneten Vorlage, die offenbar aus mehreren Dateien besteht wirft die Frage nach dem Sinn und dem richtigen Umgang mit Vorlagen auf.

   Viele der Vorlagen, die im Internet oder an Universitäten kursieren sind leider sehr schlecht. Manche davon waren vielleicht vor vielen Jahren, als die erste Fassung entstanden ist, sogar sehr gut. Dann aber wurde die Vorlage nicht mehr gut gepflegt, verschiedene Anwender haben Dinge ohne das nötige Fachwissen und ohne den Blick auf die Gesamtzusammenhänge hinzugefügt, die verwendeten Pakete sind teilweise veraltet oder wurden weiterentwickelt, ohne dass die Vorlage daran angepasst wurde, neue Dateien wurden recht wahllos hinzugefügt. Von solchen Vorlagen sollte man besser die Finger lassen, weil sie schon in der angebotenen Grundform problematisch sind.

   Vorlagen sind oft sehr komplexe Sammlungen aus Dateien, die auf verschiedene Unterordner verteilt sind. Solange man die Vorlage genau so, wie sie ist, verwendet, ist das nicht unbedingt ein Problem. Aber schon, wenn man eine neue Dokumentdatei hinzufügt, muss man zumindest zuvor herausfinden, auf welche Eingabecodierung die Vorlage voreingestellt ist. Deshalb ist es unumgänglich, sich in die Struktur einer Vorlage einzuarbeiten. Das kostet natürlich Zeit, ist aber schlicht notwendig. Die Erfolgsaussichten dafür sind umso größer, je besser die Vorlage dokumentiert ist. Dazu gehört nicht nur eine Anleitung, sondern auch ein Mindestmaß an Kommentaren im Code der Vorlage. Ein altes Prinzip der Softwaretechnik besagt: Was nicht dokumentiert ist, existiert nicht. Eine nicht dokumentierte Vorlage ist damit als nicht existent anzusehen und sollte nicht verwendet werden.

   Vorlagen enthalten oft eine Vielzahl an Paketen und Code, der die Voreinstellungen der Klasse und der verwendeten Pakete ändert, weil sie für einen bestimmten Aufgabenzweck zusammengestellt sind. Verwendet man sie nicht genau für diesen Zweck benötigt man diverse der Pakete nicht. Entfernt man solche Pakete, kann aber wiederum weiterer Präambelcode zu Fehlermeldungen führen, der die Arbeitsweise dieser Pakete abgeändert hat. Man muss als Anwender daher auch erkennen, welcher zusätzliche Code sich auf ein nicht benötigtes Paket bezieht, damit man diesen ggf. mit entfernen kann. Ebenso kann es erforderlich sein, dass man andere Pakete verwendet. Allerdings sind nicht alle Pakete beliebig miteinander kombinierbar und teilweise muss man die Reihenfolge der Pakete beachten. Dafür ist es notwendig sich ggf. zeitaufwändig in die Vorlage einzuarbeiten. Selbst bei gut dokumentieren Vorlagen, kann das schwierig sein. Man muss sich daher bewusst sein, dass wenn man sich auf eine Vorlage einlässt, man sich gleichzeitig auf eine bestimmte Art von Dokument einlässt und Änderungen der Vorlage mit erheblichem Aufwand verbunden sein können.

   Die reine Veröffentlichung einer Vorlage ist nur so lange von Wert, solange Anwender genau mit dieser Vorlage arbeiten können. Gibt es Probleme benötigen Anwender Support. Deshalb ist eine Vorlage immer nur so viel wert, wie der Support, der dazu geleistet wird. Gerade für komplexe Vorlagen sollte man nicht erwarten, dass andere den Support freiwillig übernehmen, die weder mit dieser Vorlage arbeiten müssen, noch irgend einen Nutzen aus deren Verwendung ziehen. Daher sollte man vor der Verwendung einer Vorlage der Frage nachgehen, ob dafür auch Support geleistet wird.

   Neben Vorlagen, die klar und deutlich unter eine freie Lizenz gestellt wurden, gibt es nicht nur in geschlossen Bereichen wie Verlagen oder Universitäten, auch immer wieder solche, bei denen die Lizenz eine Weitergabe mit allen notwendigen Bestandteilen nicht erlaubt oder die Lizenzfrage gar nicht eindeutig geklärt ist. Bei unklarer Lizenz ist davon auszugehen, dass eine Weitergabe nicht gestattet ist. Selbst für die Benutzung könnten dann Lizenzgebühren fällig werden. Wer solche Vorlagen verwendet, muss sich im Klaren sein, dass er sich in einen geschlossenen Bereich begibt und Hilfe konkret zu dieser Vorlage nur innerhalb dieses Bereichs möglich ist. Die bereits erwähnte Supportfrage ist dann umso wichtiger.

2. Beachtenswertes bei Fragen zu einem real existierenden Dokument

   Arbeitet man an einem Dokument und hat nun eine Frage, so ist in eigentlich allen Foren aber auch im Usenet oder bei E-Mail-Support immer ein Minimalbeispiel von Nöten. Nun kann man natürlich ein solches Minimalbeispiel von Null extrem kurz zusammenbauen. Allerdings wird man dann auch eine Antwort erhalten, die auf dem basiert, was der Helfer in genau dieses Minimalbeispiel einfügen würde. Das kann im realen Dokument natürlich zu Konflikten mit bereits verwendeten Paketen führen. Eine Lösung, mit der man sich sehr unbeliebt machen kann, wäre natürlich das komplette Dokument oder den kompletten Präambelcode (bei Vorlagen oft verteilt auf mehrere Dateien) mit anzugeben. Sinnvoller ist, nur relevante Teile in dem Minimalbeispiel zu verwenden. Hat man beispielsweise eine Frage zu Kopf- und Fußzeile und verwendet bereits ein Paket dafür. Dann ist es sinnvoll genau diesen Code im Minimalbeispiel zu zeigen. Hat man Frage zur Form von Überschriften sollte man im Minimalbeispiel genau die Klasse angeben, die man verwendet. Verwendetet man zusätzlich ein Paket zur Veränderung der Überschriften, gibt man auch dieses mit an und den zugehörigen Code, mit dem man die Einstellungen bisher vornimmt.

   Auch die Verwendung einer Vorlage ist meist ein solches existierendes Dokument. Bei der Verwendung muss man sich also klar sein, dass man sich bei Fragen ggf. tief in die Vorlage einarbeiten muss, um Fragen wirklich gut stellen zu können, so dass man mit der Antwort auch etwas anfangen kann.

3. Probleme mit der Integration eines Lösungsvorschlags in ein vorhandenes Dokument

   Die Integration stellt dann ein eigenes Problem dar. Also reduziert man das real existierende Dokument erneut zu einem Minimalbeispiel, so dass das Problem mit der Integration der Lösung nachvollziehbar wird und stellt eine neue Frage. Dabei ist es meist sinnvoll, sich mit Link auf die vorherige Frage oder Lösung zu beziehen und anzugeben, worin das neue Problem besteht.

4. Die Bedeutung der Anzahl von Fehlermeldungen

   TeX beendet den TeX-Lauf nicht beim ersten Fehler, sondern versucht eine Lösung des Fehlers in dem Sinne, dass es in einen Zustand versetzt wird, in dem es seine Arbeit fortsetzen kann. Leider besteht diese Lösung zwangsläufig oft darin, dass Dinge einfach ignoriert werden. Beispielsweise wird bei einem nicht bekannten Befehl einfach so getan, als wäre der Befehl selbst nicht verwendet worden. Hat der Anwender für den Befehl aber mehrere Argumente angegeben, werden diese von TeX dann trotzdem weiterverarbeitet, eben so als hätte der Befehl nicht vor den Argumenten gestanden. Solche Dinge führen häufig zu Folgefehlern. Daher kann man aus der Zahl der Fehlermeldungen nicht auf die tatsächliche Zahl der Fehler oder deren Schwere schließen. Ein einfacher Tippfehler kann bereits Dutzende von Fehlern auslösen.

5. Die Frage der Paketabhängigkeiten

   Es ist in der Tat richtig, dass je mehr Pakete und je mehr Code man in einer Dokumentpräambel hat, desto schwieriger ist es nicht nur, den Überblick darüber zu behalten, sondern auch Abhängigkeiten zu berücksichtigen und zu erkennen. Es gibt da lediglich einige wenige Faustregeln wie beispielsweise, dass hyperref als eines der letzten Pakete geladen werden sollte. Außerdem sollte man Pakete nicht mehrfach laden, obwohl das mit identischen Optionen durchaus möglich ist. Das mehrfache Laden macht die Präambel aber noch unübersichtlicher und führt häufig zu Problemen, wenn man etwas ändern will. Natürlich fällt die Übersicht umso leichter, je besser man sich auf die Dinge beschränkt, die man tatsächlich verwendet. Auch sinkt damit die Gefahr von Inkompatibilitäten oder Reihenfolgeabhängigkeiten. Ebenfalls nützlich ist, wenn man weiß, welches Paket und welcher Code wofür verwendet wird. Es ist also sinnvoll, bei allen verwendeten Paketen wenigstens einen Blick in eine Kurzbeschreibung oder die Anleitung zu dem Paket zu werfen. Ein Überblick über die Fähigkeiten der verwendeten Pakete hilft auch dabei, bei neuen Anforderungen festzustellen, ob diese mit den vorhandenen Paketen bereits erfüllbar sind oder welche Pakete und Definitionen man bei einer Frage im Minimalbeispiel besser mit angeben oder zumindest erwähnen sollte.

Kurz gesagt: Diverse Pakete enthalten Anleitungen, in denen explizit vermerkt ist, wenn bekannt ist, dass sie sich schlecht mit anderen Paketen vertragen oder eine bestimmte Reihenfolge einzuhalten ist oder ähnliche Probleme zu erwarten sind. Ebenso enthalten einige Paketanleitungen Hinweise über Paketabhängigkeiten. Man sollte also die Anleitungen der verwendeten Pakete konsultieren.

Ebenso sollten Vorlagen natürlich eine Anleitung besitzen. Allerdings sollte man davon dann nicht erwarten, dass darin erklärt ist, welche Pakete man nicht in die Vorlage einfügen und welche Änderungen man nicht vornehmen sollte. Im allgemeinen sind die Vorlagen ja eher dazu gedacht wie vorgefunden verwendet zu werden. Schön wäre natürlich, wenn dokumentiert wäre, welche Klasse und welche Pakete von der Vorlage verwendet werden oder in welchen Dateien man diese Informationen findet. Dann kann man wieder in den jeweiligen Anleitungen nachlesen.

Ansonsten kann man die Vorlage natürlich auch ggf. um ein \listfiles erweitern und dann am Ergebnis aus der log-Datei ablesen, welche Klasse und welche Pakete verwendet werden. Das geht sogar ohne \listfiles, ist dann aber etwas aufwändiger.

Grundsätzlich kritisch ist der Vermischung mehrerer Pakete, die dem gleichen Zweck dienen. So sollte man beispielsweise in der Regel nicht mehrere Seitenstil-Pakete oder mehrere Überschriftenstil-Pakete gleichzeitig verwenden. Manchmal sind solche Dinge natürlich auch möglich, wenn beispielsweise ein Paket auf dem anderen aufbaut. So kann man etwa tabularx gleichzeitig mit array verwenden, muss dann aber array nicht explizit laden, weil tabularx das bereits erledigt.