Vielleicht hilft ein kleiner Blick darauf, wie das Tool funktioniert. Alleine durch das Studium der mit Business-Lingo überfrachteten Webseiten wird das nicht ohne Weiteres klar.

Begonnen hat Miramo mit der Aufbereitung von Datenbank-Exporten in Textform. Diese wurden durch das Tool aufbereitet und schließlich mit einem FrameMaker-Template (einem leeren MIF-Dokument) zusammengeführt um so ein gefülltes Dokument zu erstellen. Etwas zeitgemäßer ist die Verwendung von XML als Ausgangsformat, wofür es auf der Webseite tatsächlich ein konkretes Beispiel gibt:

< ?xml version="1.0" encoding="UTF-8" ?>
<MiramoXML Tfile="template.mif" Opdf="output.pdf" >
  <P format="bodyText">Hello World</P>
</MiramoXML>

Dieses MiramoXML wird zum Beispiel mit einer XSL-Transformation erstellt und enthält letztlich den gewünschte FrameMaker-Textfluss – also die Reihe von Absätzen mit allen enthaltenen Texten, Formaten, Tabellen, Abbildungen. Dahinter steckt eine gewisse einmalige Fleißarbeit, das Ergebnis ist ein ziemlich performantes System, mit dem sich den Regeln entsprechende formatbasierte FrameMaker-Dokumente erstellen lassen. Die können anschließend mit FrameMaker weiter bearbeitet oder (über FrameMaker und Distiller) als PDF gespeichert werden.

Die Konkurrenz

Der natürliche Konkurrent dieses Verfahrens sind XSL-FO-Prozessoren, bei denen der manuelle Eingriff wegfällt und dafür auch keine FrameMaker-Lizenz benötigt wird. Zudem sind die kommerziellen Versionen dieser Prozessoren günstiger, erst recht wenn man zu Miramo auch noch einen Lizenz für FrameMaker Server hinzurechnet. Vor daher ist Miramo also unter Druck.

Aber was ist mit der tollen Leistungsangabe auf http://www.miramox.com/?

Using Adobe’s high-end DTP package FrameMaker®, Miramo can produce documents at a rate of tens of thousands of pages per hour or over a million pages overnight.

1.000.000 Seiten pro Nacht sind bei einer großzügig berechneten Nacht von 16 Stunden immer noch 62.500 Seiten/Stunde. Ich durfte einmal ein hochgezüchtetes PDF-Publishing-Verfahren mit mehreren parallel arbeitenden FrameMaker-Instanzen bewundern, welches aus XML-Daten ca. 2.000 PDF-Seiten pro Stunde produzieren konnte. Bei den Miramo-Zahlen kann es sich folglich nur um die Zurverfügungstellung von FrameMaker-Dokumenten mit dem erwähnten Seitenumfang handeln. Marketing-Lingo also, das verschatten will, dass es völlig unmöglich ist, solche Volumina a) manuell nachzubearbeiten und b) auch nur annähernd in dieser Geschwindigkeit über PostScript und Distiller nach PDF zu speichern.

Ein einzelner XSL-FO-Prozessor kann auf Basis eines Praxistests mit einem durchschnittlichen Handbuch ca. 100–150 Seiten/Minute, also 6.000 Seiten/Stunde produzieren.

Mein Fazit

Wenn also die Informationen bereits in XML vorliegen und wenn große Volumina als PDF publiziert werden sollen, warum sollte jemand auf eine proprietäre Lösung wie Miramo mit FrameMaker und Distiller setzen, statt XSL-FO einzusetzen, wo es sogar die Auswahl zwischen verschiedenen Tool-Anbieter gibt (Apache FOP, Antennahouse Formatter, RenderX XEP)?

Aha, deshalb ist Miramo PE kostenlos…

(Original von Sarah O’Keefe)

Eine Standardfrage, die mir und auch sicher Ihnen immer wieder begegnet, lautet: »Welche Software soll ich verwenden?«

Das ist, nicht nur in der Technischen Dokumentation, die falsche Frage! Wenn Sie nach danach fragen, landen Sie sofort im dunklen Rattenloch von Bedienbarkeit der Software, Langlebigkeit des Herstellers, Betriebssystemunterstützung.

Eine bessere Frage wäre: »Wie bringe ich meine Informationen am besten an den Kunden?«

Leider ist auch diese Frage schwer zu beantworten und die Antwort wechselt von Jahr zu Jahr. Mit dem Altern des CHM-Formats wurde Browser-Hilfe immer angesagter, jetzt ist es vielleicht ePUB, nächstes Jahr dann HTML5?

Wenn Sie also nicht einmal genau wissen, welche Ergebnisse benötigt werden, sich zudem die Anforderungen ändern, wie können Sie da eine Software auswählen? Eben, es geht nicht.

Die Frage muss anders gestellt werden:
»Wie können Informationen gespeichert werden, um damit aktuelle und zukünftige Anforderungen zu erfüllen?«

Und die Antwort darauf lautet: XML.

Mit einem XML-basierten Workflow stehen Sie nicht vor der Qual der Wahl des besten Werkzeugs. Wenn ein Werkzeug nicht mehr das richtige sein sollte, nehmen Sie Ihre Daten und ziehen weiter zum nächsten. Sie müssen auch nicht schon heute wissen, welche Ausgabeformate Sie einmal brauchen werden. Egal ob XHTML, Browser-Hilfe, HTML5, PDF, ePUB, oder ein heute noch nicht benanntes Format – aus den XML-Daten können Sie all diese Formate erzeugen.

Dieses Vorgehen steht natürlich im Konflikt mit dem Geschäftsmodell vieler Autorenwerkzeuge. Die Softwarehersteller haben ein großes Interesse daran, Sie möglichst langfristig an sich zu binden. (Und: Berater könnten ein Interesse an komplexen Lösungen haben, die nur mit deren Hilfe implementiert werden können.¹)

Wenn Sie also eine Software mit einem hohen Bindungseffekt wählen (im Original: »lock-in«, siehe Lock-in-Effekt, legen Sie Ihre Publikationsstrategie in die Hände des Softwareherstellers. Ihre Strategie würde in erster Linie bestimmt von den Einschränkungen der Software bzw. von den Ideen des Herstellers.

Meiner Meinung nach müssen Sie anders vorgehen: Erst wählen Sie Ihre Strategie, dann suchen Sie nach dafür geeigneten Werkzeugen.

Dieses Vorgehen ist zwar nicht einfacher als die falsche Frage zu stellen und irgendwie zu beantworten, aber mittelfristig wesentlich Erfolg versprechender.

¹) Das könnte auch mich betreffen…
Foto: Thommy Weiss / pixelio.de

Kollege Marc Achtelig hat auf seiner empfehlenswerten Webseite http://www.indoition.com die Links zu wertvollen Informationsquellen zu den Themen Normen, rechtliche Anforderungen, Rechtsfragen, Gesetze, Gesetzgebung ergänzt:

• Links zu Normen und Rechtsfragen

Wussten Sie, dass Sie sämtliche Informationen aus dem Abschnitt Know-how seiner Webseite in deutsch und englisch auch als e-Book (so nennt man das heute), sprich als PDF-Datei, kostenlos laden können? Besuchen Sie die Seite, Sie finden den Link in der Navigation mit diesem Bild:

PS: Betrachten Sie es als Nikolaus-Gabe…

Gleichzeitig wird das dabei auch um die Adobe Technical Communication Suite 2.5 gehen, das aktuell erschienene Update des Programmpakets.

Der deutliche Zuwachs an Nachfragen nach XML-strukturierten Dokumenten ist der Anlass für meinen Beitrag auf dieser Veranstaltung:

»DITA Hype Cycle« – ein Erfahrungsbericht

Da die Anzahl der Teilnehmer begrenzt ist, sollten Sie gleich überlegen, ob nicht drei Tage nach dem Finale der Fußball-WM ein guter Zeitpunkt für einen Informationsnachmittag wäre: 14.7.2010 16:30–20:00 Uhr in Nürnberg bei Squidds!

Für eine detaillierte Beschreibung der Veranstaltung klicken Sie bitte auf das Banner oben oder hierher. Drucken und faxen Sie dann einfach dieses Anmeldeformular, um sich Ihren Platz zu sichern.

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. Texte erstellen mit strukturiertem FrameMaker
2. Speichern als XML
3. Transformation der XML-Datei ins gewünschte Hilfeformat

Alles natürlich zusammengehalten von ein paar Skripten (wie in meinem Projektbericht beschrieben). Was man sonst noch alles Dank des XML-strukturierten Prozesses erreichen und produzieren kann, wird an anderer Stelle erwähnt, denn diesmal geht es um Anwender, die aus guten Gründen nicht meinen Lieblingsprozess anwenden (können). Diese Anwender brauchen in aller Regel ein oder mehrere Programme zur Erstellung der Onlinehilfe und die umfangreichste Sammlung solcher Tools hat Marc Achtelig zusammengestellt.

Frisch aktualisiert wird auf über 100 Seiten (in deutsch oder englisch) grundlegendes Know-how zur Technischen Dokumentation vorgestellt:

• Grundlagen
• Nützliche Software
• Nützliche Webseiten

Ob Sie nun vor der Aufgabe stehen selbst ein Tool auswählen zu müssen, ob Sie Kriterien für eine solche Auswahl finden (und keine relevanten übersehen) wollen, oder ob Sie Marc Achtelig mit alldem beauftragen wollen: Laden Sie sich diese Informationsquelle!

• http://www.indoition.com/de/online-help-authoring-tools-uebersicht.htm

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?

Seit 2004 betreibt er sein eigenes Unternehmen Saxonica rund um eine kostenpflichtige Version von Saxon, die über die vom Standard geforderten Basisfunktionen hinaus weitere Leistungsmerkmale bietet, zum Beispiel Schema-Validierung und das Streaming großer XML-Dateien.

Dennoch reichen vielen Anwendern die Möglichkeiten der Basis-Version (»Saxon-B«) völlig aus und auch in meinen XSLT-Projekten setze ich auf Saxon. Meine primären Gründe sind:

• XSLT 2.0
• Hervorragende Fehlermeldungen
• Performance, Performance, Performance
• plattform-übergreifende Verfügbarkeit

Im durchaus verständlichen Bestreben, die Entwicklungsaufwendungen nicht nur durch Lizenzzahlungen von Großkunden zu kompensieren, hat Michael Kay mit dem Erscheinen der Version 9.2 die Produktkonfiguration geändert. Dies sind kurzgefasst die Unterschiede (Quelle):

Welche Version verwenden?

In vielen Projekten, in denen XML zu HTML konvertiert wird, ist scheint es völlig ausreichend zu sein mit Saxon Home Edition zu arbeiten. Mich erinnert die Namensgebung aber auch daran, dass Saxon von meinen Kunden in wichtigen Produktionsprozessen verwendet wird — würde da eine »Home Edition« nicht etwas seltsam wirken?

Wie so oft geht es nicht so sehr darum, was eine Lösung heute kostet, sondern darum, welche Probleme entstehen können, wenn man nichts investiert (wobei £50 nicht gerade nach Investition klingen): Mit den kostenpflichtigen Versionen geht Saxonica eine Verpflichtung gegenüber den Kunden ein, darunter:

• Support mit höherer Priorität
• Fehler-Korrekturen auch für ältere Versionen

Die Liste der technischen und kommerziellen Gründe, die für Saxon Professional Edition oder Saxon Enterprise Edition sprechen, finden Sie detailliert auf meinen Service-Seiten beschrieben:

• Lizenzbeschaffung Saxon

Sprich: Saxon Professional Edition bin ich mir selbst schuldig , und ich werde es auch in Kundenprojekten verwenden. Und auf Wunsch auch die Lizenzbeschaffung übernehmen, das ist ja nichts Neues für mich (siehe FrameScript).

[…] in den vergangenen Monaten [habe man] ein neues, SAP-basierendes Reklamationsmanagementsystem eingeführt, das wohl noch nicht in allen Fällen optimal arbeitet.

Die Berichte über aufwändige, langwierige SAP-Einführungen sind Legion. Sie sollten aber auch eine Mahnung sein für jeden, der meint, ein — und hier komme ich zu meinem Thema — Redaktionssystem ließe sich so nebenbei, möglicherweise binnen Wochen auswählen und einführen.

Das Gegenteil ist der Fall und auch gar nicht ungewöhnlich. Bevor man sich zu einer derartigen Investition — ab ca. €100.000 für zehn Arbeitsplätze — samt Folgekosten durchringt, ist es nur vernünftig, vorher sowohl über die angebotenen Systeme als auch über die eigenen Anforderungen möglichst präzise Bescheid zu wissen. Wer die eigenen Vorgaben nicht kennt, dem wird von jedem Systemanbieter natürlich etwas vorgeschlagen, was dessen System entgegen kommt. Und wer die prinzipielle Funktionsweise der Systeme nicht vorher kennt, wird möglicherweise beim ersten Einsatz überrascht den Unterschied zwischen Verkaufsgespräch und Realität feststellen.

Die eigenen Anforderungen

Die eigenen Anforderungen an die Dokument-Strukturierung (ja: XML), die benötigten redaktionellen Prozesse, eventuelle Workflow-Funktionen, die Kenntnis darüber, welche Prozesse häufig vorkommen (und deswegen leicht erreichbar sein sollten) oder welche, weil selten gebraucht, ruhig etwas umständlicher sein dürfen — all dieses sollte ein Interessent kennen, bevor er mit Systemanbietern verhandelt. Dabei kann die Unterstützung durch externe, anbieterunabhängige Fachleute nützlich sein, schließlich zählt die Auswahl eines Redaktionssystems nicht zu den Standardaufgaben einer Redaktion. Und auf jeden Fall sollte eine Teststellung des in die engere Auswahl gekommenen Systems eingeplant werden, selbst wenn das Geld kostet; ein paar Prozent der Investitionssumme sind hier sinnvoll angelegt!

Das geeignete System

Um einen Überblick über einige Systeme zu erhalten, können sie demnächst eine »Vergleichsveranstaltung« in Hamburg besuchen. Vom Verbund Technischer Redaktionen in Norddeutschland (DokuNord) wird am 9.9.2009 ein XML-Forum organisiert, bei dem unter der Moderation von Prof. Dr. Wolfgang Ziegler vier Redaktionssysteme verglichen werden: Schema ST4, FCT TIM-RS, Docufy Cosima, Ovidius TCToolbox.

Wenn Sie also am 9.9.9 9h nicht auf eine Hochzeit eingeladen sind und in Ihrer Firma über die Einführung eines Redaktionssystems nachgedacht wird, dann laden Sie sich bitte die Einladung von Ulrike Parson (Mitglied bei DokuNord und CAP-Studio-Kooperationspartner, http://www.parson-com.com/) und melden Sie sich zu dieser Veranstaltung an.

Nachbemerkung

Falls Sie heute noch nicht XML-strukturiert arbeiten und sich für Redaktionssysteme interessieren, empfehle ich ein zweistufiges Vorgehen: 1. Zunächst umsteigen und XML-strukturiert arbeiten (z.B. mit FrameMaker aber ohne großes System), um herauszufinden, welche XML-Strukturen tatsächlich benötigt werden. Und dann 2. die Einführung eines Redaktionssystems vorantreiben. Die Redaktionssystem-Hersteller empfehlen in der Regel ein einschrittiges Vorgehen…