Am gestrigen Sonntag nahm ich an einer Fortbildung der Typographischen Gesellschaft München teil, die seit vielen Jahren neben Vorträgen auch Weiterbildungen anbietet. Diesmal ging es um die Arbeit mit dem führenden Font-Werkzeug FontLab.

Meine eigene Historie im Bearbeiten von Schriften reicht zurück ins Jahr 1990, als ich mit Altsys Fontographer (von Altsys stammte auch Freehand, dass aber von Aldus vermarktet wurde) einen Font mit Musiknotensymbolen namens Susato erstellte. Den brauchte ich für meine damalige Tätigkeit als Notensetzer, da mir die Adobe Sonata zu statisch/technisch für Liederbücher erschien. In späteren Jahren (vor Unicode!) habe ich dann noch Fonts ertüchtigt um slowakische Texte zu setzen, oder aus vielen Einzelschnitten (CE, CYR, Baltic) einen umfassenden Unicode-Font zusammengebaut. Ein zwischenzeitliches Update auf FontLab 3 hielt mich auf dem Stand der Technik, allerdings bin ich bislang das Upgrade zu FontLab Studio 5 nicht mitgegangen. Die Unterstützung für OpenType-Features lockt mich nun aber doch…

Abgesehen von den zahlreichen Fleißaufgaben, denen sich ein Schriftgestalter heute stellen muss (wie zum Beispiel das Mitliefern aller diakritischen Zeichen für sämtliche europäischen Sprachen, die auf dem lateinischen Alphabet beruhen), gehören dazu für den professionellen Einsatz in der Dokumentation natürlich auch kyrillische und griechische Glyphen. Trotz einer gewissen Verwandtschaft muss man dabei aber immer auch individuelle sprachliche Traditionen berücksichtigen, das heißt der Gestalter muss sich auch intensiv mit den jeweiligen Kulturen beschäftigen.

Nur ein Beispiel: In vielen Fällen (und in manchen Browsern auch automatisch) ist die Ligatur fi eine gute Wahl (es sei denn die Buchstaben fallen auf eine Silbengrenze). Aber nicht im Türkischen, denn dort wird zwischen i mit und ı ohne Punkt unterschieden und bei einer Ligatur fiele dieser Unterschied weg.

Diese und viele andere Besonderheiten machen Schriftsatz und Schriftgestaltung zu einem faszinierenden Gebiet. Für den Programmierer in mir stellt die Programmierung von OpenType-Feature eine weitere äußerst interessante Möglichkeit zur Optimierung von Schriftsatz dar. Lust habe ich sehr darauf, allein, mein primäres DTP-Programm FrameMaker verstünde dies nicht. Zu schade! Ob wir in Zukunft hier Fortschritte sehen werden?

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

Seit der Einführung von FrameMaker 9 im Januar 2009 ist mittlerweile genügend Zeit vergangen, es hat drei Patch-Releases gegeben, auch auf der tekom-Tagung im November 2009 in Wiesbaden wurden etliche Lösungen mit FrameMaker 9 vorgestellt. Es gibt also konkrete Projekte und Erfahrungen zu berichten. Als Baustein in teilweise recht komplexen Dokumentationsprozessen steht FrameMaker nicht allein im Raum, sondern ist auf passende Tools angewiesen. Daher gibt mein Beitrag bei der tekom Regionalgruppe Nürnberg auch einen Überblick über Software, die FrameMaker-basierte Prozesse ergänzen kann.

Die Veranstaltung findetfand statt am 25.2.2010 ab 18 Uhr bei

VCS Video Communication Systems AG, Bosch Group
Nordring 69
90409 Nürnberg

und ist kostenlos; es wird um eine Anmeldung bei abortolot@gmx.de gebeten, damit der Platzbedarf abgeschätzt werden kann.

Nachwirkung

Nach meiner Präsentation kam die Frage auf, ob FrameMaker 9 denn nun auch fernöstliche Zeichen in Dateinamen im Buch darstellen könnte? Beim Live-Versuch einer Umbenennung einer Datei im FrameMaker-Buch scheiterte das. Aber prinzipiell geht es, vielleicht eben nicht Umbenennung, aber doch die Anzeige des Dateinamens (a) genauso wie des ersten Absatzes (b).

Heute kamen die Vortragsbewertungen zur tekom-Herbsttagung 2009, deutlich später als in den vergangenen Jahren — mit der Ausnahme 2008, als sie ausfielen. Auf Basis des neuen Bewertungsschemas (anklicken für eine etwas größere Darstellung) mit Werten zwischen 1 = sehr gut und 7 = sehr schlecht freue ich mich ganz außerordentlich über Durchschnitte zwischen 1 und 2. Vielen herzlichen ♥ Dank für Ihre Wertschätzung!

XPath: XML-Dokumente effizient nutzen

Teilnehmerzahl: 65 (1 = sehr gut / 7 = sehr schlecht)

Referent/in Gesamteindruck: 1,17
Inhalt (Durchschnitt): 1,77
Qualität (Durchschnitt): 1,29
Neutralität (Durchschnitt): 1,79
Gesamtbewertung (Durchschnitt): 1,33

Typographie in chinesischen, japanischen, koreanischen Texten

Teilnehmerzahl: 80 (1 = sehr gut / 7 = sehr schlecht)

Referent/in Gesamteindruck: 1,32
Inhalt (Durchschnitt): 1,88
Qualität (Durchschnitt): 1,37
Neutralität (Durchschnitt): 1,70
Gesamtbewertung (Durchschnitt): 1,43

—

PS: Ich hatte übrigens den Eindruck, der XPath-Vortrag sei stärker besucht gewesen, aber so kann die Raumgröße täuschen.

• Vortragsankündigung
• Vortragsunterlagen

Geht es Ihnen auch so? Als »knowledge worker« kann ich meinen Kopf ja nicht abschalten, nur weil eine Uhr 17:30h anzeigt und es Freitag ist. Und so begegnen mir auch in der Freizeit Dinge, die mich an meine Berufstätigkeit erinnern. Zum Beispiel heute Vormittag in einem Kreuzworträtsel diese wunderschöne Vorgabe:

Konsequenz kontrollierten Anspruchsdenkens

die sich mit ein paar helfenden Buchstaben auflösen ließ zu Qualität. Wunderbar und vielfältig auf den Punkt gebracht, finde ich. Siehe auch

• Qualität bei Wikipedia
• KkA bei Google

Einschub: So dankbar ich für FrameScript bin, so gerne nutze ich für bestimmte Aufgaben auch »echte« C-Plug-ins mit FrameMaker, insbesondere mit strukturierten Dokumenten. Zum Beispiel AXCM, InsetPlus, FrameSLT…

Bei diesen Schulungen fällt immer wieder auf, dass FrameScript keine Deklaration der Variablen erfordert, man kann einfach schreiben

Set lvValues = MyFunction{};

und die Variable lvValues wird den Datentyp des Ergebnisses der Funktion MyFunction annehmen. Was einerseits sehr praktisch zu sein scheint, führt aber beim kleinsten Tippfehler im Namen einer Variable oft nicht zu einem gemeldeten Fehler, sondern schlicht zu unerwartetem Verhalten des Skripts. Tipps ich ein paar Zeilen weiter beispielsweise

Display lvValue;

bekomme ich diese wenig aussagekräftige Anzeige, weil ich das Plural-s beim Variablenbezeichner »vergessen« habe.

Es gibt aber eine Möglichkeit, solche Fehler melden zu lassen, und ich möchte heute dazu aufrufen, diese Möglichkeit sehr diszipliniert zu verwenden. Seit einigen Versionen gibt es die Session-Variable DeclareVarMode, die dazu verwendet werden kann, dass alle Variablen explizit entweder als Local oder als GlobalVar deklariert werden müssen. Folgende zwei Zeilen gehören in jedes Skript:

Set DeclareVarMode = True;
Set PlatformEncodingMode = True;

(Wegen der Rückwärtskompatibilität sind beide nicht standardmäßig gesetzt; den PlatformEncodingMode können Sie ignorieren, wenn Sie für FrameMaker 8 oder später im UTF-8-Mode programmieren.)

Und dann natürlich in jede Funktion oder Subroutine die entsprechenden Anweisungen Local oder GlobalVar.

Haben Sie das bereits ausprobiert? Wie sind Ihre Erfahrungen? Wie lange haben Sie schon nach Fehlern gesucht, nur um schließlich feststellen zu müssen, dass Sie sich bei einem Variablen-Bezeichner vertippt haben…

Konferenz-Tipp

Ich habe mich schon nach Ende der letztjährigen Konferenz (von der ich zu spät erfuhr) entschlossen, nach Möglichkeit die diesjährige Ausgabe der XMLPrague (13.+14.3.2010) zu besuchen, und zwar nicht weil Prag relativ nah liegt, sondern weil unter den Vortragenden einige quasi Bekannte waren, die mir vor allem in der xsl-list immer wieder mit hochkompetenten Beiträge aufgefallen sind. Die bekanntesten Namen sind in diesem Jahr wohl:

• Michael Kay: Herausgeber des XSLT-Standards und Schöpfer von Saxon
• Norman Walsh: »Vater« von DocBook

Aktuell wurde die Liste der Beiträge veröffentlicht, und schon allein von den Überschriften finde ich interessant:

• Ghislain Fourny »XQuery in the Browser (Demo)«
• Ari Nordström »Film Markup Language (Automating Cinemas Using XML)«

Nicht nur interessant, sondern auch sehr relevant für die Dokumentation scheinen mir diese Themen zu sein:

• Laurens Van den Oever »Tracking Changes: Technical and UX challenges«
• Felix Sasaki »How to avoid suffering from markup: A project report about the virtue of hiding XML«
• Stéphane Sire »Authoring XML all the Time, Everywhere and by Everyone«

Mir (und den Veranstaltern) ist klar, dass eine Konferenzankündigung weniger als zwei Monate vor dem Termin einige potentielle Besucher vor Terminprobleme stellt. Wenn Sie an den Themen allerdings interessiert sind, dann schauen Sie sich auf der Webseite einmal den Preis für die Konferenz an. Dazu gibt es das Tschechien-Spezial für den Expressbus der Deutschen Bahn von Nürnberg nach Prag… Wollen Sie mich begleiten?

http://www.xmlprague.cz/

Mit fast allen Tipps und Ratschlägen des Artikels bin ich einverstanden, auch wenn der Schlüssel von 10 Personentagen Aufwand für die Verschlagwortung von 100 Seiten jedem derartigen Ansinnen den Gar aus machen wird.

Ganz und gar nicht einverstanden bin ich mit Folgendem:

Wie viele Seitenverweise pro Eintrag soll es geben?
Empfehlung: Ein bis drei, maximal vier.

Das ist arg traditionell und stammt aus der Zeit, als man die Länge von Stichwortverzeichnissen schon aus Kostengründen beschränken musste und die Finger der linken Hand ausreichten, diese an bis zu vier Stellen zwischen die Seiten zu stecken, um dann deren Relevanz zu beurteilen.

Aber hallo! Ganz praktisch: Wie stecken Sie Finger zwischen die Seiten einer PDF-Datei oder Topics einer Onlinehilfe?

Und bezüglich Relevanz: Warum nennt uns der Autor/Verschlagworter denn nicht den Unterschied der verschiedenen Zielstellen? Diese Person kennt den Unterschied doch ganz genau! Und wenn es tatsächlich redundante Stellen sein sollten, dann reicht mir auch ein Verweis!

In meinen Augen kann es heute nur eine Regel geben:

Genau eine Zielstelle für jeden Eintrag im Stichwortverzeichnis!

Abgesehen vom Nutzen für den Leser in allen Medien funktioniert nur das ohne Handhabungsprobleme in Online-Medien.

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.

Je größer, desto besser? Eigenartige Nachrichten zu einem Y2010-Problem lesen wir in diesen Tagen, z.B. auf heise.de. Dahinter stecken die ca. 30 Millionen ausgelieferten Karten eines Herstellers. 30 Millionen, wow! Oder? Ein Programmierfehler, den weder die Qualitätskontrolle der Firma noch diverse Stellen auf Seiten der Banken erkannt haben. Hätten diese das erkennen müssen oder wiegten sich alle nach überstandenem Y2K-Wechsel in Sicherheit? Egal, was mich mehr erschüttert: Ich bin nicht überrascht, ganz und gar nicht!

Achtung, Verschwörungstheorie! Man muss als Unternehmen möglichst schnell eine »systemrelevante« Größe erreichen. Dann darf man die Gewinne ungestraft privat vereinnahmen, im Verlustfall werden diese dann von der Gesellschaft aufgefangen, sozialisiert. Ich sehe hier eine Aufgabe für die Kartellbehörden: Kann ein Konzern denn auch für den größtmöglich anzunehmenden Schaden gerade stehen?

Was hat das nun mit Dokumentations-Technologie oder FrameMaker zu tun?

Auch FrameMaker als Produkt einer großen Firma ist mit Fehlern behaftet, die sich im Rahmen dieser Firma anscheinend nicht zeitnah beheben lassen. Im Gegenzug gibt es rund um das Produkt ein Ökosystem von Einzelpersonen oder kleinen Teams, die mit scheinbar kleinen Lösungen gewaltige Produktivität ermöglichen — trotz der Fehler des Basisprodukts. Ich möchte vier solche Personen nennen:

• Scott Prentice (Leximation) mit u.a. seinem Plug-in DITA-FMx, welches DITA-Publishing für FrameMaker 7.2 und spätere Versionen ermöglicht.
• Frank Elmore (Elmsoft) und sein Plug-in FrameScript, welches mir und vielen anderen einen einfacheren Zugang zur FrameMaker-Automation ermöglicht hat.
• Jeremy Griffith (Omsys) und sein Plug-in Mif2Go, welches neben RTF und HTML auch XML hochgradig konfigurierbar exportieren kann.
• Klaus Müller (ITL), dessen Skripte für FrameMaker vielen die Augen geöffnet haben, wie weit FrameMaker-Automation gehen kann.

Ich wünsche Ihnen, meinen Lesern und den erwähnten Lösungsanbietern, einen guten Start in dieses Jahr!

(Bild: Gebhard Fugel, commons.wikimedia.org)