Info-Portal > Artikel

Geht nicht - oder doch?

Wie man dennoch ans Ziel gelangt, wenn Standardsoftware an ihre Grenzen stößt.
Beispiel: Adobe FrameMaker Publish-Modul

Publishing mit einer Black Box

Wenn man Adobe FrameMaker als Standardsoftware einsetzt, dann kann man seit dem Jahr 2014 aus den FrameMaker-Dokumenten verschiedene Ausgabeformate für digitale Medien erzeugen, ohne auf Zusatzsoftware zurückgreifen zu müssen. Zuvor hatte man nur die Wahl, entweder hochkomplexe Konverter einzusetzen, die von einem Experten konfiguriert werden müssen und zusätzliche Lizenzkosten verursachen, oder man setzte auf spezielle Help-Authoring-Tools (HAT), die FrameMaker-Dokumente importieren können - und auch Lizenzkosten verursachen. Besonders kleinere Redaktionen waren deshalb hoch erfreut, ab Adobe FrameMaker Version 12 ein zusätzliches, kostenlos mitgeliefertes Werkzeug vorzufinden. Genau dieser Anwenderkreis stand den Produktentwicklern von Adobe vermutlich vor Augen: Man nimmt ein schönes FrameMaker-Testdokument, übt ein wenig mit der Konfiguration des Publish-Moduls, drückt den Knopf, schickt damit alles in die „Black Box“ und heraus kommt nach kurzer Zeit das gewünschte Ergebnis (z. B. Responsive HTML5).

Die Benutzerschnittstelle des Publish-Moduls (Veröffentlichen-Moduls) in FrameMaker ist so gestaltet, dass routinierte FrameMaker-Anwender die notwendigen Einstellungen und Parameter setzen können. Seit Adobe die Benutzerinformationen für FrameMaker 2019 bezüglich des Publish Moduls überarbeitet und erweitert hat, findet man die allermeisten benötigten Informationen dazu. Ein paar im Umfang reduzierte FrameMaker-Testdokumente, die alle vorkommenden Formate exemplarisch enthalten, eignen sich während der Konfiguration des Publish Moduls als Testobjekte. Per „Knopfdruck“ startet die Konvertierung. Zumeist ist das erste Ergebnis vielversprechend aber noch nicht zufriedenstellend. Es beginnt ein iterativer Prozess: Parameter und Einstellungen anpassen, konvertieren, Ausgabe beurteilen, usw. Mit jedem Durchgang werden die eigenen Ansprüche immer besser erfüllt, bis das Ergebnis die geforderte Qualität liefert. Die Einstellungen können jederzeit wiederverwendet und zur Konvertierung anderer Dokumente benutzt werden. – So der Idealfall.

In der Praxis ergeben sich dann doch manchmal Hürden, die nicht durch Konfiguration des Publish-Moduls genommen werden können. Technologisch basiert das Publish-Modul in FrameMaker auf Adobe RoboHelp. Damit erbt der FrameMaker-Anwender alle Begrenzungen dieses Werkzeugs. Wenn Redaktionen darauf vertraut hatten, allein mit FrameMaker ihre digitale Wunschausgabe erzeugen zu können, dann stehen sie nun vor einer „Black Box“, deren Verhalten sie nicht bis ins kleinste Detail beeinflussen können. Manch einer gibt an dieser Stelle auf. „Geht nicht – oder?“

Unter die Motorhaube blicken

Adobe FrameMaker speichert alle Parameter und Vorlagen, die für die Steuerung der Datenkonvertierung notwendig sind, in sogenannten sts-Dateien (Publish Setting - bzw. Veröffentlichungseinstellungen-Dateien). Diese Dateien sind technisch gesehen ZIP-Archive. Erfahrende Anwender mit Forschungsdrang können sts-Dateien mit frei verfügbarer Software öffnen und Anpassungen vornehmen, die über die Zugriffsmöglichkeiten der in FrameMaker implementierten Benutzerschnittstelle hinaus gehen. Bei diesem Vorgehen immer in einer Kopie arbeiten, da man die sts-Datei beschädigen könnte. Diese Kopie darf auch nicht während der externen Bearbeitung im FrameMaker im Zugriff sein, sonst gibt es Programmanstürze. Der Anwender beschreitet hier also einen inoffiziellen Weg, richtet aber bei Beachtung der Vorsichtsmaßnahmen keinen Schaden an.

FrameMaker per Skript Beine machen

Adobe FrameMaker besitzt die leistungsstarke Script-Sprache ExtendScript, mit deren Hilfe wiederkehrende Abläufe in FrameMaker automatisiert werden können. FrameMaker kann auf diese Weise auch um neue Funktionen, Menüeinträge und Dialoge erweitert werden. ExtendScript basiert auf JavaScript, sodass jeder erfahrene FrameMaker-Anwender mit Grundkenntnissen in der Web-Programmierung zur Selbsthilfe schreiten kann.

  • "Geht nicht!" geht doch in vielen Fällen durch ExtendScript.

Bugs umgehen, anstatt auf den Softwarehersteller zu warten

Jede Software enthält Fehler. Die Behebung von bekannten Fehlfunktionen durch den Hersteller einer Standardsoftware kann manchmal eine Weile dauern. In dieser Zeit darf der eigene Publishing Workflow nicht undurchführbar sein. Anstatt auf bessere Zeiten zu hoffen, kann man in vielen Fällen den Fehler analysieren und geeignete Korrekturschritte per ExtendScript realisieren.

Beispiele aus der Praxis für Hürden und ihre Überwindung

  • Problem: In einem Projekt mit strukturierten FrameMaker Dateien einer firmenspezifischen EDD misslang die Konvertierung einiger Querverweise. Anstelle von Hyperlinks erschien in der Ausgabe statischer Text. Grund: Querverweise auf der Strukturebene von FrameMaker werden von RoboHelp nur als solche erkannt und zu Hyperlinks konvertiert, wenn der Name des Zielattributs „id“ lautet.
    Abhilfe: 
    Ein ExtendScript startet direkt vor der HTML5 Ausgabe und verschiebt in den FrameMaker-Dateien die Querverweisinformationen von der Strukturebene in die unstrukturierte Absatz-Ebene. Dort werden die Links von RoboHelp korrekt erkannt und korrekt verarbeitet.
  • Problem: In einem Projekt mit ausgefeiltem Print-Layout wurden Steuerzeichen, die sich in FrameMaker Variablen befanden, im HTML ausgegeben (z. B. \- für umbruchgeschützter Bindestrich).
    Abhilfe: 
    Ein ExtendScript entfernt die Steuerzeichen in den FrameMaker-Variablen unmittelbar vor der Ausgabe nach HTML5 und stellt die ursprünglichen Variablenwerte anschließend wieder her, damit sie in der PDF-Ausgabe erhalten bleiben.
  • Problem: Ein Projekt benötigte weitere Navigationselemente und JavaScripts für Kundenspezifische Funktionen in der HTML5-Ausgabe, die in der Benutzeroberfläche des Publish Moduls nicht vorgesehen sind.
    Abhilfe: Über den Direktzugriff auf die .sts-Datei (Zip-Archiv) konnte die grundlegende HTML-Schablone angepasst und die JavaScripts implementiert werden.
  • Problem: Wörter, die mit einem „/“ ohne Leerzeichen aneinandergereiht wurden (Vorgabe des Styleguides in der betroffenen Redaktion), werden von RoboHelp als ein Wort angesehen und führen in Tabellenzellen zu unvorhersehbaren Umbrüchen.
    Abhilfe: Ein ExtendScript fügt jeweils ein Leerzeichen nach diesem Zeichen in Tabellenzellen ein, startet die Konvertierung nach HTML5 und entfernt anschließend die eingefügten Zeichen wieder aus den FrameMaker-Dateien.

Problemlöser gesucht?

Wenn in Ihrer Redaktion keine geeigneten Mitarbeiter vorhanden sind oder Ihnen einfach die Zeit fehlt, sich in dieses spezielle FrameMaker-Thema einzuarbeiten, dann wenden Sie sich einfach unverbindlich an uns. Wir beraten Sie gerne und individuell in diesem Bereich, damit die nächste "Black Box" in Ihrer Redaktion keine unüberwindbare Hürde darstellt.

Der Autor

Ralf Klossek, Dipl. Ing. (FH) Maschinenbau, beschäftigt sich seit 1995 mit der Anpassung von Standardsoftware und mit Optimierungen verschiedenster Art in der Technischen Redaktion. Er berät Kunden, erarbeitet Konzepte, konvertiert Daten und realisiert medienspezifische Ausgaben von Dokumenten. Er automatisiert Arbeitsabläufe, entwickelt Werkzeuge und gestaltet Vorlagen. Bei commatec verantwortet er als einer der drei geschäftsführenden Gesellschafter den Bereich Forschung & Entwicklung.

Aktuelle Artikel