Nichts mit WYSIWYG

Fehler in Qt

Dann weigert sich der PostScript-Betrachter gv plötzlich mit einem Unrecoverable error, von der erzeugten ps-Datei überhaupt etwas anzuzeigen. Der Schuldige hierfür steckt tief im Qt-Quellcode versteckt, genaugesagt in der Datei src/kernel/qpsprinter.cpp: Enthält eine pfb-Datei Leerzeilen oder die Zeichenkombination CR/LF als Zeilenende, geht einiges schief. Dummerweise steckt in allen pfb-Fonts aus dem XType1-Paket jeweils eine Leerzeile. Qt-Hersteller Trolltech verspricht, diesen Fehler in Version 3.2 zu beheben, doch das hilft derzeit aktuellen Installationen leider nicht weiter.

Abbildung 4: Damit Qt richtig arbeitet, muss die markierte Leerzeile aus der Datei Advertisement.pfb entfernt und die Länge des ASCII-Teils am Dateianfang angepasst werden

Zum Glück gibt es einen Workaround, ohne Qt zu patchen: die problematischen Leerzeilen mit einem minimal-invasiven Editor wie vi aus den XType1-PFB-Dateien zu entfernen. Wie Abbildung 4 anhand der XType1-Datei Advertisement.pfb zeigt, bestehen "Postscript Font Binary"-Dateien aus menschenlesbaren ASCII-Teilen (oben) und Binärbestandteilen (die komischen Zeichen im unteren Teil). Die Zeilenumbrüche stellt vi als ein Zeichen ^M ([Strg-M]) dar. Das ist die Kontrollsequenz, die hinter CR steckt.

Um nach einer Leerzeile, also zwei aufeinanderfolgenden [Strg-M]-Sequenzen, zu suchen, gibt man im vi-Kommandomodus das Suchzeichen / und anschließend [Strg-V][Strg-M][Strg-V][Strg-M][Enter] ein. Die im ASCII-Teil gefundene ^M^M-Sequenz (nicht jedoch eventuelle weitere im Binärteil) reduziert der vi-Befehl x (Zeichen unter dem Cursor löschen) auf ein Zeilenumbruchszeichen. Doch ehe :wq speichernd den Editor verlässt, muss man noch die Länge des so um ein Zeichen verkürzten ASCII-Teils anpassen. Die steht am Dateianfang zwischen der Kontrollsequenz ^A und einer weiteren.

Wie um alles in der Welt kann eine Länge wie in Abbildung 4 den Wert Í haben? Das spielt zum Glück keine so große Rolle: Man muss diese "Anzahl" lediglich um eins erniedrigen, und da Í ein Zeichen aus dem ISO-8859- oder Latin-1-Zeichensatz ist, reicht es, in der Latin-1-Code-Tabelle den Vorgänger-Code von Í nachzuschlagen. man latin1 listet die Code-Tabelle auf; die ersten drei Spalten geben den Code des Zeichens aus Spalte vier im Oktal-, Dezimal- und Hexadezimal-Zahlensystem an; am Ende folgt eine Erklärung:

314   204   CC     Ì     LATIN CAPITAL LETTER I WITH GRAVE
315   205   CD     Í     LATIN CAPITAL LETTER I WITH ACUTE

Í in Abbildung 4 muss sich also lediglich per Copy&Paste in Ì verwandeln.

Bei anderen Fonts ist die Suche nach dem neuen Längen-Code einfacher: Steht an der entscheidenen Stelle ein großer Buchstabe aus dem lateinischen Alphabet, nimmt man seinen (ebenfalls großgeschriebenen) Vorgänger. So wird aus dem von vi als ~@^AL dargestellten Dateianfang in College-Bold.pfb die Sequenz ~@^AK oder aus ~@^AT in College-Italic.pfb ~@^AS.

Um zu testen, dass dabei nichts schiefging, entfernt man das Verzeichnis mit den nunmehr geänderten XType1-Fonts mit

xset -fp /home/pjung/XType1/

aus dem Font Path und fügt es mit xset +fp wie oben gezeigt wieder ein. Somit löscht X seinen Font-Cache und liest die Font-Dateien neu ein. Ruft man jetzt erneut xfontsel auf, lassen sich alle geänderten Fonts prüfend durchgehen.

Stimmt hier alles, ist der Weg zu kyrillischen Ausdrucken aus Konqueror und Opera frei. Einen Haken hat die Font-Auswahl dennoch: Da die kyrillischen Schriften zwar 7-Bit-ASCII-Zeichen, aber keine deutschen Umlaute enthalten, sehen deutschsprachige Seiten mit den neuen Default-Schriften plötzlich merkwürdig aus. Hier hat der Konqueror-Schriften-Dialog den großen Vorteil, dass man mit einem Mausklick wieder zu den Voreinstellungen kommt. Bei Opera mit seinem Font-Einstellungskonzept "eine Schrift pro HTML-Element" wäre ein solcher Knopf noch dringender, zumal man bei aufwändigen Seiten durchaus eine Menge ändern darf. Der Weg zum problemlosen, alphabetunabhängigen Ausdruck ist also noch weit.