SCHEMA Blog

Corporate Blog der SCHEMA GmbH

Dr. Arno Klein

Vom Word-Import zum Dokument-Import für FrameMaker-Dateien

3 Kommentare

Langjährige Nutzer des SCHEMA ST4 DocuManagers können sich vielleicht noch an die 2005 eingeführte Funktion „Word-Import“ erinnern. Damals wurde versucht mit einem VBA-Makro (Visual Basic for Applications) die Struktur und Auszeichnungen eines beliebigen Word-Dokuments so zu verändern, dass eine gemäß DocuManager-Vorgaben ausgezeichnete Version des Dokuments entstand. Technisch wurde dazu jedes Zeichen des Word-Dokuments angeschaut und anhand des implementierten Algorithmus entschieden, welche Auszeichnung das Zeichen, das Wort oder der Absatz erhalten. Schön an dieser Implementierung war eigentlich nur, dass man aufgrund der Ineffizienz der Bearbeitung von Word-Dokumenten per VBA und den damals noch deutlich langsameren Rechnern dem Algorithmus bei der Arbeit zusehen konnte: wie von Geisterhand hat sich das Ursprungsdokument langsam in ein DocuManager-Dokument verwandelt, das dann importiert werden konnte. Zugegebenerweise ist der Spannungsbogen nach dem Beobachten der Verwandlung einiger Seiten deutlich abgeflacht.

Wir haben damals recht schnell eingesehen, dass die Implementierung der Funktion „Word-Import“ grundlegend überarbeitet werden musste und zwar in Bezug auf Effizienz, Anpassbarkeit und Erweiterungsmöglichkeit bzgl. des Imports anderer Dokumente. Das Ergebnis wurde mit dem DocuManager 2.0.1 im Jahr 2007 erstmals verfügbar. Neben der Implementierung hat sich dabei auch die Bezeichnung der Funktion geändert, die seitdem „Dokument-Import“ heißt. Mit der Version ST4 DocuManager 2012 lassen sich nun erstmals auch Adobe FrameMaker-Dokumente über die gleiche Funktion wie zuvor die Word-Dokumente importieren. Und das auch für unstrukturierte FM-Dateien.

FM-Dokumentimport

Der Dokument-Import arbeitet technisch auf XML-Strukturen: als Eingabe wird eine sehr einfach aufgebaute XML-Datei erwartet. Der interaktive Mapping-Dialog im DocuManager liest diese Datei ein und bestimmt die verwendeten Absatz- und Zeichenformatvorlagen (aus den verwendeten Elementen). Dabei werden auch Kontextinformationen ausgewertet (z.B. Absatz in Tabelle, Auflistung). Diese Absatz- und Zeichenformate können dann vom Benutzer den im DocuManager konfigurierten Formaten zugewiesen werden. Der Dokument-Import transformiert schließlich die Eingabe-XML-Datei, unter Berücksichtigung der Mapping-Informationen, in eine DocuManager-konforme XML-Repräsentation.

Um diese Eingabe-XML-Datei zu erzeugen, verwendet das DocuManager-Plugin im Adobe FrameMaker zunächst die eingebaute „Als XML speichern“-Funktion des FrameMaker. Anders als bei der Standardfunktion gedacht, wird jedoch nicht die Konvertierungstabelle des FrameMaker zum Zuordnen der Absatz- und Zeichenformate zu den erwarteten XML-Elementen genutzt. Das liegt zum einen daran, dass die Verwendung der Konvertierungstabelle FrameMaker-Spezial-Know How erfordert und zum anderen, dass die Vollständigkeit der Konvertierungstabelle für jedes Dokument neu geprüft werden müsste.

Weitere Nachteile der Standardfunktion „Als XML speichern“:

  • Die Tabellen verlieren einige ihrer Eigenschaften. Bspw. gehen die Informationen der Tabellen- und Spaltenbreiten verloren.
  • Alle Grafiken werden in ein von FrameMaker definiertes Format mit meist schlechterer Qualität als das Original konvertiert (standardmäßig GIF). Ändern könnte man das nur, wenn man eigens hierfür eine „Strukturierte Anwendung“ erstellt und diese in den XML-Exportprozess einbindet.

Das DocuManager-Plugin vermeidet diese Probleme mit Hilfe der folgenden Maßnahmen:

  • Die Tabelleneigenschaften werden vor dem XML-Export durch das ST4-FrameMaker-Importplugin eingesammelt und so gespeichert, dass sie beim XML-Import erhalten bleiben.
  • Die Informationen für Bildgröße und Pfad zum Originalbild werden beim XML-Export so gespeichert, dass sie beim XML-Import erhalten bleiben. Dort wo es möglich ist, wird die Bildreferenz auf den Pfad zur Originaldatei zurückgesetzt und die ungewollt konvertierte Bilddatei ignoriert. Außerdem bleiben die Bildgrößeninformationen erhalten.

Das Mapping der Absatz- und Zeichenformate erfolgt wie in ST4 gewohnt über den Mapping-Dialog des Dokumentenimports. Ändert sich das Quellformat einmal, sind meist nur geringe Anpassungen am Mapping erforderlich. Einmal gesicherte Mappings können immer wieder verwendet und mittels Drag & Drop geändert werden.

Leider geht das alles inzwischen so schnell, dass man auch bei größeren Dokumenten dem Algorithmus nicht mehr beim Arbeiten beobachten kann.

3 Kommentare zu “Vom Word-Import zum Dokument-Import für FrameMaker-Dateien

  1. Es wäre super, wenn das auch so geschmeidig funktionieren würde 🙂

    Von 12 Kapiteln konnte ich 5 importieren, die Ergebnisse werfen die Frage auf, ob der Aufwand bei „normalen“ Copypasten tatsächlich höher wäre, zumal man dann auch andere Probleme gleich vermeiden kann. Die restlichen 7 Kapitel weisen Fehler auf, die den Import stoppen. Ohne Zusatzsoftware hat man auch keine Chance, die Probleme zu beheben. Es fehlt eine Vorschau auf das Quelldokument, um im Zweifelsfall zu entscheiden, wie ein Absatz- oder Zeichenformat gemappt werden soll.

    Problem sind Mutationen der FM templates, die bereits 10 Jahre im Einsatz sind, wurden, verändert „nach bestem Wissen“ = „keine Ahnung, ob das in der neuen Version auch noch funktioniert?“.

    Inkonsequenzen beim Formatieren der nicht strukturierten FM-Dateien sind ein weiterer Stolperstein und die mangelnde Intelligenz der Import-Routine, wiederkehrende Grafiken (Logo, Sicherheitspiktogramme, Zielgruppenpiktogramme) zu einer Quellgrafik zusammenzufügen, bzw. erst gar nicht auseinanderzunehmen, trüben das Vergnügen doch stark. Der Nachbearbeitungsaufwand ist enorm, ich habe es nach einem Tag Testen aufgegeben.

    • Hallo Herr Jundt,

      es ist sicherlich richtig, dass der Import auf die Qualität der FM-Dateien angewiesen ist. FM entscheidet nämlich in seiner Speicherroutine, wie und ob das Dokument nach XML gespeichert werden kann. Dieser Vorgang ist leider generisch nicht zu beeinflussen. Die von Ihnen angesprochene Zusammenführung gleicher Bilder ist sicher eine wünschenswerte Erweiterung der Importfunktion; das prüfen wir für eine neue Version. Solange können Sie jedoch auch im DocuManager nach dem Import nach gleichen Grafiken suchen und eine davon wiederverwenden.

      Zur weiteren Bewertung Ihrer nicht importierbaren Kapitel wäre es schön, wenn Sie uns die Dateien zukommen lassen könnten.

      mfg,
      Arno Klein

  2. Hallo Herr Klein,

    steht der Aufwand, die vielen FM Dokumente mit unterschiedlichster Formatierung, unterschiedlichster Berabeitungstiefe (Texteinschübe hatte ich noch keine dabei) nach Schema zu übernehmen, in einem vernünftigen Verhältnis von Initialaufwand zu Arbeitserleichterung?
    Vielleicht bei einem einzelnen, konsequenten Autor. Aber bei einer Redaktion mit normaler Fluktuation, normalen Unvollständigkeiten des Redaktionsleitfadens (und seiner Anwendung) und normal mutierten FM Dokumenten?

    Ich hatte die betreffenden Kapitel bereits an Schema geschickt, weil ein Element zum Abbruch des Exports führte. Mit dem Beheben dieses einen Problems würden alle verbleibenden nicht gelöst. Ich sehe hier nur die Möglichkeit, schon automatisch erzeugte FM-Daten nach Schema zu transportieren. Aber manuell geschriebene, deren templates schon inkonsequent sein können, holt man sich wirklich besser per Copy & Paste ins System, man muss die Strukturen ohnehin ändern oder wenigstens überprüfen.

    Solange keine Voransicht implementiert ist und man keinen unstrukturierten und strukturierten FM parallel laufen lassen kann, ist das ein mühsames Geschäft. Das nachträgliche manuelle Suchen von Grafiken und „einen davon wiederverwenden“ – bitte nennen Sie mir doch den Eintrag in der Hilfe, der dafür das richtige Stichwort ist?

    Und was die Suche, insbesondere die „erweiterte Suche“ angeht, würde ich eher manuell suchen als mich durch den Wust von Parametern durchzuwühlen versuchen. Sorry, aber mit den beiden Suchmechanismen konnte ich noch keine Erfolgserlebnisse verbinden. Findet zuviel und trotzdem nicht das Richtige.

    Templates von FM enthalten meist schon alle wiederverwendeten Grafiken, jedenfalls die, die pro Seite vorkommen (Logos) oder bei jedem Sicherheitshinweis die gleichen bleiben. So wie aussieht, hat die Importroutine daraus keinen Nutzen gezogen. Aber vielleicht gibt es ja Redaktionen, die diesbezüglich bessere Erfahrungen machen. Die Regel, dass bei jeder Datenwandlung Verluste anfallen, gilt hier besonders. Wenn alte Dokumente wiederverwendet werden sollen in der letzten bearbeiteten Ausgabe, ist das Einbinden der PDF ein Vorzugsweg. Nicht strukturierte FM Dokumente dagegen müssen ohnehin für die Bedürfnisse eines Redaktionssystems fit gemacht werden. Ich glaube nicht, dass das per Routine einfach machbar ist.

    mfg

    J. Jundt

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s