Herzlichen Glückwunsch zum Geburtstag!

Adobe Anniversary Website

Splash-Screens von http://www.guidebookgallery.org/splashes

seit 1993 bin ich im Bereich der Technischen Dokumentation als Spezialist für Dokumentationstechnologie tätig. In den letzten zwölf Jahren in erster Linie als FrameMaker-Experte, seit ca. 2005 kamen XML-basierte Prozesse mit und ohne FrameMaker hinzu.

Ab Januar 2012 werde ich die Firma DOCUFY GmbH in Bamberg als Berater verstärken. Mit dem Motto »Einfach gute Dokumentation« verfolgt DOCUFY seit 1998 das gleiche Ziel wie ich: die Optimierung Ihrer redaktionellen Prozesse. Für dieses Ziel hat DOCUFY das Redaktionssystem COSIMA erstellt und entwickelt es kontinuierlich weiter. Dieses System ist vollständig XML-basiert, vom Editor bis zur PDF-Produktion, und ist für mich damit die logische Fortsetzung meines Betätigungsfeldes.

Was bedeutet das für Sie bzw. meine bisherigen Geschäftsfelder? Ich werde Sie in aller Regel nicht mehr selbst unterstützen können, möchte Ihnen aber gerne helfen einen geeigneten Ansprechpartner zu finden. Melden Sie sich einfach per E-Mail und ich werde Ihnen gerne geeignete Kollegen empfehlen.

Vielen Dank für die bisherige Zusammenarbeit,
mit herzlichen Grüßen,


Michael Müller-Hillebrand

PS: Alle Informationen zu COSIMA finden Sie auf http://www.docufy.de/, auch die mich betreffende Pressemitteilung.

PPS: Um die FrameScript/ElmScript-Lizenzbeschaffung werde ich mich weiterhin kümmern, alle Infos dazu auf http://www.framescript.eu/

Nach weiteren fünf Monaten ist das zweite Patch-Release für FrameMaker 10 verfügbar. Fünf Monate sind seit dem Release vergangen und aus 10.0.1.402 wird 10.0.2.419.

• FrameMaker-Updates
• 10.0.2 Read me

Zu den Themen gehört in erster Linie die Unterstützung der lange versprochenen CMYK-Unterstützung.

Zum ersten Mal gibt es einen Updater, der die Patches 10.0.1 und 10.0.2 integriert. Daraus folgt (mit Dank an Georg Eck):

• 10.0.0.388 oder 10.0.1.402 ► 10.0.2.419
• 10.0.1.408 (aus TCS3.5) ► 10.0.2.419

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…

(Anklicken zum wiederholen)

Direkter Link: http://cap-studio.de/edge/index.html

Aber wenn jetzt jeder – wie ich – einfach so mit Animationen herumspielen kann, wird er/sie das auch tun. Und was dabei herauskommt, haben wir schon in den Anfangsjahren des DTP und des Web gesehen…

Im April erschien das Werk »InDesign automatisieren« von Gregor Fellenz. Jetzt hat der Autor den Ergänzungen der Version CS5.5 Rechnung getragen und ein Zusatzkapitel veröffentlicht, erhältlich auf InDesignBlog.

(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

Die Welt, wie wir sie in der Technischen Dokumentation heute kennen, sähe anders aus, hätten zwei Steves nicht Mitte der 1980er Jahre Desktop Publishing erfunden.

Bitte lesen Sie zum Tod von Steve Jobs Jürgen Sieberts Nachruf.

Bitte schauen Sie sich Steve Jobs’ Stanford Commencement Address an.

24.10.2011: Ich finde es nicht übertrieben: Celebrating Steve u.a. mit Norah Jones, Al Gore, Coldplay.

Foto: RainerSturm / pixelio.de

Ich beschäftige mich vor allem mit der Automation lästiger manueller Tätigkeiten. Statt solche manuellen Schritte immer wieder und möglicherweise auch in allen Übersetzungen wiederholt abzuarbeiten, versuche ich mit meinen Kunden, diese Aufgaben oder den damit verbundenen Zeitbedarf möglichst zu reduzieren. Dazu gibt es in der Regel zwei Ansätze:

• Im Vorfeld vermeiden; zum Beispiel durch: ein besseres Template, XML-strukturiertes Arbeiten, Training der Mitarbeiter, …
• Vom Computer erledigen lassen; zum Beispiel durch: bessere Layout-Regeln in der EDD, Finishing-Routinen per FrameScript/ExtendScript, …

Der wirtschaftlich interessanteste Teil ist die Phase nach dem Übersetzungsvorgang, denn hier geht es jetzt nur noch darum, die benötigten Ausgabeformate möglichst schmerzfrei (lies: kostengünstig) zu erzeugen. Früher gab es eigens dafür zuständige Mitarbeiter, heute darf sich der Technische Redakteur auch damit beschäftigen – und es lenkt ihn von seiner Hauptaufgabe ab.

Nachdem die Produktionsschritte im Prinzip immer gleich sind (Verzeichnisse aktualisieren, PDF erstellen, …), ist es dann nicht möglich dies vom Computer erledigen zu lassen? Ja, ist es, wenn Ihre Dokumente XML-basiert erstellt und übersetzt werden: Mit XSLT und XSL-FO können Sie zuverlässig alle derzeit üblichen Ausgabemedien nach einmaliger Programmierung in automatischen Prozessen erstellen lassen!

Bei der Erstellung von Online-Medien – also meist HTML in irgendeiner Verpackung – haben wir uns daran gewöhnt, das finale Aussehen vorher nicht zu kennen, da der Anwender sein Browserfenster eben so breit oder schmal machen kann, wie es ihm oder ihr beliebt. Bleibt die Erstellung von PDF-Dokumenten. Im Unterschied zu den Online-Medien kennen wir hier die Seitenbreite genau und auf einmal sind wir alle Experten für den optimalen, den richtigen Seitenumbruch. Wirklich?

Warum also lassen wir auch diese Arbeit nicht einfach komplett vom Computer erledigen? Warum liegt uns diese letzte Eingriffsmöglichkeit mit einem DTP-Programm so am Herzen?

Was meinen Sie?

Adobe hat einen (lange überfälligen) Vergleich der FrameMaker-Versionen 7.2 – 10 auf der Produktwebseite veröffentlicht, der den Eindruck hinterlässt, dass FrameMaker 7 ja wohl gar nichts konnte, sehen Sie selbst: Upgrade-Leitfaden FrameMaker.

Natürlich wissen wir über Vergleichstabellen Bescheid, alle Features, die es seit Jahrzehnten gibt und an denen auch nichts verbessert wurde, tauchen hier einfach nicht auf. Das erinnert mich an einen Leitfaden zur Produkt-Evaluation aus den 1990ern, für FrameMaker 3. Die folgende Liste der Fragen ist lang, aber doch immer noch vollständig wahr und enthält viele der eigentlichen Gründe, weshalb FrameMaker eingesetzt wird. Oder fehlt etwas Wichtiges?

Evaluating which publishing software to use is difficult. Feature lists are long and difficult to compare. To help you decide which publishing software is best for you, here’s a checklist of key questions. The answers will help determine the strength of the software you’re considering.

• Can you create, edit, and publish your documents within one application, or do you need one product for word processing, and another for layout and document formatting?
• Can you execute all commands from the keyboard and the mouse?
• Can you zoom in on any page, whether it has text or graphics? Can you display facing pages? Can you edit while in thumbnail view?
• Are tables integrated? Do the tables automatically paginate? Can you create automatic ruling and shading for tables? Can you change table formats the way you change paragraph formats (with a click of the mouse)?
• Does the spelling checker catch common typos such as double spaces, straight quotes, and spaces before punctuation?
• Can you search for automatic hyphens, change bars, and text within index markers? Can search strings include wildcards? Can you replace text with a graphic?
• Can you include multiple cross-reference points in a single cross-reference? (See Figure 3, “Fluid Flow,” in Section 7, “Fluid Analysis” on page 7-5.)
• Is conditional text part of the application? Can you selectively view different versions of a document made from a single base document?
• Can you mix portrait and landscape pages in a single document? Are there master pages to automatically apply layouts for left, right, divider, and other pages?
• Are change bars automatic? Can you adjust their thickness, color, and position to identify different authors? Can you clear them in one step?
• Do you need to reformat a table of contents or index each time you update its content?
• Can many dialog boxes remain open while you edit text?
• Can you create hypertext documents?
• Can text flow between columns of different widths? Can you have more than one story in a document? Can you continue a story on any page?
• Are there versions of your publishing application available for other platforms or environments? How many? Are the document files from those versions completely compatible with all other versions of the software? Do you need to “convert” your document files to open them on other platforms?
• Is the company whose software you’re considering committed to technical support?