scrwfile: Tester gesucht!

Ich suche Tester für ein neues Paket mit Namen scrwfile, das sich noch immer in Entwicklung befindet. So wie scrlfile Einfluss auf das Laden von Dateien erlaubt, verändert scrwfile das Schreiben von Dateien. Konkret hackt es sich in \@starttoc und \@writefile ein.

Theoretisch kann man die Aktivitäten von scrwfile auf einzelne Dateiendungen beschränken bzw. einzelne Dateiendungen von den Aktivitäten von scrwfile ausnehmen. Dies beträfe dann alle Features von scrwfile:

Single Write Handle Feature

Normalerweise fordert LaTeX bei jedem \@starttoc ein neues write handle, öffnet die Datei und hält sie bis zum Ende des TeX-Laufs offen. Das führt dazu, dass für jedes Verzeichnis, das über \@starttoc ausgegeben wird (Inhaltsverzeichnis, Abbildungsverzeichnis, Tabellenverzeichnis, weitere float-Verzeichnisse, Verzeichnis der Listings, Verzeichnis der Algorithmen, ...) ein eines write handle benötigt wird. Da TeX maximal 17 dieser write handles hat und einige davon schon für interne Zwecke benötigt werden und natürlich für Index, Glossary etc. ebenfalls write handles benötigt werden, kann es schon passieren, dass diese aus gehen.

scrwfile ändert \@starttoc nun so, dass keine write handles mehr angefordert werden. Damit die Hilfsdateien für die Verzeichnisse trotzdem erzeugt werden, wird dann vor dem Schließen und damit auch vor dem Einlesen der aux-Datei zusätzlich \@writefile so abgeändert, dass dies eine weitere Hilfsdatei erzeugt, die dann wiederum so oft verarbeitet wird, wie notwendig ist, um die sämtliche Verzeichnishilfsdateien zu erzeugen. Dazu bedient sich scrwfile auch scrlfile. Außerdem verwendet scrwfile ein ohnehin bereits belegtes internes write handle aus dem LaTeX-Kern, das zu diesem Zeitpunkt ungenutzt ist.

Ergebnis der Aktion ist, dass mit scrwfile kein einziges write handle mehr für die mit \@starttoc angezeigten Verzeichnisse benötigt. Da direkt die Verarbeitung der aux-Dateien verändert wird, müssen \addtocontents und \addcontentsline nicht angetastet werden und es werden auch Anweisungen erfasst, die mit anderen Aufrufen von \@writefile erzeugt werden.

Dieses Feature ist derzeit bereits nach dem Laden von scrwfile aktiv. Es gibt jedoch Überlegungen, das Feature optional zu deaktivieren. Dies hätte jedoch massive Auswirkungen auf die Implementierung der übrigen Features. Sinnvoll ist die Möglichkeit, dieses Feature zu deaktivieren auch deshalb, weil LuaTeX keine Beschränkung bei den write handles mehr hat, bei Verwendung von LuaLaTeX also kein Problem bezüglich der Anzahl der gleichzeitig öffenbaren Dateien mehr besteht.

Clone File Feature

Manchmal wäre es praktisch, wenn man alle Einträge, die in eine Verzeichnisdatei geschrieben werden, automatisch auch in andere Verzeichnisdateien schreiben lassen könnte. Genau dieses Möglichkeit bietet scrwfile mit der Anweisung \TOCclone[Verzeichnistitel]{Quellendung}[Zielendung}. Dabei wird zunächst die Zielendung via tocbasic den bekannten Endungen (mit Besitzer TOCclone) hinzugefügt, falls die Endung tocbasic noch nicht bekannt ist. Außerdem wird dafür gesorgt, dass alle \@writefile-Anweisungen für die Datei mit der Quellendung für die Zielendung ausgeführt werden. Wichtig ist, dass dieses Kopieren erst beim Einlesen der aux-Datei erfolgt! Auch hierzu wird wieder mit Hilfe von scrlfile \@writefile kurz zuvor geändert.

Ist das optionale Argument gesetzt, so werden außerdem die zum Zeitpunkt des Aufrufs von \TOCclone geltenden primären tocbasic features, die für die Quellendung gesetzt sind für die Zielendung kopiert. Desweiteren wird dann das angegebene optionale Argument Verzeichnistitel als Titel für das Verzeichnis der Zielendung und die Anweisung \listofZielendung definiert.

Will man nun also eine Gliederungsübersicht, so geht das einfach mit:

\usepackage{scrwfile}
\TOCclone[Gliederungsübersicht]{toc}{xtoc}
\AtBeginDocument{\addtocontents{xtoc}{\value{tocdepth}=1}}
...
\begin{document}
...
\listofxtoc
...
\end{document}

Sinn des Pakets

Dieses Paket ist einer der Bausteine, um das eingestellte Experiment tocstyle zu ersetzen. Tatsächlich handelt es sich dabei um eine Abspaltung aus der ehemaligen tocstyle-Entwicklung.

Die Aufgabe der Tester

Da das Paket an Interna von LaTeX herumpfuscht wäre die erste Aufgabe der Tester einfach nur, das Paket möglichst bei jedem Dokument und an unterschiedlichen Stellen in der Präambel zu laden. Falls allein schon durch das Laden des Pakets Probleme entstehen, sind diese vorzugsweise hier oder ersatzweise per Mail an mich zu melden. Natürlich wäre es schön, von Zeit zu Zeit auch Erfolgsberichte zu bekommen. In dem Fall ist für mich interessant, welche Klassen und Paket verwendet wurden.

Tests mit dem Clonen sind natürlich ebenfalls willkommen, aber keine Grundvoraussetzung. Wichtiger ist erst einmal zu sehen, ob das per Default aktive single write handle feature funktioniert, also das reine Laden des Pakets keine Probleme verursacht.

Hauptziel des Tests ist also Inkompatibilitäten zu finden und zu dokumentieren. Viele dieser Inkompatibilitäten werden sich aufgrund der stark abweichenden Arbeitsweise bei aktivem single write handle feature nicht umgehen lassen. Daher ist es umso wichtiger, den Anwender darüber zu informieren.

Wie Tester an das Paket kommen

Das Paket ist schon seit einiger Zeit Teil von KOMA-Script. Es ist also kein Problem an das Paket zu gelangen. Aktuellere Versionen sind ggf. in der aktuellen KOMA-Script-Prerelease oder für die Experten unter den Testern auch im Quellcode-Repository zu finden.