• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

docstrip und nicht-ASCII-Zeichen (bzw. write und solche)

[Bitte vor dem Antworten zuerst bis zu Ende lesen: Das Problem ist
bereits gelöst. Ich poste das trotzdem mal so, wie ich es, ohne die
Lösung zu kennen, nach und nach geschrieben habe. Vielleicht hilft es
mal jemanden.]

Hallo,

ich habe heute den Quelltext eines meiner Pakete von Latin-1 auf UTF-8
umstellen wollen, unter anderem, damit die in der (per Docstrip aus der
DTX-Datei extrahierten) README-Datei auch gleich so kodiert ist (und ich
nebenbei auch Nicht-latin-1-Zeichen verwenden kann).

Das Umwandeln des Quelltextes ist ja kein Problem, das macht Emacs mit
ein paar Mausklicks. Auch ein paar Änderungen, damit der Doku-durchlauf
dann \usepackage[utf8]{inputenc} verwendet, sind kein Problem.

Das Problem tat sich dann an ganz anderer Stelle auf: Die generierte
README-Datei enthielt plötzlich keine ä, ö, ü mehr, sondern ^^c3^^a4,
^^c3^^b6, ^^c3^^bc.

Und als ich gerade ein Minimalbeispiel dazu erstellen wollte, stellte
ich fest, dass auch in meinem frisch übersetzten Latin-1-kodiertem
Original [1] die Umlaute nicht direkt vorhanden sind, sondern
^^-kodiert, hier natürlich ^^e4, ^^f6 und ^^fc.

Ich bin mir aber ziemlich sicher, dass das früher einmal funktioniert
hat - etwa hat mir mein Kubuntu-Paketmanager eine frühere Version dieser
generierten README-Datei installiert, in der die Umlaute
(latin-1-kodiert) richtig aussehen - diese Version war auch bis vor ein
paar Tagen auf CTAN [2].

Meine Frage: Woran kann es liegen, dass das nicht mehr funktioniert? Ist
das eine andere Konfiguration meines TeX, oder ein neues docstrip?

...

OK, nach einigem Probieren (z.B. mit locale-Einstellungen) ist die
Ursache gefunden:
Mit tex erhalte ich die ^^-Variante, mit etex (und pdftex, pdflatex
etc.) die "echte" Variante. Hmm, jetzt muss ich nur noch herausfinden,
warum jetzt auf einmal ein "pures" TeX von meinem Make-Skript aufgerufen
wird, und vorher nicht.
...
Aha, das geschah im März dieses Jahres im Zuge eines Umräumens meines
Build-Systemes: Damals habe ich ein kompliziertes
INSTALLTEX='TEXMFCNF="$HOME/texmf" $LATEX'
(bei dem in den Config-Dateien in $HOME/texmf vor allem openout_any=a
gesetzt wurde) durch
INSTALLTEX='openout_any=a tex'
ersetzt. Tja, $LATEX war damals schon ein e-TeX, tex nicht.

Und diese Änderung wurde vornehmlich dafür gemacht, dass docstrip die
Dateien gleich ins Zielverzeichnis in meinem texmf-Baum stecken kann -
dass durch die Verwendung von tex statt latex die Readme-Datei kaputt
geht, fiel mir nicht auf, da nur eines meiner Pakete (eben das, an dem
ich gerade sitze) die READMEs mit docstrip generiert, und das hatte ich
damals ja gar nicht angefasst.

OK, das 'tex' habe ich zu 'etex' geändert, und nun läuft alles wie
gewünscht :-)
(Ich hatte sogar schon angefangen, ein Programm zu schreiben, welches
die ^^xx-Kodierung wieder in ihre Original-Bytes zurückverwandelt. Es
zeigte sich, dass das mit sed nicht so einfach ist, wie es aussieht.)

Was lernen wir:
(1) in eTeX kann \write mit allen 256 Zeichen umgehen, nicht nur mit der
ASCII-Teilmenge wie in TeX.
(2) Bei Änderungen des Build-skriptes bitte immer alle damit zu bauenden
Pakete einmal durchlaufen lassen, nicht nur das, für das man die
Änderung gerade macht. Und auch die Ergebnisse ansehen.

Danke für's Zuhören!

Paul
-----
[1] Dieses Exemplar hat es vor ein paar Tagen nach CTAN geschafft, ohne
dass ich das bemerkt hätte:
http://www.ctan.org/tex-archive/macros/latex/contrib/dateiliste/
(der deutsche Teil der README-Datei, oder README-de).

[2] An der bei [1] genannten Stelle war seit Mai 2006 eine
Latin1-kodierte Datei, die auf dem Dante- und TUG-Server aber auch
kaputt aussah, weil der dies als UTF-8 auslieferte. Demnächst wird die
nächste Version hochgeladen (mit noch mehr Änderungen als nur der
Readme-Datei).

Antworten