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?

1989-01			2.0
1992-05			4.0
1992-06	3.0
1992-11				2.5
1993-06		1.0 (PDF 1.0)
1993-09	4.0
1994-09		2.0 (PDF 1.1)
1994-11				3.0
1995-xx			4.1
1995-11	5.1
1996-01	5.12
1996-11		3.0 (PDF 1.2)		4.0
1997-05			7.0	5.0
1997-08	5.5
1998-09			8.0
1998-10	5.5.6
1999-02				5.5
1999-04		4.0 (PDF 1.3)
2000-04	6.0
2000-06			9.0
2000-09				6.0
2001-01		5.0 (PDF 1.4)
2001-11			10.0
2002-03				7.0
2002-07	7.0
2003-07		6.0 (PDF 1.5)
2003-10			11 (PDF 1.5)	8.0	CS
2003-12	7.1
2005-01		7.0 (PDF 1.6)
2005-04			12	9.0	CS2
2005-09	7.2
2006-11		8.0 (PDF 1.7)
2007-04			13	10.0	CS3
2007-07	8.0
2007-09					TCS1
2008-05	8.0.4
2008-07		9.0 (PDF 1.7)			TCS1.3
2008-10			14	11.0	CS4
2009-01	9.0				TCS2
2010-01		9.3
2010-04			15	12	CS5
2010-06	9.0.4
2010-08		9.3.4

Quellen:

• http://www.daube.ch/docu/fmhist00.html
• Wikipedia: FrameMaker
• Wikipedia: Acrobat
• Wikipedia: Illustrator
• Wikipedia: Photoshop
• Wikipedia: TCS

Ich stimme dem vollinhaltlich zu, aber wie überträgt man das einigermaßen griffig ins Deutsche? Mit diesem Motto könnte ich eventuell auf der tekom-Tagung im November auftreten…

PS: Google hilft nicht weiter, hier wird aus »There’s always a way to do something that can’t be done in FrameMaker in FrameMaker.« nämlich Es gibt immer einen Weg, um etwas, das nicht in FrameMaker können in FrameMaker getan werden kann. Hmm,… nicht ganz falsch…

http://my.adobe.acrobat.com/newintcs2dot5/

Captivate 5 wurde komplett neu geschrieben (und ist jetzt auch für Mac OS verfügbar), während Photoshop CS5 »nur« mit Funktionserweiterungen, darunter dem vielfach vorgeführten »inhaltssensitiven Füllen« (»content-aware fill«) glänzen kann.

Im Gegensatz zum vorherigen Patch-Release 9.0.3 (auch als 9.0p250 bekannt) sind die in den Release Notes erwähnten vier Punkte wohl hinreichend für den Schritt von Build 250 auf 255 (9.0p255), dürften aber nur Automatisierer betreffen, insbesondere rund um die DITA-Spezialisierung, betreffen. Bei den Einträgen, die mit FA_Note_ beginnen, handelt es sich um Ereignisse, die FrameMaker intern verwendet, die man aber auch per Programmierung (FDK oder FrameScript) abfangen kann. Im Fall 2. gab es Programmierer, die vor dem Schließen eines Buchs (PreQuitBook) gerne noch Dokumente oder Bücher gespeichert hätten, die aber mit dem Befehl F_ApiSimpleSave nicht machen konnten. Und so weiter.

Auch wenn die Änderungen nicht spektakulär zu sein scheinen, zeigen sie doch, dass Adobe Add-on-Programmierer ernst nimmt, nicht zuletzt entsteht so in der Regel ein flüssiger Prozess.

Sie erhalten das Update entweder über die interne Update-Funktion oder auf der Download-Seite.

1. Earlier FrameMaker used to crash if FA_Note_QuitModelessDialog notification was registered, and user tried to close Cross Reference dialog, Marker dialog or Variable pod. This has been fixed now.
2. F_ApiSimpleSave() now works fine in the FA_Note_PreQuitBook Notification.
3. Now FrameMaker should close normally when FA_Note_DisplayClientXRefDialog notification is registered.
4. FrameMaker now works fine while executing “Go To Source” command on XRef when FA_Note_PreGoToXrefSrc notification is registered.

Diff, Change Tracking, Änderungsverfolgung… you name it…

Es gibt mehrere Gründe warum jemand gerne sehen möchte, wo in einem Dokument welche Änderungen gemacht wurden:

• Der Leser möchte bei einem Update die Stellen mit Änderungen gegenüber seiner letzten Version des Dokuments sofort erkennen
• Der Korrektur-Leser möchte die Stellen mit Änderungen seit dem letzten Korrekturlauf erkennen
• In den Übersetzungsprozess sollen nur Abschnitte mit Änderungen geleitet werden

Den letzten Fall möchte ich hier einmal ausklammern, auch wenn dessen wirtschaftliche Relevanz nicht unterschätzt werden darf. Aber hierfür sind eine Vielzahl weiterer Prozessfragen zu klären.

Die ersten beiden Punkte bieten Raum genug. Zum Beispiel, wenn wir Versionssprünge für bestimmte Sprachen oder Produktvarianten unterstellen. Wenn also nicht in allen Sprachen oder Produktvarianten die gleichen Änderungen angezeigt werden sollen (Äa = Änderungsanzeige):

Wenn Sie dies noch kombinieren mit gesonderter Änderungsanzeige für verschiedene Korrekturleser… dann ist es kein Wunder, dass dies heute nicht oder nur selten stattfindet. Und wenn, dann mit recht hohem Zeitaufwand.

Aber es geht! Mit FrameMaker!

In einem aktuellen Projekt habe ich folgendes umgesetzt:

• zwei beliebige XML-Fassungen eines Handbuchs werden mit Hilfe eines XML-Tools verglichen
• das XML-Ergebnis mit Änderungsmarkierungen wird für FrameMaker aufbereitet
• es entsteht ein FrameMaker-Buch mit FrameMaker-Änderungsmarkierungen, die auf Wunsch noch nachbearbeitet werden können

Im Detail:

Es gibt viele Werkzeuge, mit denen Textdateien oder sogar XML-Dateien vergleichen werden können. Aber erst 2009 fand auch eines, dass Änderungsmarkierungen auch in einem XML-Dokument speichern kann. Dies erfolgt mit Hilfe von Processing Instructions, so dass die XML-Datei nicht durch neue Elemente oder Attribute von vornherein ungültig wird. Dem Werkzeug fehlten noch einige Funktionen, die wir für den Vergleich von Dokumenten benötigen, zum Beispiel den Vergleich auf Textebene. Mittlerweile gibt es eine Version 2.0 von XML Tree Compare zum Testen auf http://www.xmldifftool.com/.

Eine Aufbereitung des Outputs von XTC ist nötig, da FrameMaker Änderungsmarkierungen auf ganz bestimmte Art und Weise erwartet. Zudem bietet die Aufbereitung auch die Möglichkeit, bestimmte technisch motivierte Änderungen zu ignorieren. Da es sich um eine XML-Datei handelt, erfolgt diese Anpassung per XSLT.

Integriert wird das Ganze mit einem Skript, so dass der Vorgang für den Anwender problemlos ist. FrameMakers Einschränkungen im Zusammenhang mit der Änderungsverfolgung werden dabei weitgehend behoben.

Und das Dokument mit Änderungsanzeige kann anschließend mit der Symbolleiste Textänderungen nachverfolgen nach Änderungen durchsucht werden. Wenn gewünscht können auf diese Weise banale Änderungen noch akzeptiert werden. Abgebildet sind hier das alte, das neue und das Dokument mit Änderungsanzeige.
(Für große Darstellung bitte anklicken und mit Pfeiltasten zwischen den Bildern wechseln)

Wenden Sie sich an mich, wenn Sie dies auch für Ihre FrameMaker-Publikationen einsetzen wollen!

• Thomas Merz’ Bücher bei pdflib.com

Mein Thema sind Schaltflächen, mit denen zum Beispiel der Druck bestimmter Seiten einer Anleitung für den Anwender komfortabel gestaltet werden kann. Das sieht dann gewöhnlich so aus, wie rechts im folgenden Bild:

Wenn aber mehr gewünscht wird, wie zum Beispiel eine grafische Gestaltung des Hintergrunds oder der ganzen Schaltfläche (wie links), dann muss man etwas tiefer einsteigen. Natürlich nur, wenn diese Schaltfläche im PDF nicht gedruckt werden soll, denn sonst könnte man das Erscheinungsbild schon in FrameMaker hinzufügen und eine unsichtbare Schaltfläche darüber legen.

Um den Druckdialog wie oben abgebildet (anklicken für größere Darstellung) mit einem vorbelegten Seitenzahlbereich zu öffnen, muss übrigens JavaScript erlaubt sein, denn der Befehl dazu lautet für die Seiten 3 bis 4:

this.print(true, 2, 3);

Meine Lösung dazu ist aktuell ein Skript mit einer Konfigurationsdatei, in der nicht nur verschiedene Schaltflächen, deren Größe und Position(en) auf der Seite (in verschiedenen Seitenformaten), sondern auch noch frei wählbare EPS-Dateien als Schaltflächen-Bilder einstellbar sind.

Bei dieser Gelegenheit fallen noch ein paar Tipps für die EPS-Erstellung aus Illustrator ab, mit denen sich die Dateigröße stark verringern lässt:

• Alle nicht benutzen Farbdefinitionen löschen (Alle Farbfeldarten einblenden, Auswählen aller nicht im Bildmaterial verwendeten Farbfelder, Löschen), siehe Farbfeldbedienfeld
• Alle nicht benutzen Stile löschen (Auswählen aller nicht verwendeten Grafikstile, Löschen), siehe Grafikstilebedienfeld
• Möglichst Kopie als Illustrator 3 speichern (dabei werden auch ausgeblendete Ebenen entfernt)

Zum genannten Thema gibt es am Freitag 16.4.2010 ein kostenloses E-Seminar mit Stefan Gentz, einem ausgewiesenem Spezialist für Übersetzungs-Technologie. Aus dem Ankündigungstext:

[…] erfahren Sie, wie Sie als Technischer Autor oder Grafiker/Designer Dokumente so vorbereiten können, dass sich Ihre FrameMaker- oder InDesign-Dokumente optimal durch moderne Übersetzungsprozess führen lassen. Stefan Gentz verrät Ihnen zehn einfache aber höchst effektive Tipps & Tricks, mit denen Sie sich viel Geld, Zeit und Ärger sparen können. Ihr Übersetzungsdienstleister wird Sie dafür lieben.

Bitte hier anmelden: http://www.adobe-eseminars.de/signup-477.htm

1. Entwurf und Optimierung einer Konvertiertabelle: Hier wird für jedes FrameMaker-Objekt ein entsprechendes Element festgelegt
2. Anwenden dieser Konvertiertabelle: Wenn Sie bei 1. gründlich waren, entstehen Dokumente mit einem definierten Highest Level Element
3. Laden der gewünschten Elementdefinitionen
4. Reparieren aller noch vorhandenen Fehler

Letzteres wird zum Beispiel nötig, wenn Abbildungen und Warnmeldungen bislang mit Tabellen aufgebaut waren, dies aber im strukturierten Template nicht mehr der Fall ist. Da können sehr viele Aktionen anstehen.

Bislang habe ich in solchen Fällen Skripte geschrieben, jetzt aber mache ich das mit dem Plug-in FrameSLT und dessen Funktion Node Wizard Scripts. Es handelt sich hier um XPath-basierte Element- und Attributaktionen, die nahezu jegliche Modifikation der Dokumentstrukturen erlauben. In einem aktuellen Projekt (ca. 1.200 Seiten, 32 Kapitel) waren es einmal über 20.000 Aktionen:

Bei solchen Volumina ist ein C-Plugin auch signifikant schneller als ein Skript es wäre! Aber das allerschönste ist die Notation der Aufgabenstellung mit XPath-Ausdrücken, die damit eine wunderbare Präzision bekommen.

• FrameSLT auf fminit.eu

Als alter Hase war mir (und anderen) eine Besonderheit von FrameMaker schon lange in Fleisch und Blut übergegangen: Sobald ein Wort in Kontakt mit einem Sonderzeichen, insbesondere dem geschützten Leerzeichen (Strg+Lz) kam, wurde es für die automatische Silbentrennung nicht mehr berücksichtigt.

Am Rande bemerkt: Über die Qualität jeglicher Silbentrennungsalgorithmen kann man durchaus verschiedener Meinung sein…

Im Rahmen der Tests der Unicode-fähigen Version 8 war mir aufgefallen, dass sich das geschützte Leerzeichen auf zwei Arten erstellen lässt: Wie bisher mit Strg+Lz und zusätzlich mit dem typischen Windows-Kürzel Alt+0160. Allerdings unterschieden sich die die Darstellungen im Dokument, denn letzteres war nicht als Steuerzeichen zu erkennen, verhielt sich aber dennoch korrekt.

Jetzt wurde, ein klein wenig zufällig, im Forum bei hilfdirselbst.ch entdeckt, dass sich nicht nur das Erscheinungsbild im Dokument sondern auch die Auswirkung auf die Silbentrennung unterscheidet:

Bei der Verwendung von Alt+0160 werden Worte getrennt!

Ich hatte vergessen, dass ich das seinerzeit schon in Testdokumenten bemerkt hatte, siehe Screenshot mit nachträglich hervorgehobenen Alt+0160-Leerzeichen:

Die beiden Versionen des umbruchgeschützten Leerzeichens werden auch im Dialog Suchen/Ändern unterschieden: Das alte suchen Sie mit Backslash Leerzeichen (\ ), das neue geben Sie per Alt+0160 ein. Auf diese Weise können Sie das eine durch das andere ersetzen. In der MIF-Datei werden beide Zeichen unterschieden, d.h. sie überleben Übersetzungsprozesse. Beim Speichern als XML wird aus beiden das korrekte Unicode-Zeichen \u00A0 und beim Öffnen der XML-Datei dann (leider) das alte FrameMaker-Zeichen (analog Strg+Lz). Was sich bei Bedarf modifizieren ließe.