Hallo,
Tester sind angehalten, Probleme in Zusammenhang mit dem scrwfile-Paket zu melden.
Ich bin nun über etwas gestolpert, was man so nennen könnte, auch wenn es keinen eigentlichen Bug/Fehler im scrwfile-Paket darstellt:
Das scrwfile-Paket setzt laut seiner Dokumentation am \@starttoc-\addtocontents-\@writefile
-Mechanismus an.
Nun ist es so, dass ich bei vielen meiner Dokumente möchte, dass die Dinge am Ende so, wie ich sie im Quelltext eingebe, in der jeweiligen Hilfsdatei landen, weil die Hilfsdatei auch von anderen Programmen gelesen wird. D. h., oft möchte ich, dass Zeilenumbrüche, Leerzeichen und dergleichen genau so in der Hilfsdatei landen, wie ich sie im Quelltext eingebe.
Da \addtocontents
und \@writefile
aber vor dem Schreiben ihre Argumente jeweils unter normalem Catcode-Régime einlesen, ist das bei diesen Kontrollsequenzen nicht gewährleistet.
Ich habe mir deshalb schon vor Jahren - entsprechend häufig ist sie in meinen Dokumenten benutzt - meine eigene Variante dieses Mechanismus programmiert, die im Prinzip gleich funktioniert, mit dem einzigen Unterschied, dass diejenigen Argumente für \addtocontents
bzw \@writefile
, die den zu schreibenden Text enthalten, zunächst jeweils "verbatimisiert", d.h. unter dem catcode-Régime des \verb
-Befehls, eingelesen und dann erst zum Schreiben an \addtocontents
bzw \@writefile
übergeben werden. (Fürs eigentliche Schreiben kann man nur hoffen, dass beim Benutzer keine .map-files oder dergleichen zum Tragen kommen, die beim Schreiben manche Character durch ^^-Notation ersetzen würden...)
Im Quelltext verwende ich somit bei diesem Mechanismus meine eigene verbatimisiert einlesende \addtocontents
-Variante, die - statt in die .aux-Datei einen \@writefile
-Befehl zu schreiben - in die .aux-Datei den Befehl \UD@CatcodeSwitchedWriteFile
hineinschreibt, mittels dessen das den zu schreibenden Text beinhaltende Argument aus der .aux-Datei wieder verbatimisiert gelesen und dann erst an \@writefile
übergeben wird.
Zusammen mit dem scrwfile-Package ist dieser "Verbatimisierungs-Mechanismus" natürlich ausgehebelt, weil eine weitere \@writefile
-Etappe hinzukommt, bei der das den Text beinhaltende Argument aus der .wrt-Datei direkt über den \@writefile
-Befehl eingelesen und somit nicht mehr verbatimisiert eingelesen wird.
Wenn man den Paket-Code von scrwfile gelesen hat, ist es natürlich einfach, die Sache für die eigene \@writefile
-Variante so nachzubasteln, dass sie auch mit scrwfile funktioniert.
Aber im Prinzip geht es bei scrwfile ja nur darum, dass das Token \@writefile
in der ersten Schreiberunde sich selbst und seine Argumente nochmal in die .wrt-Datei hineinschreibt.
Ganz genau in der selben Weise müsste meine \@writefile
-Variante - anstatt eines \@writefile
-Befehls - sich selbst und ihre Argumente in die .wrt-Datei hineinschreiben, damit auch aus der .wrt-Datei wieder auf die selbe Weise / mit dem selben catcode-Regime gelesen wird wie aus der .aux-Datei.
Vielleicht könnte in das scrwfile-Package ein Hook eingebaut werden, damit Benutzer wie ich, die eigene \@writefile
-Varianten benutzen, eine Liste an Kontrollsequenzen vorgeben können, die genau auf die selbe Weise gepatcht werden sollen, wie der \@writefile
-Befehl?
Ich habe im folgenden ein Minimalbeispiel mit eigenen \addtocontents
- und \@writefile
-Varianten angefügt, die jeweils dasjenige Argument, das den zu schreibenden Text enthält, mit geändertem catcode-Regime einlesen. Im Vergleich zu dem, was ich zum verbatimisierten Einlesen tatsächlich verwende, sind diese Varianten stark abgespeckt, denn sie ändern nur den catcode des Backslash und des Caret/Hat.
Aber sie illustrieren die Problematik:
Das Minimalbeispiel liefert unterschiedlich aussehende Hilfsdateien, je nachdem, ob scrwfile genutzt wird oder nicht.
Wenn man im Minimalbeispiel scrwfile auskommentiert, alle Hilfsdateien löscht und dann zweimal mit herkömmlichem pdflatex compiliert, erhält man eine .lst-Hilfsdatei, in der die ^^-Notation erhalten ist.
Wenn man im Minimalbeispiel scrwfile verwendet, alle Hilfsdateien löscht und dann zweimal mit herkömmlichem pdflatex compiliert, erhält man eine .lst-Hilfsdatei, in der die ^^-Notation nicht mehr erhalten ist.
Der Grund ist: Im .aux-file stehen Aufrufe der eigenen, mit geändertem catcode-Régime einlesenden \@writefile
-Variante, die zunächst das catcode-Régime temporär geringfügig ändert, dann Argumente einliest und dann erst diese unter geändertem catcode-Régime eingelesenen Argumente an \@writefile
übergibt.
Wenn scrwfile geladen ist, stehen beim Zwischenschritt übers .wrt-File in selbigem aber auf jeden Fall \@writefile
-Anweisungen. Diese lesen die Text-Argumente aber nicht mehr unter geändertem, sondern unter normalem catcode-Régime ein bevor die eigentlichen Hilfsdateien geschrieben werden.
Ulrich
\documentclass[a4paper]{article} %\usepackage{scrwfile} \usepackage{verbatim} \makeatletter \@ifpackageloaded{scrwfile}{% \newcommand\phrase{}% }{% \newcommand\phrase{not }% }% \newcommand\UD@SwitchCatcodeAndCall[1]{% \begingroup \catcode`\^=12\relax \catcode`\\=12\relax \expandafter\endgroup#1% }% \newcommand*\UD@CatcodeSwitchedWriteFile[1]{% \UD@SwitchCatcodeAndCall{\@writefile{#1}}% }% %\newcommand\UD@CatcodeSwitchedWriteFile[1]{% % \ifx\@writefile\scrwfile@writefile % \expandafter\@firstone % \else % \expandafter\@secondoftwo % \fi % {% % \scrwfile@if@only{#1}{\@firstoftwo}{\@secondoftwo}{% % \typeout{Use my own \string\@writefile\space for #1}% % \UD@SwitchCatcodeAndCall{% % \immediate\write\scrwfile@wrtout{% % \string\UD@CatcodeSwitchedWriteFile{#1}% % }% % }% % }% % }{% % \UD@SwitchCatcodeAndCall{\@writefile{#1}}% % }% %}% \newcommand\UDaddtocontents[1]{% \UD@SwitchCatcodeAndCall{\UD@addtocontents{#1}}% }% \newcommand\UD@addtocontents[2]{% \protected@write\@auxout% {\let\label\@gobble \let\index\@gobble \let\glossary\@gobble}% {\string\UD@CatcodeSwitchedWriteFile{#1}{#2}}% }% \begin{document} \UDaddtocontents{lst}% {^^48^^65^^6c^^6c^^6f^^2c^^20^^77^^6f^^72^^6c^^64^^21} With \texttt{scrwfile} \phrase loaded, the file \texttt{\jobname.lst} looks like this: \verbatiminput{\jobname.lst} The phrase that is contained in it is: \fbox{\@starttoc{lst}} \end{document}
Guter Punkt
Nur ist es wohl so, dass bei luatex die Beschränkung bezüglich der Handles wegfällt und solche Umwege wie scrwfile dann eigentlich gar nicht mehr nötig sind. Deshalb stellt sich mir schon die Frage, ob es sich noch lohnt, da Arbeit zu investieren. Ja, ja ich weiß, es gibt unzählige Leute, die noch pdflatex verwenden und nicht so einfach auf lualatex umsteigen können. Fast das gleiche Argument ist Schuld, dass in KOMA-Script noch immer jede Menge Code enthalten ist, der irgend etwas wahnsinnig umständlich löst, das mit e-TeX ganz einfach geht.
Na, mal sehen, wenn ich die aktuellen Baustellen geschlossen habe.