Grafikformate und ihre Tücken – Teil 2: Tücken

Im ersten Teil dieses Artikels hat meine Kollegin Katharina neben Grundlagen zu den gängigsten Grafikformaten bereits auf einige Fallstricke beim Verwenden digitaler Grafiken in der Redaktionsarbeit hingewiesen.

• Pixelgrafiken sind nicht besonders gut für technische Zeichnungen geeignet.
• Vektorgrafiken liegen häufig in proprietären Formaten vor. Die großen Mitspieler Microsoft und Adobe bilden eigene Welten mit nur bedingt durchlässigen Grenzzäunen aus.
• Fehlt die Originalgrafikdatei, lassen sich Grafiken manchmal nur mit Mühe aus Bestandsdokumenten extrahieren.

Lassen Sie uns etwas tiefer einsteigen. Unser Geschäft hier bei doctima sind Single-Source-Redaktionsprozesse, wo Texte, Grafiken etc. aus einer Quelle (Redaktionssystem) in verschiedene Zielmedien (Print, Web, App, …) publiziert werden. Bestandsdokumente und Zulieferungen sollen in diese Datenflüsse integriert werden. Auf diesem Weg findet sich die eine oder andere Sollbruchstelle. Ich möchte mit einem Fall (einer Falle?) aus einem aktuellen Projekt beginnen.

Du hast ein völlig falsches Bild von mir!

Auf der von uns betreuten Website eines Kunden befindet sich ein Bild mit dem Namen {dateiname}.jpg. Firefox, Chrome und Safari zeigen das Bild korrekt an, Internet Explorer 11 zeigt ein Fehlersymbol. Was ist falsch?

Ein PNG-Bild im Texteditor geöffnet

Ein kurzer Blick ins Innenleben der Datei genügte, um das vorgebliche JPG-Bild als PNG-Grafik zu enttarnen. Moderne Browser erkennen das, der IE … ist ein anderes Thema.

Unser bevorzugtes Redaktionssystem arbeitet für seine interne Vorschau mit Microsoft-Web-Komponenten (d.h. sozusagen auf IE-Basis). Also gleich ausprobiert. Ein kurzer Test mit dem betreffenden Bild ergab aber, dass bereits der Ressourcen-Import clever genug ist, um die Dateiendung zu ignorieren und das Bild als PNG in seine Objektverwaltung aufzunehmen. Die Vorschau funktioniert also problemlos.

Dieses eher harmlose Beispiel illustriert ein Grundproblem des Single Source Publishing: Die Produktionskette kann eine ganze Reihe von Werkzeugen umfassen, und nicht jedes Glied der Kette kommt gleich gut mit den verwendeten Formaten zurecht.

Im Schnitt hundert Bilder

Übernimmt man ein Anleitungsdokument aus Word, Framemaker oder InDesign ins medienneutrale Redaktionssystem, entstehen (je nach Dokumentgröße) neben einer Vielzahl von Textbausteinen auch eine ganze Reihe von Grafikobjekten. Das bedeutet in der Regel, dass man sich mit proprietären Grafikformaten auseinandersetzen muss. Dazu später mehr. Dazu kommen aber proprietäre Einstellungen aus dem Dokument wie Rahmen, Skalierung, Positionierung und Beschnitt, die auf dem Weg in die medienneutrale Welt verloren gehen bzw. ihren Sinn verlieren. Einige Beispiele aus vergangenen Projekten:

• In einem beschreibenden Kapitel erklärt eine zweispaltige Tabelle die Bedeutung von Bedienknöpfen. Links der Knopf, rechts die Erläuterung. Acht Knöpfe, acht Tabellenzeilen. Bei der Übernahme von Word nach XML stellt sich heraus, dass es sich um acht unterschiedliche Beschnitte des Übersichtsbilds mit allen Knöpfen handelt. Da das CMS mit Beschnitt anders umgeht als Word, und in einer Single-Source-Umgebung mit unterschiedlichen Ausgabemedien ein für alle Zwecke konsistenter Beschnitt nur mit Mühe zu erreichen ist, ist es sinnvoll, die Grafik in ihre Einzelteile zu zerlegen und diese neu zuzuordnen.
• In einem InDesign-Dokument sind über mehrere Seiten hinweg erläuternde Grafiken rechts neben Anleitungsschritten positioniert. Beim Konvertieren stellt sich heraus, dass die Grafikobjekte an willkürlichen Stellen im Dokument verankert und dann relativ zum Anker verschoben wurden. In diesem Fall muss die Positionierung der Grafiken im XML-Textfluss manuell nachkorrigiert werden.
• In einer Montageanleitung, einem Word-Dokument, befinden sich eine Reihe optisch gleich großer Risszeichnungen. Beim Extrahieren der Grafiken stellt sich heraus, dass einige davon eins zu eins die angezeigte Größe hatten, andere aber mit der Maus klein geschobene Riesengrafiken, mit denen man eine Messewand hätte gestalten können. Auch hier entsteht Aufwand, weil man die Skalierungsinformation in die Modellierungswelt des Redaktionssystems bzw. der unterschiedlichen Zielmedien übertragen muss. Am einfachsten ist es, Grafiken beim Import auf ein plausibles Format herunter zu skalieren.

Das Bild hängt schief

Die in der Technischen Dokumentation gängigen Dokumentformate arbeiten neben den proprietären Einstellungen auch gerne mit proprietären Bildformaten. Bei Übernahme in ein Single-Source-Redaktionssystem empfiehlt es sich, diese in Standardformate zu konvertieren, die im System verwaltbar und für die generierten Zielformate verdaulich sind. In den meisten Fällen wird das bedeuten, dass Grafiken sich in PDF und HTML einbinden lassen und für die Erfassung in XML-Editoren (bzw. in Word für einen Großteil der Nutzer von SCHEMA ST4) funktionieren.

In gängigen Redaktionssystemen lassen sich Grafikvarianten für unterschiedliche Zielmedien verwalten. Gängige Formate für die Online-Produktion sind PNG, JPG, GIF und das Vektorformat SVG. Für Print-Produktionen sind TIFF, JPG (mit CMYK-Farbraum) und PDF verbreitet, sowie das in die Jahre gekommene Encapsulated Postscript, EPS. In Dokumenten finden sich weitere, proprietäre Formate, die bei Übernahme in einen Single-Source-Prozess verarbeitet werden müssen. Hier einige Beispiele aus dem täglichen Leben:

• Anleitungen im InDesign-Format, die ins Redaktionssystem übernommen werden sollen, enthalten in großen Mengen Illustrator- und Photoshop-Grafiken im Originalformat. Im InDesign-Dokument funktioniert das hervorragend. Auch HTML und PDF lassen sich direkt aus dem Dokument sauber generieren. Für den XML-basierten Single-Source-Prozess müssen diese Grafiken in Web- und Print-taugliche Formate überführt werden. Am saubersten gelingt das durch direkten Export der Originalgrafiken aus Illustrator bzw. Photoshop, jeweils als Print- (z.B. als PDF-Grafik) und als Webvariante (z.B. als PNG).
• Eine große Menge Textbausteine, die als Word-Dateien vorliegen, enthalten EPS-Grafiken. Das Problem hier: Word verpackt beim Einbinden von EPS-Bildern diese in WMF-Container (Windows Metafile, Microsoft-eigenes Containerformat für Medien). Extrahiert man die Grafik (Kontextmenü „Als Grafik speichern“ oder andere Wege bis hin zur Office-API), erhält man eine WMF-Datei, die das EPS zwar möglicherweise enthält, aber auch beim Ausdrucken bzw. beim Weiterkonvertieren nach PNG nur die WMF-Vorschau auswertet. Der stabilste Weg, an die EPS-Auflösung zu gelangen, ist das Drucken aus Word in den Adobe Distiller, um dann mit Adobe Acrobat aus dem generierten PDF die Grafik in Druckqualität zu extrahieren. Bei einer fünfstelligen Anzahl von Textbausteinen ist das nicht wirklich ein gangbarer Weg. In solchen Fällen sollte man versuchen, an die verwendeten Original-EPS-Dateien heranzukommen. In unserem Fall waren ausreichend wenig Dateien betroffen, um manuell nachzuarbeiten.
  Nochmal zu EPS: Das Format aus den Achtzigern des letzten Jahrhunderts ist immer noch sehr verbreitet in unserer Branche. Es besteht aus einer Abfolge von Druckerbefehlen, die von Postscript-Interpretern verarbeitet werden. Da EPS keine Sicherheitsmechanismen kennt, gilt es als angreifbar und sollte nicht mehr verwendet werden. In Microsoft Office ab Version 2016 lassen sich EPS-Grafiken beispielsweise nicht mehr einfügen.
• Der schwierigste Fall für die Übernahme sind native Zeichnungen im Dokument. Besonders in Word kann man damit rechnen, dass eingebundene Grafiken angereichert sind durch Rechtecke, Pfeile und kleine Textboxen. Beim oberflächlichen Prüfen des Dokuments können einem diese Ergänzungen leicht entgehen. Die einzelnen Elemente können gruppiert sein, möglicherweise sind sie aber einfach nur auf der Seite einzeln so positioniert, dass sie optisch ein Gesamtbild ergeben, aber als Objekte keinerlei Bezug zueinander haben. Hier hilft nur Handarbeit, z.B. mit Screenshots.

Zum Abschluss ein besonders schönes Beispiel einer Grafik, die sich nicht ohne weiteres in eine Single-Source-Umgebung übernehmen lässt. Das …

… ist eine Tabelle.

Ein Kunde hatte auf diese Art (mit ca. 20 Spalten und 30 Zeilen) seinen Typschlüssel erläutert. In dem konkreten Fall haben wir die ganze Tabelle in eine Struktur konvertiert, die dynamisch in der HTML-Ausgabe nur die Erläuterung zum jeweils angeklickten Teil des Typschlüssels anzeigt.

Alles so schön bunt hier!

Das Übernehmen von Grafikmaterial aus Zuliefer- und Bestandsdokumenten kann einen großen Teil der Bearbeitungszeit in Anspruch nehmen. In jedem Fall lohnt sich eine genaue Beschäftigung mit dem Thema.

Dieser Artikel deckt sicher nur einen kleinen Teil aller relevanten Probleme ab, denen Sie im Umfeld der Technischen Redaktion mit Grafikformaten begegnen. Das ganze Thema Farbräume (CMYK, RGB, Pantone, …) haben wir zum Beispiel ausgespart. Wir fänden es spannend, und für unsere anderen Leser wäre es sicher ebenfalls von Interesse, über Ihre Erlebnisse mit Grafiken und Bildern im (bunten) Redaktionsalltag zu erfahren. Schreiben Sie einen Kommentar!