DTP-Vielfrass

christoph schäfer Je komplexer eine Software ist, desto mehr Informationen müssen in einer von ihr erzeugten Datei gespeichert werden, und da ein wesentliches Verkaufs­argument für eine neue Version zusätzliche Funktionen sind, wächst die Menge der zu speichernden Daten mit jeder neuen Version an. Um Platz zu sparen und das Laden einer Datei zu beschleunigen, legen die meisten Anwendungen Informationen traditionell in einem maschinenlesbaren Binärformat ab – erst in jüngerer Zeit sind die Computer so leistungsfähig geworden, dass es kaum noch einen wahrnehmbaren Unterschied macht, ob ein Programm Informationen binär oder in einer von Menschen lesbaren Struktur wie XML ablegt.

Wer nun Dateien in einem anderen als dem «eigenen» Format öffnen oder importieren lassen möchte, steht gleich vor mehreren Problemen. Zunächst einmal sind nur wenige wichtige Dateiformate dokumentiert, sodass es oft mühevoller Kleinarbeit bedarf, um herauszufinden, welche Bits welche Information enthalten und was sie bedeuten. Aber selbst wenn eine Dokumentation vorliegt, bedeutet dies noch nicht, dass das Schreiben eines Importfilters ein Selbstläufer ist, denn manchmal sind in der eigenen Software nicht alle Funktionen vorhanden, die zum reibungslosen Import notwendig sind.

Im DTP-Bereich ist die Lage beinahe hoffnungslos komplex, denn zu Unwägbarkeiten bei Grafikformaten kommen hier Probleme beim Textsatz. Ohne Einblick in den Quellcode eines Programms ist es praktisch unmöglich zu bestimmen, welche Algorithmen zum Einsatz kommen und wie formatierter Text «richtig» importiert werden kann. Nimmt man noch die verschiedenen typografischen Optionen einzelner Programme hinzu, so ist klar, dass es einen perfekten Datenaustausch zwischen DTP-Programmen nicht geben kann, solange es kein allgemein akzeptiertes Austauschformat gibt.

Importfilter – Fluch und Segen

Wenn ein Open-Source-Programm wie Scribus dennoch über eine beinahe furchterregend lange Liste an Importformaten verfügt, so ist dies vor allem zwei Faktoren zu verdanken. Erstens der Verfügbarkeit öffentlich zugänglicher, vollständiger und benutzbarer Spezifikationen wie PDF oder SVG. Zweitens haben zahlreiche Open-Source-Projekte es auf sich genommen, die Inhalte undokumentierter Formate zu analysieren und Spezifikationen zu schreiben, anhand deren «Bibliotheken» (Funktionsmodule) geschrieben werden konnten. Letztere ermöglichen es Freien Projekten und Unternehmen ohne grossen Aufwand Importfilter zu schreiben, da sie einfach nur auf die Schnittstellen dieser Module zugreifen müssen. Besonders umtriebig ist hier das Re-Lab-Projekt (bit.ly/1fJOtPh), das bereits die Formate von MS Visio, MS Publisher und CorelDraw dokumentiert hat, und zwar von den frühesten Versionen bis in die Gegenwart.

Derartige Bibliotheken sind ein Segen für Programmierer, weil sie unglaublich viel Zeit sparen; sie stellen in gewisser Weise aber auch einen Fluch dar, denn wie am Beispiel Scribus zu sehen ist, verlangen sie von Entwicklern unter Umständen die Implementierung zusätzlicher Funktionen, die nicht unbedingt ganz oben auf der Prioritätenliste stehen.

Ausgabe = Eingabe

Sauberer PDF-Export war schon früh eines der Hauptkriterien der Scribus-Programmierer. Inzwischen entwickelt sich PDF jedoch in zunehmendem Masse vom Ausgabe- zum Austauschformat, und hier tat sich Scribus bisher etwas schwer: Ob ein direkter Import in Version 1.4 funktionierte, war Glückssache. Und so blieb häufig nur der Umweg über einen Bildrahmen, in dem man eine PDF-Datei rastern lassen konnte.

Für Scribus 1.6 wurde der Import-Code komplett neu geschrieben, so dass (auch mehrseitige) PDF-Dokumente jetzt layoutgetreu geöffnet werden können. Wenn man ein PDF-Formular öffnet, werden die darin enthaltenen Formularelemente (Checkbox, Eingabefeld usw.) als solche erkannt und als entsprechende Scribus-Elemente geladen. Perfekt ist der Import trotz allem noch nicht, und der grösste Wermutstropfen ist dabei die Umwandlung von Text in Vektordaten, so dass man importierten Text nicht als solchen bearbeiten kann. Auch Ebenen erkennt Scribus nicht – importierte PDF-Dateien bestehen immer nur aus einer Ebene.

Was für PDF gilt, trifft mutatis mutandis auch auf dessen älteren Bruder PostScript zu, und der wesentliche Unterschied besteht darin, dass PostScript als reine Seitenbeschreibungssprache weniger Informationen speichert.

Ganz neu ist der Importfilter für Microsofts PDF-Rivalen XPS (siehe Publisher 6-06) sowie dessen Nachfolger OXPS. Auch hier gilt, dass formatierte Texte als Vektordaten, dafür aber layoutgetreu importiert werden.

DTP-Import

Lange galt für Scribus dasselbe wie für die meisten anderen DTP-Programme: Es lohnte sich kaum, Importfilter für die Dateiformate der Konkurrenz zu schreiben. Wenn dennoch Filter angeboten wurden, so handelte es sich meist um PR-Aktionen, um Nutzer eines marktbeherrschenden Programms zum Umstieg zu bewegen (etwa die XPress-4-Importfilter in VivaDesigner und InDesign). In der Praxis hat sich dann freilich oft gezeigt, dass die Import-Ergebnisse mehr oder weniger viel Nacharbeit erforderten. Bessere Resultate liessen sich erzielen, wenn man einen Konkurrenten einfach übernahm und somit Zugang zum Quellcode von dessen Produkt erlangen konnte (beispielsweise Adobe mit PageMaker).

Angesichts immer grösser werdender Erfahrungen beim «Reverse engineering» von Binärdateien seitens der Open-Source-Gemeinde sowie veröffentlichter Spezifikationen konnte das Scribus-Team aber einen bedeutenden Schritt in Richtung funktionierender und relativ verlässlicher DTP-Importfilter gehen.

In Bezug auf den Marktführer InDesign steht eine Analyse von dessen Binärformat noch aus. Indes hat Adobe mit IDML (InDesign Markup Language) eine XML-Variante des Formats implementiert und eine brauchbare Spezifikation veröffentlicht. Bei den XML-Versionen von InDesign Snippets (IDMS) sowie deren InCopy-Äquivalenten (ICML) handelt es sich um Untermengen von IDML. Auch wenn Scribus noch nicht alle Funktionen von InDesign beherrscht, arbeitet der Importfilter für IDML-Dateien bereits recht gut. Dennoch sollte man nicht vergessen, dass eine IDML-Datei keineswegs eine vollständige Repräsentation eines InDesign-Dokuments ist. So werden beispielsweise die ursprünglich verwendeten Bilddateien nicht in einer IDML-Datei gespeichert, sondern nur niedrig auflösende Vorschaubilder. Wer InDesign-Dokumente in Scribus öffnen, bearbeiten und für den Druck ausgeben möchte, sollte daher unbedingt darauf achten, auch die Originale der verwendeten Pixeldateien zur Hand zu haben.

Die aus Deutschland stammende DTP-Software VivaDesigner erlaubt ebenfalls den Export nach XML. Auch diese Dateien kann Scribus 1.6 importieren. Indes handelt es sich hier nicht um einen ZIP-Container, so dass nicht einmal Vorschauversionen der im Original verwendeten Pixeldateien zur Verfügung stehen.

Apple hat das Textverarbeitungsprogramm Pages, das Bestandteil der iWork Office Suite ist, auch mit DTP-Funktionen ausgestattet – nicht zuletzt, weil Publisher im Gegensatz zu anderen MS-Office-Komponenten nie auf Mac OS portiert wurde. Weil auch das Pages-Format nur einen ZIP-Container darstellt, der Standardkomponenten enthält, war es möglich, in Scribus 1.6 einen Importfilter für Pages-Dateien ab Version «’08» zu implementieren.

Weniger günstig ist die Lage für QuarkXPress-Daten. Die im Jahr 2005 mit viel Getöse angekündigte Spezifikation des QuarkXML-Formats (QXML) ist nicht mehr öffentlich zugänglich und scheint jenseits der Server-Version keine Rolle mehr zu spielen. Anders sieht es bei XPress Tags, einer Quark-eigenen Mark-up-Sprache für formatierte Textbausteine, aus, für die es einen Importfilter in Scribus gibt, der allerdings bis zur Veröffentlichung von Version 1.6 noch einer gründlichen Überholung bedarf, um dann auch wirklich nützlich sein zu können.

Ein völlig anderes Bild bietet sich hingegen für bisherige Anwender von Microsoft Publisher. Dank der Bemühungen des Re-Lab-Projektes und der LibreOffice-Entwickler (siehe Publisher 6-13) kann Scribus auf eine inzwischen ziemlich robuste Importbibliothek zurückgreifen, und die Import-Ergebnisse sind erstaunlich gut. Einschränkungen ergeben sich lediglich dann, wenn in einer PUB-Datei Funktionen verwendet werden, die entweder Windows- oder MS-Office-spezifisch sind, etwa OLE-Objekte oder WordArt.

Wechselbalg

Produkte des Herstellers Xara benutzen seit jeher das kompakte und vollständig dokumentierte XAR-Format. Letzteres verwendet nicht nur das wegen seiner Vielseitigkeit bekannte Profiprogramm Xara Designer Pro, sondern auch dessen DTP-Ableger Xara Page & Layout Designer.

Unter Zuhilfenahme der Spezifikation gelang es den Scribus-Entwicklern, einen hervorragend funktionierenden Importfilter für XAR-Dateien zu schreiben. Das Ziel eines möglichst originalgetreuen Imports führte ausserdem zur Programmierung zusätzlicher Funktionen in Scribus 1.6.

Vektorgrafiken

Zu den am häufigsten anzutreffenden Vektorformaten im professionellen Bereich gehören zweifellos EPS sowie das Illustrator-Format AI. Zwar konnte Scribus diese Dateien schon bisher importieren beziehungsweise direkt öffnen, doch liess sich manche Illustrator-Funktion nicht adäquat in Scribus abbilden. Die Komplettüberarbeitung des Importfilters hatte daher die Implementierung neuer Grafikfunktionen wie etwa Verlaufsgitter zur Folge. Ausserdem können Anwender beim Öffnen einer hybriden AI-Datei (AI plus PDF) auswählen, welche Version sie verwenden möchten. Ebenfalls von Grund auf neu geschrieben wurde der Filter für den offenen Standard ODG, der beispielsweise von LibreOffice und OpenOffice für Grafiken aller Art verwendet wird. Da ODG und das für Präsentationen à la Powerpoint benutzte ODP-Format praktisch Zwillinge sind, kann Scribus 1.6 nun auch ODP-Dateien importieren.

Wer häufiger technische Zeichnungen importieren muss, wird sich in Scribus 1.6 über den neuen Filter für CGM-Dateien freuen. CGM steht für «Computer Graphics Metafile» und ist ein internationaler Standard. Das Format erlaubt Vektor-, Pixel- und Textdaten, und alle diese können bearbeitbar importiert werden.

Für Diagramme aller Art bietet Microsoft seit Langem das Programm Visio an. Dessen Dateiformat wurde, ebenso wie im Fall MS Publisher, vom Re-Lab-Projekt seziert. Die auf dieser Arbeit aufbauende Programmbibliothek nutzt Scribus zum Import von Visio-Dateien ab Version 1.

Pixel

Beim Pixel-Import hat sich gegenüber Scribus 1.4 auf den ersten Blick wenig getan, und der wichtigste Neuzugang ist ein Importfilter für die in der Schweiz entwickelte und hoch­interessante JPEG-2000-Alternative PGF (www.libpgf.org). Für Photoshop gibt es ein kostenloses Plug-in, das dem Marktführer PGF-Import- und -Export-Optionen hinzufügt. (www.xeraina.ch/pgf/pgfdownload.html).

Externe Helferlein

Scribus verlässt sich beim Datei-Import zum Teil auf externe Programme wie Ghostscript. Hat man zusätzlich zu Scribus 1.6 noch das Kommandozeilenwerkzeug GraphicsMagick installiert, so kann man mit dessen Hilfe fast jedes Pixelformat aus der endlos langen Liste unterstützter Formate (www.graphicsmagick.org/formats.html) importieren. Ein weiteres Helferlein ist UniConvertor (bit.ly/1ifOufX). Ist dieses Programm installiert, lassen sich zusätzlich Vektorgrafiken aus CorelDraw, dem Veteranen AcornDraw, dem Open-Source-Programm sK1 sowie CAD-Dateien im DXF-Format importieren.

Dreidimensional

Die PDF-Spezifikation erlaubt ab Version 1.6 auch das Einbetten von 3D-Daten, wie sie von CAD- oder Modellierungsprogrammen erzeugt werden. Wer künftig die Freie 3D-Grafik­bibliothek OpenSceneGraph (www.openscenegraph.org) zusätzlich zu Scribus 1.6 installiert, der wird in der Lage sein, dreidimensionale Objekte in allen gängigen Formaten (beispielsweise 3DS, LWO oder OBJ) mittels einer speziellen «3D-PDF-Anmerkung» einzufügen und – in engen Grenzen – zu bearbeiten.

Öffnet man eine PDF-Datei mit solchen Daten in Acrobat oder Adobe Reader, lässt sich das 3D-Objekt dort aus verschiedenen Perspektiven betrachten.

Fazit

Mit Version 1.6 wird Scribus auf dem Weg zum universellen Verarbeiter von DTP- und Grafikdaten erheblich vorankommen. Die vorhandenen Importfilter werden extern und intern ständig verbessert, und weitere befinden sich in Vorbereitung. Nimmt man noch die neuen Export-Optionen (mehr dazu in einer der nächsten Ausgaben des Publisher) sowie das Scribus-eigene und offene Dateiformat hinzu, scheint der herstellerunabhängige Datenaustausch zwischen DTP-Programmen allmählich seinen Schrecken zu verlieren.