Altlasten mit ü

Verwenden Sie möglicherweise noch irgendwo EPS-Grafiken aus dem letzten Jahrhundert? Falls nicht, dann können Sie diesen Beitrag als Randnotiz bewerten und woanders weiter lesen.

Dieser Tage bekam ich solche einfache EPS-Dateien wie oben zugesandt, erstellt 1996 mit FreeHand, was sich nach dem Öffnen mit einem Texteditor einfach feststellen ließ:

Diese Dateien waren als nicht-kompatibel mit FrameMaker 9 identifiziert worden, aber warum? Und ließe sich etwas dagegen unternehmen? Beide Fragen konnten beantwortet werden.

Die Situation

Dokumente mit diesen Grafiken ließen sich seit Jahren völlig problemlos mit FrameMaker bis einschließlich Version 7.2 bearbeiten. Bei Tests mit FrameMaker 9 ließen sich die alten Dokumente zwar öffnen, aber nur um das Programm dann mehr oder weniger sofort abstürzen zu lassen. Boom! Wer war schuld?

>
>

Etwas kurios ist die Situation mit der Freehand, denn 1996 war FreeHand 7 auf Windows verfügbar, das Dokument verwendet aber offensichtlich die PostScript-Bibliotheken von FreeHand 3, welches 1991 oder 1992 erscheinen war, auf Macintosh.

Die Analyse

Ein Test mit meinem Lieblings-Workspace „Leer“ (also ohne jeden offenen Pod) ergab keine Auffälligkeiten. Auch wenn die bösen Grafiken direkt in FrameMaker 9 importiert wurden, gab es keine oder zumindest weniger Probleme. Denn sobald ich testweise die Tabellengestaltung öffnete, verabschiedete sich die Anwendung (das Dokument enthielt keine Tabellen). Es benötigte etwas Entspannung, um den möglichen Zusammenhang nach erneutem Blick auf den Text in der EPS-Datei zu erkennen: das ü im Farbnamen Füllung.

In PostScript gibt es nur ASCII-Zeichen, es gibt kein vordefiniertes Encoding für Nicht-ASCII-Zeichen, die muss sich der PS-Programmierer immer selbst schaffen. Nachdem ich die Datei in Illustrator geöffnet und erneut als EPS gespeichert habe, wurde das ü im Namen der Farbe »Füllung« folglich auch durch ein Oktal-Zeichen \774 ersetzt.

Aber reicht FrameMaker den Inhalt von EPS-Dateien beim Drucken nicht einfach durch und ignoriert ihn ansonsten? Nein, denn wenn in einer EPS-Datei Sonderfarben definiert sind wie hier Füllung, dann werden diese Farben zu den Dokumentfarben hinzugefügt, samt Name natürlich!

Wie ist nun FrameMaker 7.2 mit dem Windows-codierten Füllung umgegangen? Na, schlecht, denn das ü mit dem Bytewert 252 bedeutet für das FrameRoman-Encoding eine Cedille, folglich erschien in der Dokument-Farbliste auch F¸llung.

Für FrameMaker 8 und FrameMaker 9 ist das Byte 252 aber zunächst ein ungültiges UTF-8-Byte, es schlägt aber nur zu Buche, wenn ein Dialog angezeigt wird, der eine Farbauswahl enthält, d.h. die Absatz-, Zeichen- oder Tabellengestaltung. Ohne diese Dialoge gibt es keine Probleme, aber das ist natürlich keine Lösung.

Lösungsansatz

Da derartige Icons in sehr vielen Dateien verwendet sein könnten, habe ich der Redaktion vorgeschlagen die betroffenen alten Dateien zu identifizieren und dann mit einem leistungsfähigen Texteditor nach Nicht-ASCII-Zeichen in Farbnamen zu suchen und bytegetreu zu ersetzen, aus dem ü eben einfach ein u zu machen. Bytegetreu deshalb, weil die geheimnisvollen Zeichen in der ersten Zeile der EPS-Datei einen Verweis auf die am Ende der Datei mitgespeicherte Bildschirmvoransicht enthalten, solche Verweise vertragen keine Änderung des Dokuments dazwischen.

Fazit

Für mich ist dies damit kein FrameMaker-Fehler, auch wenn es natürlich schöner wäre, das Produkt würde diesen Fehler eines anderen Programms nicht mit einem Absturz quittieren.

Aber es werden nicht viele Anwender noch derart alte, unkorrekt erstellte EPS-Dateien im Einsatz haben. Oder doch?

Dieser Beitrag wurde unter FrameMaker veröffentlicht. Setze ein Lesezeichen auf den Permalink.

4 Antworten zu Altlasten mit ü

  1. Thomas BÖTTIGER sagt:

    Und wenn man nun die alten EPSe mit einem aktuellen Grafikprogramm öffnet und wieder speichert? Das lässt sich auch Batchen.

  2. Ja, das dachte ich auch. Aber ein Test mit der betreffenden FreeHand-Datei ergab, dass diese sich mit Illustrator zwar völlig problemlos öffnen und erneut speichern ließ, danach aber andere Werte in der Bounding Box standen, was dazu führt, dass die Grafik im FrameMaker-Dokument versetzt auftauchte. Abgesehen davon, dass sich auch die Regeln für die Bemessung der Bounding Box geändert haben.

  3. Helge Blischke sagt:

    Nach der DSC Spezifikation muss ein Text-Element in Klammern nur der PostScript-Syntax für Strings genügen, und da sind beliebige 8-Bit-Codes (exakt: Repräsentationen von ganzen Zahlen zwischen 0 und 255) erlaubt, also auch ein mac-roman-codiertes ü.

    Da ich vermute, dass das FM9 GUI im wesentlichen auf den C++-Klassen von Microsoft beruht, muss man denen den Vorwurf der schlampigen Programmierung machen.

  4. Nun, der Effekt tritt auch ohne das FM9-GUI bei FM8 auf, alle späteren Versionen von FreeHand kodieren Umlaute oktal, hmm.

    In meinem PostScript Language Reference Manual, Second Edition (1990) steht auf S. 638 für derartige Namen: »Special characters can be denoted using the PostScript language string \ escape mechanism.« Und auf S. 39: »To enhance program portability, strings appearing literally as part of a PostScript language program should be limited to characters from the printable ASCII character set, with other characters inserted by means of the \ddd escape convention.«

    Jede W3C-Empfehlung wäre präziser, aber ich lese das »can« und »should« hier entsprechend der aufgeführten Beispiele als »sollten«. Was Ihr Argument mit der schlampigen Programmierung nicht wirklich schwächt, denn abstürzen sollte das Produkt deswegen keinesfalls.

Kommentare sind geschlossen.