// du liest...

Grafik/Illustration

Grafikformat für die Zukunft

Irgendwann stellt sich die Frage, ob EPS heute immer noch dem Stand der Technik entspricht oder ob man für die Illustrationserstellung nicht auf Freeware wie zum Beispiel Inkscape umsteigen will. Das „Irgendwann“ ist meistens dann, wenn es darum geht Altdaten zu übernehmen oder mehr Funktionalität oder Automatisierung in der Grafikerstellung bieten zu können. Ansonsten würde es wohl niemandem in den Sinn kommen zig-tausend bestehende Grafiken anzupassen. Ausser vielleicht, man hat ein XML-fähiges Redaktionssystem in Betrieb genommen und will nun auch die Grafiken auf das “alleslösende” XML-Format hochheben. Dass XML auch seine Tücken, resp. die Umstellung auf XML auch mit einem beachtlichen Aufwand verbunden ist, möchte ich hier in diesem Rahmen aber nicht weiter erläutern.

Schon öfter sind in den letzten Jahren zwei neue Grafikformate als Nachfolger von EPS gehandelt worden: SVG (Scalable Vector Graphics) und VML (Vector Markup Language). SVG kommt von Adobe und Sun und VML wird von Microsoft forciert. Obwohl Google Maps im InternetExplorer zum Zeichnen der Maps VML verwendet, ist es sonst um diesen Standard sehr still geworden. Ansonsten sind diese beiden Grafikformate sehr ähnlich, da beide 2D-Vektorformate auf XML basieren und der Quellcode mit einem Texteditor betrachtet und bearbeitet werden kann.

Was sind SVG und VML?

SVG und VML sind Vektorgrafiken, so wie auch EPS eine ist. Im Gegensatz zu Pixelgrafiken wie GIF oder JPEG können SVG und VML grafische Details als Teil eines Informationssystems zur Verfügung stellen, die man mit Links versehen kann. Manipulationen wie eine dynamische Grössenänderung erfolgen ohne Qualitätsverlust, da nicht die komplette grafische Information modifiziert wird, sondern nur die entscheidenden Parameter.

Grafiken dynamisch generieren

Ein grosser Vorteil von SVG und VML ist, dass diese aufgrund ihrer XML-Eigenschaften (definierter Syntax) dynamisch generierbar sind! So können zum Beispiel sprach- oder produktabhängige Grafiken bei Bedarf generiert werden. Natürlich können diese Grafikformate wegen ihrer Eigenschaft im Volltextmodus durchsucht werden. Automationen sind hier fast keine Grenzen gesetzt.

Schwierige Recherchen

Schnell hat dich herausgestellt, dass es über die Grafikformate wenig Quellen gibt, die auch Informationen haben, wie sich die Formate im Druckbereich verhalten. Beide Grafikformate werden vor allem für den Webbereich hoch gehandelt. Eines wurde aber schnell klar: VML ist ganz und gar kein Thema. Ausser Microsoft kann mit diesem Format niemand etwas anfangen und da Microsoft nun bei SVG mitarbeiten will, hat sich das Thema hoffentlich bald von selbst erledigt.

Realität in der Technischen Dokumentation

Nach Ulrike Hässler (Dozentin am Fachbereich Photo-Ingenieurwesen der Fachhochschule Köln) sehen die Anforderungen an ein Dateiformat für den Datenaustausch zumindest im grafischen Gewerbe folgendermassen aus:

  • Das Format soll unabhängig von der Plattform, dem Betriebssystem und den Programmherstellern sein
  • Die Limitierungen bezüglich der Einbindungen von Grafiken, Schriften und dem generellen Layout sollten so gering wie möglich sein
  • Der Seitenaufbau soll in Grösse, Position und Eigenschaften der eingebundenen Objekte klar definiert sein
  • Es sollte möglichst platzsparend sein
  • Es sollte editier- und erweiterbar bleiben
  • Es sollte offengelegt werden und für zukünftige Anforderungen erweiterbar bleiben
  • Es sollte sich nahtlos in den allgemeinen Arbeitsablauf einfügen

Auch SVG erfüllt diese Kriterien des grafischen Gewerbe, obwohl ich EPS bedenkenlos mal “blind” dem Drucker geben könnte, jedoch bei SVG noch jedesmal ein Proof verlangen würde. Noch sind das Datenformat und die Technik nicht ganz ausgereift und die Prozesse noch nicht eingespielt. Trotzdem erfüllt SVG heute eines meiner persönlichen “Killerkriterien” (noch) nicht: Es wird von den meisten Satzprogrammen nicht unterstützt. Sobald man sich ausserhalb der Welt von Adobes FrameMaker und InDesign bewegt, ist mir bis heute kein Editor bekannt geworden, der SVG unterstützt. Natürlich kann man SVG auch mit Microsoft Visio öffnen und dann ins Word kopieren (ähnlich auch mit Openoffice), aber dies ist weit entfernt von einer akzeptablen Lösung.

SVG doch nur fürs Web?

Zum Spielen anklicken!Eigentlich ist SVG ja fürs Web konzipiert worden. Vektorgrafik auf dem Browser und verlustfrei Zoomen kann man auch noch. Leider hat sich bei meinen Tests ergeben, dass die Datenmenge nicht wirklich kleiner wurde. Wenn man zum Beispiel Grafiken modular aufbaut, um damit die Produkte schneller kombinieren und anpassen zu können, ist eine Testgrafik als EPS 322 KB gross und als SVG “stolze” 561 KB. Nun soll SVG ja fürs Web sein, doch ich würde keinem Kunden zumuten eine Produktgrafik mit einem halben MB runterladen zu müssen. Fürs Web würde ich lieber automatisch ein GIF, PNG oder JPEG generieren lassen und das ist dann vielleicht noch 5 bis 30 KB gross. Natürlich werden die Bandbreiten immer grösser, doch sollten wir auch an Internetbenutzer ausserhalb Westeuropas oder die Mobilen Webbenutzer denken, denn dort gehören langsame Verbindungen noch immer der Tagesordnung an.

Ein weiterer Punkt ist auch, dass SVG heute noch immer nicht nativ vom Internet Explorer unterstützt wird. Das bedeutet, dass man entweder auf eine Alternative wie Firefox umsteigen oder sich den kostenlosen Adove SVG-Viewer 3 installieren muss und diese Installation während des Surfens ist genau so nervend, wie wenn ich nachträglich einen Shockwave- oder Flash-Player installieren muss. Vielleicht bin ich aber auch nur zu verwöhnt.

Was bedeutet es, dass Adobe den SVG-Viewer seit 2009 nicht mehr unterstützt?

Dafür müssen wir uns kurz in das Projekt “Mars” eintauchen. Dabei handelt es sich um eine XML-freundliche Variante von PDF – genannt PDFXML – die auf vielfachen Kundenwunsch entwickelt wurde.  Mehr darüber unter http://labs.adobe.com/technologies/mars. Ein Whitepaper dazu von tyclipso.net kann man sich hier herunterladen. Jedenfalls verwendet Mars eine SVG-Variante für die Speicherung der Dokumentenansichten im XML-Container.

Bei einem persönlichen Gespräch mit Jim King (Chef PDF Architekt bei Adobe) fand ich heraus, dass zwar nur eine Teilmenge der Funktionen von SVG verwendet werden (SVGtyni) plus noch etwas weniges hinzugefügt wurde. Aber es ist immer noch SVG!
Das Wichtigste aus meiner Sicht ist, dass SVG von Adobe aktiv verwendet wird und auch ein W3C-Standard ist. Was für mich die Schlussfolgerung zulässt, dass SVG doch eine weitere Zukunft hat, auch wenn Adobe die Unterstützung für den SVG-Viewer per 1. Januar 2009 eingestellt hat. Kein Support mehr bedeutet ja nicht gleich, dass der Viewer per Stichdatum aufhört zu funktionieren und der SVG-Viewer läuft übrigens auch ohne Probleme auf meinem Windows Vista Rechner.

Fazit

Ein Umsteigen auf SVG scheint mir für die grosse Masse noch zu früh. Zu wenige Programme für Druckerzeugnisse unterstützten heute dieses Format.

Ein Text zur DocBook DTD unterstützt meine Meinung: Es ist absehbar, dass das Dokumentationsprojekt in Zukunft das Scalable Vector Graphic-Format (SVG) als Standardformat für Vektorgrafiken übernehmen wird. Zum jetzigen Zeitpunkt ist dieser Wechsel noch nicht möglich, da der Stand der jetzigen SVG-Anwendungen noch nicht den dafür notwendigen Erfordernissen entspricht.

Nicht einmal eine Reduzierung der Dateigrössen war mit meinen “echten” Beispielen möglich. Es kann sein, dass SVG bei einigen simplen Grafiken schlanker ist oder die dynamische Generierung von Grafiken seine Vorteile ausspielen kann. Jedenfalls konnte ich dies nicht wirklich beweisen.

Es bleibt abzuwarten, was nun geschehen wird, falls Microsoft wirklich in der Arbeitsgruppe des W3C zum Thema SVG mitarbeiten wird. Sobald Word und auch der InternetExplorer nativ (ohne zusätzlichen Plug-In) SVG verarbeiten können, dann haben wir einen wirklichen Standard.

Für mich persönlich ist SVG das Format der Zukunft! Aus diesem Grund haben wir Anfangs 2009 in meiner Redaktion den Grafikstandard so definiert, dass alle Illustrationen oder Photos mit Positionsnummern erstens in Inkscape erstellt werden und die Mastergrafik als SVG (wenn nötig mit eingebettetem Bild) gespeichert wird. Für die Verwendung in Word exportieren wir nach PNG. Unser Redaktionssystem Docuglobe wurde so angepasst, dass wir nun einen Container (Zip-Datei) hochladen, der alle dazugehörigen Daten enthält (SVG Grafik, evtl. Originalfoto, evtl. bearbeitetes Bild mit Freistellern aus GIMP und eine PNG-Datei) und das Redaktionssystem zieht sich dann automatisch das PNG heraus und verwendet es für Word.

Ressourcen:

http://www.gis-news.de/svg/svg.htm

Literatur und Ressourcen zu SVG

http://www.adobe.com/svg/main.html

Diskussion

3 Kommentare für “Grafikformat für die Zukunft”

  1. Ganz recht, Herr Kesselmark! Die flächendeckende Ablösung von EPS durch ein entsprechendes XML-Format ist wirklich schon lange mehr als überfällig. Natürlich bietet sich hier SVG an. Allein schon die wesentlich einfachere Einbindung in Redaktions-/Content Management-/Translation-Memory-System macht eine mittelfristige EPS-Ablösung durch SVG geradezu unvermeidbar.

    Ich gehe davon aus, dass sich SVG durchsetzen wird. Insbesondere, da es im HTML5-Standard integriert sein wird, sodass wir in den kommenden ein, zwei Jahren auch in jedem Fall eine nocht breite Unterstützung in den kommenden Web-Browsern sehen werden (und auch wieder im IE).

    Eine Schwachstelle hat SVG derzeit aber dennoch: Es gibt verabschiedet bislang nur Textzeilen (svg:text) und keine Textblöcke – was jede Verwendung etwas längerer Texte quasi unmöglich macht, da kein Multiline reflow möglich ist. Für Positionsnummer und One-Word-Labels reichts’s natürlich und in der gut geplanten technischen Redaktion sind Illustrationen in der Regel meist eh textfrei/sprachneutral. Aber für einen breiten Einsatz bedingt es in jedem Fall auch eine Textblock-Funktionalität. Zum Glück wird SVG 1.2 auch mit Text Areas kommen (Inkscape kann das zwar auch schon (svg:flowRoot, svg:flowRegion, svg:flowPara), allerdings kann das sonst keiner derzeit darstellen). Da SVG 1.2 zudem auch mit mit einer ganzen Reihe weiterer Page Layout Features kommt, wird auch PDFXML darauf basieren (was eben auch bedeutet das ein finales PDFXML nicht vor einem verabschiedetenSVG 1.2 kommen wird).

    Einen SVG-Support in Word darf man ja zumindest schon mal laut fordern…

    Posted by Stefan Gentz | Januar 8, 2010, 18:42
  2. “Für die Verwendung in Word exportieren wir nach PNG. Unser Redaktionssystem Docuglobe wurde so angepasst, dass wir nun einen Container (Zip-Datei) hochladen, der alle dazugehörigen Daten enthält (SVG Grafik, evtl. Originalfoto, evtl. bearbeitetes Bild mit Freistellern aus GIMP und eine PNG-Datei) und das Redaktionssystem zieht sich dann automatisch das PNG heraus und verwendet es für Word.”

    Warum den dieses Herr Kesselmark?

    Nur weil Microdoof irgend wo schreibt das PNG das Grafikformat für Office-Anwendungen ist und das einige Grafikprogramme treudoof als Export für Office anbieten. Als Ersatz für Grusel-JPEG-Artefakte ist es sicher die bessere Option. Als Ersatz für eine Vektorgrafik eher nicht, warum exportieren sie denn nicht nach *.emf http://de.wikipedia.org/wiki/Windows_Enhanced_Metafile (zur Not nach *.wmf, kleiner aber mit Qualitätsnachteilen behaftet http://de.wikipedia.org/wiki/Windows_Metafile) das kann sowohl MS-Office als auch OpenOffice jederzeit importieren, ganz ohne Qualitätsverlust und beliebig skalierbar.

    Pixelgrafiken in Word geht aus zwei Gründen nur dann wenn man ein “echtes” Bild (Foto) einbauen möchte und dann eigentlich nur dann wenn man sich richtig Mühe macht und das Bild nachdem die endgültige Größe feststeht durch eine Version ersetzt die man in PS/GIMP/etc. erst mal auf die erforderlichen Maße bei 300ppi gebracht hat.

    Grund 1
    Monsterbilder belasten Word insbesonders bei großen Dokumenten mit vielen Bildern, dazu gibt’s die Option Komprimieren, die einerseits nicht dargestellte Bereiche abschneidet (Word hält sonst immer die ganze Grafik vorrätig, auch wenn nur ein Viertel davon angezeigt wird.) Bis Word 2003 ist die Auflösung zum Drucken 200 ppi und für den Bildschirm 100 ppi, ab Word 2007 Drucken 220 ppi, Bildschirm 150 ppi und E-Mail 96 ppi. Wenn man sich aber wirklich ordentlichen Druck in der Hinterhand halten möchte sollten es aber schon 300 ppi sein. Weis der Teufel warum der verantwortliche Hirni bei Microdoof da nicht noch eine freie Auswahl eingebaut hat.

    Grund 2
    Man gibt heute meist PDF-Dateien weiter und keine Worddateien, die sind aber in Standardeinstellung auf 150 ppi eingestellt und die bekomme ich weder aus 200 ppi noch aus 220 ppi in anständiger Qualität. Da war doch was mit skalieren nur mit ganzzahligen Teilern, weil die Algorithmen alle doof sind und sonst grundsätzlich das Pixel auf der falschen Seite nehmen.

    In Word 2007 gleich auf 150 ppi komprimieren verbietet sich weil man dann keine ordentliche Druckversion mehr hat.

    Heißt, wann immer es geht wird da nix Pixeliges erzeugt oder eingebaut, sondern eine Anständige Vektorgrafik, z.B. fürs Firmenlogo, das wäre dann halt die gute alte, fast schon vergessene EMF-Datei die sowohl MS-Office wie auch OpenOffice verarbeiten und in beliebiger “Pixel”-Qualität exportieren kann.

    “Einen SVG-Support in Word darf man ja zumindest schon mal laut fordern…” – dem schließe ich mich uneingeschränkt an und erweitere das auf Writer, der mag das nämlich auch nur mit Add-on “fressen”.

    Gruß Werner

    Posted by Werner | März 26, 2010, 15:07
  3. Hallo Werner,

    ich hoffe, dass man aus meinem Artikel herausliest, dass ich ein Verfechter von Vektorgrafiken bin.
    EMF kenn ich natürlich auch.
    Am Schluss muss man sich immer fragen, welchen Tod man sterben will.
    EMF und WMF haben gegenüber SVG oder EPS den enormen Nachteil, dass alle Ebeneninformationen verloren gehen, d.h. alles wird auf eine Ebene zusammengepappt und es keine Mischformen Pixel und Vektor zulässt. Kein Problem bei einem Logo (Warnzeichen und Logo in unserer Wordvorlage sind auf Basis EMF!), ein riesen Problem bei einer Produktzeichnung mit hunderten von überlagernden Inhalten auf 10 Ebenen.
    Da wir aus Kostengründen die ganzen Prozesse auf GIMP und Inkscape abgestimmt haben, kommen wir auch noch an eine Limitation von Inkscape: Verläufe können nicht nach EMF oder WMF exportiert werden. Aus Illustrator ist dies kein Problem, aber eben, ich musste eine Entscheidung für unsere Redaktionsumgebung auf Basis eines Terminalserver fällen und die Beschaffung von 10 Adobe CSx liess sich finanziell nicht rechtfertigen.
    Wieso nun auf PNG: Bei meinem jetztigen Arbeitgeber sind ca. 95% der Abbildungen Fotos. Für den Rest, nehme ich gerne ich Kauf, dass die Druckqualität nicht optimal und die Daten etwas zu gross sind, wobei ein PNG von einer komplexen Vektorgrafik meistens kleiner als die Vektorgrafik ist! Wichtig ist für mich, dass wir einen “genormten” Prozess hatten und dass die Grafik jederzeit in einem Format verfügbar ist, welches die volle Informationsmenge “konserviert”.

    Gruß,

    Pascal Kesselmark

    Posted by Pascal Kesselmark | März 30, 2010, 06:06

Einen Kommentar erstellen

 

Januar 2010
M D M D F S S
« Dez   Feb »
 123
45678910
11121314151617
18192021222324
25262728293031

Geplante Artikel