Bachelor Thesis zur Erlangung des akademischen Grades

eines „Bachelor of Engineering“ für Druck- und Medientechnik

am Fachbereich I der Hochschule der Medien, Stuttgart.

Vorgelegt von: Ingo Fängmer, Matrikel-Nummer 15804

Erstprüfer: Marko Hedler

Zweitprüfer: Christian Spieker

Eingereicht: 31. 12. 2007

Die mehrfache Verwertung von Inhalten wird im Medienbereich immer wichtiger, die Begriffe XML und medienneutrale Datenhaltung spielen eine immer größer werdende Rolle. Das Ziel dieser Entwicklung ist, mit einem gemeinsamen Datenbestand verschiedene Ausgabeformate möglichst automatisch generieren zu lassen.

Ein weiterer wichtiger Prozess ist die Verknüpfung von Daten und Inhalten zwischen Online- und Print-Medien. In letzter Zeit wurde das Thema „Web-to-Print“ immer stärker fokussiert und es sind verschiedene Technologien und praktische Anwendungsmöglichkeiten entwickelt worden. „Web-to-Print“ ist ein Verfahren der Online-Erzeugung von Druckvorlagen via Internet mithilfe serverbasierter Layout-Technologie, die Server-Templates und Client-Eingaben miteinander kombiniert.

Was ist jedoch mit dem entgegengesetzten Weg? Der weniger kommunizierte Begriff „Print-to-Web“ beschreibt den Weg einer Überführung von Informationen aus Layout-Dokumenten in den Online-Bestand. In dieser Ausarbeitung werden verschiedene Möglichkeiten untersucht, um bereits proprietär gespeicherte Inhalte einzelner Layout-Programme möglichst komfortabel in ein internetfähiges Online-Format zu übertragen.

Die Notwendigkeit der Verarbeitung bereits gespeicherter Inhalte ergibt sich dadurch, dass sich entweder in der Praxis der Mehraufwand der medienneutralen Datenhaltung wirtschaftlich nicht für jedes Printprodukt lohnt, oder aber andererseits es bereits fertige Layout-Daten existieren, die in ein Online-Format umgewandelt werden sollen.

Neben technischen Hintergründen der Konvertierungsmethoden wird desweiteren auch auf das Workflow-Optimierungspotenzial einzelner Möglichkeiten eingegangen. Insbesondere werden die beiden Werkzeuge Adobe InDesign, als Print-Komponente, und das Content Management System TYPO3, als Online-Komponente, näher betrachtet.
Schließlich wird ein Vergleich der Konvertierungsmethoden unter verschiedenen Gesichtspunkten durchgeführt und bewertet.

III. Abbildungs- und Quellcode-Verzeichnis

IV. Abkürzungen

1.1 Motivation zur Themenwahl und persönliche Zielsetzung 2

1.2 Struktur der Ausarbeitung 3

1.3 Vorstellung der betreuenden Firma 3

2.1 Aktuelle Situation zur Verwertung von Inhalten 6

2.2 Zeitverlust durch manuelle Optimierung der Inhalte 6

2.3 Workflow-Optimierung als primäres Ziel 7

2.4 Bewertung der Konvertierungsmöglichkeiten und

Anwendung auf ein Beispiel-Szenario 7

3.1 Medienneutrale Datenhaltung – zur Diskussion 10

3.1.1 Vorteile medienneutraler Datenhaltung 10

3.1.2 Veränderung des Workflows 10

3.1.3 Umsetzung in der Praxis 11

3.1.4 Lösungsansatz 11

3.2 Definitionen 12

3.2.1 XML/(X)HTML/CSS 12

3.2.2 XSLT – Extensible Stylesheet Language Transformations 12

3.2.3 Web-to-Print 13

3.2.4 Print-to-Web 13

3.2.5 Content Management System (CMS) 13

3.2.6 MySQL 13

3.3 Anforderungen an den Print-to-Web-Workflow 14

3.3.1 Hoher Automatisierungsgrad des Konvertierungsprozesses 14

3.3.2 Hohe inhaltliche und technische Integrität 14

3.3.3 Hohe Usability 15

3.3.4 Barrierefreiheit 15

4.1 Adobe InDesign CS2/CS3 18

4.1.1 Das InDesign-Interchange-Format 18

4.1.2 (X)HTML-Export 19

4.2 QuarkXPress 7 20

4.2.1 QXML-Schema 20

4.2.2 HTML-Funktionen 20

4.2.3 Konvertierung der Dokumente in das InDesign-Format 21

5.1 Statische HTML-Seiten 24

5.2 Dynamische HTML-Seiten/Dynamische Webseiten 24

5.3 Content Management System 25

5.4 TYPO3 26

5.4.1 TypoScript 26

5.4.2 TYPO3-Extensions 27

5.4.3 MySQL 27

5.4.4 Die Benutzeroberfläche von TYPO3 28

6.1 PDF-Export aus Layoutapplikationen 32

6.1.1 Konvertierungsvorgang 32

6.1.2 Anforderungen an PDF-Dokumente 33

6.1.3 Manuelle Einbindung ins Web 33

6.1.4 Inhalts- und Navigationskomponenten im Browser 34

6.1.5 Automatische Einbindung in ein CMS (TYPO3) 34

6.2 Konvertierung auf Flash-Basis (ADE/Livepaper/speedPaper) 35

6.2.1 Adobe Digital Editions (ADE) 35

6.2.2 Livepaper 35

6.2.3 speedPaper 36

6.2.4 Manuelle Einbindung ins Web 36

6.2.5 Automatische Einbindung in ein CMS (TYPO3) 37

6.3 BatchXSLT – XML-Konvertierung aus Layoutapplikationen 38

6.3.1 Vorbereitungen für die Konvertierung 38

6.3.2 Analyse des Adobe InDesign-Interchange-Formates (INX) 40

6.3.3 BatchXSLT for InDesign 55

6.3.4 ImageMagick 56

6.3.5 Ghostscript 57

6.3.6 Funktionsweise von BatchXSLT 58

6.3.7 Auswertung der Export-Daten 59

6.3.8 Manuelle Einbindung ins Web 67

6.3.9 Automatische Einbindung in ein CMS (TYPO3) 67

6.4 (X)HTML-Export aus Layoutapplikationen 68

6.4.1 Konvertierungsvorgang 68

6.4.2 Einstellungsmöglichkeiten beim Export 69

6.4.3 Auswertung der Export-Daten 71

6.4.4 Weiterverarbeitung der Daten mittels Cascading Stylesheets 73

6.4.5 CSS-Frameworks 74

6.4.6 YAML – Yet Another Multicolumn Layout 74

6.4.7 blueprintcss 80

6.4.8 Manuelle Einbindung ins Web 85

6.4.9 Automatische Einbindung in ein CMS (TYPO3) 85

7.1 Mehrspaltiges Webseitenlayout 88

7.2 Grundlinienraster 89

7.3 Schriftenvielfalt – Neue Möglichkeiten mit SIFR 91

7.4 Silbentrennung im Internet 92

8.1 Zielsetzungen und deren Erreichungsgrade 96

8.2 Usability 97

8.3 Individuelle Konvertierungsmöglichkeiten und Erweiterungen 98

8.3.1 XSLT-Weiterverarbeitungsmöglichkeit 98

8.3.2 CSS-Weiterverarbeitungsmöglichkeit 98

8.4 Übersicht und firmeninterne Bewertung der Möglichkeiten 99

9.1 Optimierter Workflow der One Advertising AG 102

9.2 Magazin-Beispiel: Macwelt 102

11.1 Literaturverzeichnis 110

11.2 Stichwortverzeichnis 112

[Abb.: 1.01] Logo der One Advertising AG, www.advertising.de 3

[Abb.: 4.01] Screenshot, Splashscreen Adobe InDesign CS3 18

[Abb.: 4.02] Screenshot, Splashscreen QuarkXPress 7 20

[Abb.: 5.01] Logo TYPO3, www.typo3.org 26

[Abb.: 5.02] Screenshot, Benutzeroberfläche von TYPO3 28

[Abb.: 5.03] Screenshot, Modulbereich Web 29

[Abb.: 5.04] Screenshot, Modulbereich Datei 29

[Abb.: 5.05] Screenshot, Modulbereich Benutzer 29

[Abb.: 6.01] Screenshot, PDF-Export aus QuarkXPress 32

[Abb.: 6.02] Screenshot, Einstellungen beim PDF-Export aus QuarkXPress 32

[Abb.: 6.03] Screenshot, PDF-Export aus Adobe InDesign 32

[Abb.: 6.04] Screenshot, Einstellungen beim PDF-Export aus Adobe InDesign 32

[Abb.: 6.05] Screenshot, Betrachtung einer PDF-Datei in einem Browser 34

[Abb.: 6.06] Screenshot, ADE-Beispielumsetzung im Adobe Digital Reader 35

[Abb.: 6.07] Screenshot, Konversats mithilfe der Livepaper-Technologie 35

[Abb.: 6.08] Screenshot, ePaper-Konvertierung mittels speedPaper-Technologie 36

[Abb.: 6.09] Screenshot, Scripting-Palette von Adobe InDesign 38

[Abb.: 6.10] Screenshot, Vorschau: Leeres InDesign-Dokument 42

[Abb.: 6.11] Screenshot, Vorschau: InDesign-Snippet mit Textinhalt 43

[Abb.: 6.12] Screenshot, Vorschau: InDesign-Snippet mit Bildinhalt 43

[Abb.: 6.13] Screenshot, Meta-Informationen aus Adobe Bridge 43

[Abb.: 6.14] Screenshot, Meta-Informationen im Layoutprogramm 54

[Abb.: 6.15] Screenshot, Grafische Benutzeroberfläche von BatchXSLT 55

[Abb.: 6.16] Screenshot, Display: Benutzerinterface von ImageMagick 56

[Abb.: 6.17] Screenshot, Benutzerinterface von GSView 57

[Abb.: 6.18] Screenshot, Einstellungsmöglichkeiten in BatchXSLT 58

[Abb.: 6.19] Screenshot, Beispiel 1: Leeres Dokument 66

[Abb.: 6.20] Screenshot, Beispiel 2: Text-Snippet 66

[Abb.: 6.21] Screenshot, Beispiel 3: Bild-Snippet 66

[Abb.: 6.22] Screenshot, Medienübergreifender (X)HTML-Export aus InDesign 68

[Abb.: 6.23] Screenshot, Exportoptionen: Allgemein 70

[Abb.: 6.24] Screenshot, Exportoptionen: Bilder 70

[Abb.: 6.25] Screenshot, Exportoptionen: Erweitert 70

[Abb.: 6.26] Screenshot, Browserausgabe Beispiel 1 72

[Abb.: 6.27] Screenshot, Browserausgabe Beispiel 2 72

[Abb.: 6.28] Screenshot, Browserausgabe Beispiel 3 72

[Abb.: 6.29] W3C-CSS-Boxmodell, www.linkwerk.com 73

[Abb.: 6.30] Logo T3N-Magazin, www.t3n-magazin.de 79

[Abb.: 6.31] Screenshot, YAML Grundgerüst für TYPO3 79

[Abb.: 6.32] Screenshot, blueprintcss: Beispielseite 85

[Abb.: 7.01] Screenshot, blueprintcss: Gestaltungsraster 88

[Abb.: 7.02] Screenshot, blueprintcss: Mikrotypografie 90

[Abb.: 7.03] Screenshot, SIFR deaktiviert 91

[Abb.: 7.04] Screenshot, SIFR aktiviert 91

[Abb.: 7.05] Screenshot, Silbentrennung 93

[Abb.: 9.01] Cover Macwelt 01/2008, www.macwelt.de 102

[Abb.: 9.02] Screenshot, Macwelt ePaper-Konvertierung (Artikel) 103

[Abb.: 9.03] Screenshot, Macwelt ePaper-Konvertierung (Tabelle) 103

[Abb.: 10.10] Wikipedia, Grafische Darstellung Web2.0, www.wikipedia.de 107

[Code: 6.01] HTML-Aufruf einer PDF-Datei 33

[Code: 6.02] Filelink (TypoScript) 34

[Code: 6.03] Einbinden einer Flash-Datei mit der objekt-embed Kombination 37

[Code: 6.04] Einbinden einer Flash-Datei gemäß (X)HTML-Standard 37

[Code: 6.05] Einbinden einer Flash-Datei in TYPO3 als HTML-Objekt 37

[Code: 6.06] Quellcode: BXSLTExport.jsx 39

[Code: 6.07] INX: XML-Deklaration, Verarbeitungsanweisung, Wurzelelement 40

[Code: 6.08] INX: Leeres InDesign Dokument 48

[Code: 6.09] INX: InDesign-Snippet-Text 50

[Code: 6.10] INX: InDesign-Snippet-Bild 52

[Code: 6.11] INX: InDesign Meta-Informationen 54

[Code: 6.12] XML: Leeres InDesign Dokument 59

[Code: 6.13] XML: InDesign-Snippet-Text 61

[Code: 6.14] XML: InDesign-Snippet-Bild 62

[Code: 6.15] Quellcode: xml2htmEpaper.xsl 66

[Code: 6.16] HTML-Aufruf einer XML-Datei 67

[Code: 6.17] XML-Transformationsmöglichkeit in PHP 67

[Code: 6.18] (X)HTML: Leeres InDesign Dokument 71

[Code: 6.19] (X)HTML: InDesign-Snippet-Text 71

[Code: 6.20] (X)HTML: InDesign-Snippet-Bild 72

[Code: 6.21] Inhalt einer CSS-Datei 73

[Code: 6.22] Eigenschaften eines div-Containers 73

[Code: 6.23] YAML: base.css 77

[Code: 6.24] blueprintcss: grid.css 83

[Code: 6.25] blueprintcss: typography.css 84

[Code: 6.26] HTML-Aufruf einer HTML-Datei 85

[Code: 7.01] Grundlinienraster, Standardschriftgröße und Zeilenabstand 89

[Code: 7.02] Grundlinienraster, Absatzformate 90

[Code: 7.03] Grundlinienraster, Überschriftenformat h1 90

[Code: 7.04] Grundlinienraster, Überschriftenformat h2 90

[Code: 7.05] Skript-Einbindung: Hyphenator.js 93

[Code: 7.06] Skript-Aufruf: Hyphenator.js 93

ADE – Adobe Digital Editions

AJAX – Asynchronous JavaScript and XML

API – Application Programming Interface

BE – Backend

BMP – Windows Bitmap

CGI – Common Gateway Interface

CI – Corporate Identiy

CJK – CJK-Schriftarten (Chinesisch, Japanisch, Koreanisch)

CMS – Content-Management-System

CMYK – Cyan, Magenta, Yellow, Key (Schwarz)

CSS – Cascading Stylesheets

DBMS – Datenbankmanagementsystem

DIV – Division (Block/Bereich)

DOM – Document Object Model

DPI – Auflösung in Dots per Inch

DRM – Digital Rights Management

DTP – Desktop Publishing

EDV – Elektronische Datenverarbeitung

EPS – Encapsulated Postscript

FAQ – Frequently Asked Questions

FE – Frontend

FTP – File Transfer Protocol

GUID – Globally Unique Identifier

GIF – Graphics Interchange Format

GNU – GNU‘s Not Unix

GPL – General Public License

GS – GhostScript

GZ/ZIP – Dateiarchiv (PKzip Dateierweiterung)

HTM/HTML – Hypertext Markup Language

HTTP – Hypertext Transfer Protocol

ID – Identifikationsnummer

INDD – InDesign-Dokument

INDS – InDesign-Snippet

INX – InDesign-Interchange-Format

ISO – Internationale Organisation für Normung

JAVA VM – Java Platform, Virtual Machine

JPG/JPEG – Joint Photographic Experts Group

JS/JSX – Javascript

LAMP – Linux-Apache-MySQL-PHP-Kombination

MAMP – MacOS-Apache-MySQL-PHP

MIME – Multipurpose Internet Mail Extension

MPG/MPEG – Moving Picture Experts Group

OS – Operation System

PCX – Picture Exchange

PDA – Personal Digital Assistant

PDF/PDF X-3 – Portable Document Format

PID – Packet Identifier

PHP – PHP: Hypertext Preprocessor

PNG – Portable Network Graphics

PPML – Personalized Print Markup Language

PS – Postscript

PSD – Photoshop-Dokument

QXML – QuarkXpress Markup Language

RA/RAM – RealAudio

RDF – Resource Description Framework

RGB – Rot, Grün und Blau

RIA – Rich Internet Application

RTF – Rich Text Format

SEO – Search Engine Optimization

SGML – Standard Generalized Markup Language

SIFR – Scalable Inman Flash Replacement

SQL – Structured Query Language

SSMC – Single-Source Multi-Channel

SWF – Small Web Format/Flash-Dateien

TIFF – Tagged Image File Format

TT, TX – TYPO3-Extensions

TXT – Text

UID – Unique Identifier

URI – Uniform Resource Identifier

W3C – World Wide Web Consortium

WAMP – Windows-Apache-MySQL-PHP-Kombination

WAV/WAVE – Windows Media Audio Wave Dateiformat

WWW – World Wide Web

(X)HTML – (Extensible) Hypertext Markup Language

XAMPP – X (betriebssystemunabhängig) Apache-MySQL-PHP-Kombination

XMP – Extensible Metadata Platform

XML – Extensible Markup Language

XPath – XML Path Language

XSL – Extensible Stylesheet Language

XSLT – Extensible Stylesheet Language Transformations

YAML – Yet Another Multicolumn Language

Das Thema „Print-to-Web – Neue Möglichkeiten der Datenkonvertierung“ hätte nicht treffender – so wie in diesem Zitat formuliert – eingeleitet werden können. In der folgenden Ausarbeitung werden genau diesen besseren Lösungen gesucht und einzelne Verfahren miteinander verglichen.

Die Potenziale einzelner Konvertierungsmethoden, die Inhalte aus Print-Produkten in onlinefähigen Web-Content überführen, werden oft nicht richtig erkannt, zu oberflächlich behandelt und dann in der Praxis an den Anforderungen des Ausgabemediums vorbei realisiert.

Gerade als Person mit einer starken Affinität zu Printmedien, habe ich es als interessante Herausforderung betrachtet,
in Zusammenarbeit mit einer auf Online-Medien und Digitales Marketing spezialisierten Firma, der One Advertising AG [2] aus München, einen Vergleich der Konvertierungsmöglichkeiten vorzunehmen, um mit dieser Ausarbeitung im Produktionsalltag die beiden Welten um Print und Web ein Stück näher zusammen bringen zu können.

Wichtigster Aspekt dieser Untersuchung ist aus Firmensicht die zeitliche Optimierung der Datenaufbereitung von Inhalten aus Print-Dokumenten für eine optisch und benutzermäßig dem Medium Internet angemessene Darstellungsweise.

Desweiteren stellt sich die Frage nach der Wirtschaftlichkeit der Konvertierungsmethoden – genauer, nach dem Arbeitsaufwand und den Zeitvolumina, welche für eine Datenaufbereitung der Inhalte für eine Zweitverwertung benötigt werden. Letztendlich spielt auch die Integration in den firmeninternen Workflow eine wichtige Rolle: Umstellungen des Arbeitsablaufes und Sekundärinvestitionen sollten nach Möglichkeit minimal ausfallen.

Persönlich ergibt sich für mich durch diese Ausarbeitung einerseits eine starke Horizonterweiterung in Richtung Online-Medien und andererseits eine fachliche Vertiefung in die Analyse des XML-basierten Adobe InDesign-Interchange-Formats und dessen weiteren Bearbeitungsmöglichkeiten sowie in die Datenaufbereitung für das Content Management System TYPO3.

Zu Beginn dieser Ausarbeitung geht es um die thematische Problembeschreibung der Datenaufbereitung von Print-Dokumenten für eine Zweitverwertung in einem Onlinemedium, um die Definition der Rahmenbedingungen in der Firma und die anschließende Skizzierung der angestrebten Ziele.

Nach einer durchaus kritischen Betrachtung des Prinzips der medienneutralen Datenhaltung, werden zunächst die – die Problemstellung betreffenden – Print- und Web-Komponenten betrachtet und einzelne Funktionen näher beschrieben. Anschließend folgt mit der Untersuchung und dem Vergleich verschiedener Konvertierungsmöglichkeiten, um Inhalte von Print-Dokumenten in onlinefähige Formate übertragen zu können, der Kernbereich dieser Ausarbeitung.

Es werden vier Ansätze vorgestellt, die jeweils auf einer anderen Basistechnologie (PDF, Flash, XML, HTML) aufbauen.

Aus den Untersuchungsergebnissen resultiert dann die Empfehlung einer bestimmten Konvertierungsart, die – den angestrebten Zielen der Firma entsprechend – am ehesten geeignet ist. Zuletzt wird die Umsetzung dieser präferierten Methode anhand eines Beispiels aus der Praxis gezeigt.

Die One Advertising AG ist eine Agentur für Digitales Marketing und entwickelt performance-orientierte Lösungen für Online Marketing, Online Vertrieb und Online Kommunikation.

Sie wurde 2006 von den beiden Online Marketing Experten Christian Spieker und Andreas Kelnberger gegründet.

Die One Advertising AG bietet ihren Kunden aufgrund der interdisziplinären Kompetenz in den Bereichen Gestaltung und Technologie ein integriertes Dienstleistungsangebot für Digitales Marketing von der Konzeption über die Kreation bis zur technischen Umsetzung von performance-orientierten Online Kampagnen.

Innerhalb kurzer Zeit konnte die One Advertising AG namhafte Kunden von ihrer Leistungsfähigkeit überzeugen: 1&1 Internet AG, Quelle, TUI, IDG Mediengruppe, United Internet AG.

Oftmals sind bereits vorhandene Satzdateien von Drucksachen Ausgangsmaterial für eine Webpräsenz, da bei vielen kleinen und mittleren Unternehmen Webdesign bisher eher als ein Nebenprodukt der Werbepräsenz behandelt wurde. Erst so langsam entwickelt sich ein eigenständiges Bewusstsein im Umgang mit Online-Medien und somit auch die Wichtigkeit der Kommunikation aktueller Informationen. Auch Zeitschriften- und Zeitungsverlage fusionieren ihre Online- und Printsparten, damit die Inhalte der Produkte parallel – und nicht nicht wie bisher linear vom Layoutdokument hin zum onlinefähigen Format – in die jeweiligen Vertriebskanäle gelangen kann und somit Synergieeffekte [3] und Kosteneinsparungen bei den Konvertierungsvorgängen erzielt werden können.

Trotz dieser Bemühungen bleibt letztendlich aber die Frage nach den Konvertierungsmöglichkeiten von bestehendem Material und den Wegen, diese Inhalte für eine Zweitverwertung aufzubereiten, weiter offen. Ein medienneutraler Workflow würde zwar viele dieser Probleme beseitigen, doch aufgrund der Vielfalt der Produkte und der Individualität der Arbeitsabläufe der One Advertising AG wirtschaftlich sich nicht rentieren.

Bei der Wiederaufbereitung der Inhalte kann man grob zwischen allgemeinen Gestaltungselementen, Bildern und Texten unterscheiden.

Besonders bei der Aufbereitung bestehender Textinhalte erweisen sich proprietär [4] in das jeweilige Dokument eingearbeitete Zusatzinfomationen, sanfte und harte Zeilenumbrüche, Farbe, Größe und Schriftart eher hinderlich als hilfreich. Die reichen typografischen Möglichkeiten, die in der Druckvorstufe zur Verfügung stehen, lassen sich leider nicht ohne Weiteres in Webseiten umsetzen.

Inhalte aus bestehenden Satzdateien können daher erst nach zum Teil beachtlichen Nach- und Umarbeitungen für verschiedene Ausgabemedien genutzt werden.

Um dem Inhalt bei unterschiedlichen Verwendungszwecken ein einheitliches „Look and Feel“ [5] zu geben, ist eine Aufbereitung der Textinformation und der Bilder sowie eine optische Optimierung des Gestaltungsrahmens entsprechend den – durch das Ausgabemedium festgelegten Rahmenbedingungen – unumgänglich. Der hieraus resultierende höhere Zeitbedarf ergibt sich zwangsläufig.

Primäres Ziel dieser Untersuchung ist eine Optimierung des Arbeitsablaufes ohne große Veränderungen des bestehenden Workflows zu erzeugen.

Die Analyse verschiedener Konvertierungsmöglichkeiten wird mit dem Ziel durchgeführt, Inhalte von Archivmaterialien, sowie Daten aus laufenden und zukünftigen Print-Produktionsprozessen bei Bedarf in ein onlinefähiges Format konvertieren zu können, ohne den internen Ablauf der Produktion umfassend verändern zu müssen. Eine zu erzielende Kosteneinsparung durch zeitlich verkürzte Arbeitsabläufe mit möglichst hohem Automatisierungsgrad hat bei dieser Untersuchung oberste Priorität. Dennoch sollte die Qualität der optischen Darstellung und der technischen Umsetzung entsprechend den Anforderungen des Ausgabemediums auf einem hohen Niveau gehalten werden.

Der Kunde beziehungsweise Mitarbeiter sollte die Möglichkeit haben, jederzeit entscheiden zu können, ob ein weiterer Ausgabekanal neben dem Printmedium bedient wird – ohne den permenenten Mehraufwand einer medienneutralen Datenhaltung oder des datenbankbasiertem Layouts eingehen zu müssen.

Die untersuchten Möglichkeiten werden anschließend nach den Zielerreichungsgraden – gemessen an den Anforderungen und Rahmenbedingungen des Firmen-Workflows – verglichen.

Wichtige Entscheidungskriterien sind zum einen ein hoher Automatisierungsgrad bei der Konvertierung, eine hohe inhaltliche und technische Integrität sowie ein hoher optischer Wiedererkennungswert zum Printmedium beziehungsweise zum Corporate Design.

Zuletzt werden sowohl die Potenziale als auch die technischen Grenzen der Gestaltungsmöglichkeiten in Print und Web verglichen, das Konversat auf die Verständlichkeit bei der Interaktion mit dem Benutzer hin untersucht und außerdem die jeweiligen Konfigurations- und Erweiterungsmöglichkeiten miteinander verglichen. Durch eine Bewertung mithilfe gewichteter Faktoren wird eine Entscheidung für das Verfahren der Wahl getroffen und schließlich anhand einer Beispielumsetzung belegt.

Die Motivation diese Herausforderung anzugehen ist verständlicherweise sehr hoch, aber so lange nicht alle technischen Komponenten und alle beteiligten Anwender in der Produktionskette das XML-Format unterstützen, wird sich die medienneutrale Datenhaltung nicht für jedes Produkt in der Praxis lohnen.

Vor allem, wenn es sich um rein statische Inhalte handelt, steht die Vorbereitung und Realisierung einer neutralen Produktionsbasis für ein einzelnes Produkt in keinem Verhältnis zum dem weiteren Einsparungspotential.

Die Umsetzung des Modells der medienneutralen Datenhaltung ist in der Praxis mit einem nicht zu unterschätzenden Aufwand verbunden.

Für einige Produktionen ist diese Arbeitsweise überaus sinnvoll, für viele kleinere Produktionen, bei denen die Inhalte erst noch aufwändig semantisch strukturiert werden müssen, eher weniger.

Eine medienneutrale Datenhaltung basiert auf einer Datenbank, in der die Inhalte des Produktes medienneutral im XML-Format gespeichert werden.

Aus dieser Datenbank werden dann die verschiedenen Ausgabemedien bedient. Es findet somit eine klare Trennung zwischen dem Inhalt und der jeweiligen für das Ausgabemedium entsprechenden optischen Ausprägung statt.

Medienneutrales Datenmanagement führt zu umfassenden Veränderungen der internen Agentur- und Herstellungsabläufe und die beteiligten Mitarbeiter sind mit einer Umorganisation der beste

henden Prozesse konfrontiert. Diese Veränderungen beziehen sich zum einen auf die internen Abläufe, zum anderen aber auch auf das Zusammenspiel mit externen Dienstleistern (insbesondere Satz- und Druckbetrieben, sowie freien Mitarbeitern).

Die optimale aufbau- und ablauforganisatorische Integration [8,9] eines medienneutralen Workflows ist stark von den spezifischen Rahmenbedingungen abhängig und daher von Unternehmen zu Unternehmen unterschiedlich zu lösen.

In der Praxis geht die Tendenz bei vielen Anwendern eher zur der folgenden Workflow-Variante: Bei dieser bleibt die interne Arbeitsweise weitgehend unverändert und die Erstellung der XML- und HTML-Daten wird auf externe Dienstleister übertragen.

Vorteile bestehen insbesondere darin, dass die XML/HTML-Konvertierung sehr kostengünstig durchgeführt werden kann und sich keine großen Veränderungen im Arbeitsumfeld des Unternehmens ergeben.

Nachteil ist jedoch, dass durch das lineare Verfahren ein Zeit- und Aktualitätsproblem entsteht, da die XML/HTML-Daten in der Regel erst nach der Druckfreigabe für das Printprodukt zur Verfügung stehen. Desweiteren ist die Qualität und Korrektheit der Daten bei der Bearbeitung durch externe Dienstleister oft nicht ausreichend.

Diese Art des Praxiseinsatzes entspricht nicht dem Bild des idealen Cross-Media-Verständnisses. Sie kann aber aus organisatorischen und insbesondere betriebswirtschaftlichen Gründen für die Praxis des jeweiligen Unternehmens die geeignete Form der Umsetzung sein.

Um eine Konvertierung ohne Veränderung des Produktionsprozesses zu ermöglichen, muss ein Konvertierungsverfahren so modular in den Arbeitsprozess – jederzeit und nur nach Bedarf – eingreifen können, dass sich keine Wechselbeziehungen und sonstigen Abhängigkeiten sowie zeitlichen Verzögerungen zwischen Print- und Web-Ausgabe ergeben.

Der theoretische Idealfall einer vollständigen Automatisierung mit Ausgabe einer optimal auf das Medium zugeschnittenen Daten-Charakteristik, ist auf dieser Basis nicht möglich. Für diese Belange gibt es wiederum medienneutrale XML-Produktionen, die aber einen gewissen Mehraufwand und sorgfältige Vorbereitung benötigen. Die totale Flexibilität aus struktureller Sicht und die Möglichkeit, lokale Korrekturen des optischen Erscheinungsbildes vornehmen zu können, sind dann aber nicht gegeben.

So ergibt sich schießlich die Notwendigkeit, einen idealen Kompromiss zwischen den beiden Ausrichtungen Flexibilität und Automatisierung zu finden, damit sowohl xml- als auch nicht-xml-basierte Print-Dokumente für eine Zweitverwertung aufbereitet werden können.

In diesem Abschnitt sind einige grundlegende Begriffe definiert, die feste Bestandteile des Cross-Media-Workflows sind.
Kleinere Definitionen und detailliertere Ergänzungen sind im gesamten Dokument in den Marginalspalten beschrieben.

XML (Extensible Markup Language) = Auszeichnungssprache. XML ist hierarchisch strukturiert und trennt Struktur und Inhalt. XML ist ein wichtiger Standard für eine medienneutrale Verarbeitung von Inhalten.

(X)HTML (Extensible Hypertext Markup Language) = XML-basierte Auszeichnungssprache im Internet. Browser ab der vierten Generation kommen mit diesem Standard gut zurecht.

CSS (Cascading Style Sheets) = Formatierungssprache. Ermöglicht die Trennung von Inhalt und Layout. Layouteigenschaften wie zum Beispiel Schriftarten und Schriftgrößen werden über CSS ähnlich wie Formatvorlagen deklariert. CSS-Dateien können aus HTML-Dateien ausgelagert werden.

Die Sprache XSLT beschreibt die Umwandlung eines XML-Derivats in ein anderes Dokument. Diesen Vorgang nennt man Transformation. Das resultierende Dokument entspricht meist der XML-Syntax, es können aber auch andere Textdateien und sogar Binärdateien erstellt werden.

Dazu werden die XML-Dokumente als logischer Baum betrachtet: Die Quellbäume der zu transformierenden Dokumente und die durch die Transformation entstehenden Zielbäume der zu erzeugenden Dokumente.

Eine Transformation besteht aus einer Reihe von einzelnen Transformationsregeln, die Templates genannt werden. Ein Template besitzt ein auf XPath [12] basierendes Pattern [13], das beschreibt, für welche Knoten es gilt, und einen Inhalt, der bestimmt, wie das Template seinen Teil des Zielbaums erzeugt.

Die Grundlage für Web-to-Print-Verarbeitungen sind immer vordefinierte Vorlagen. Während der eine Hersteller auf XML zur Erzeugung setzt, nutzt ein anderer PDF-Formulare und wieder ein
anderer Vorlagen aus Adobe InDesign oder QuarkXPress. „Web-to-Print“ ist ein Verfahren der Online-Erzeugung von Druckvorlagen via Internet mithilfe serverbasierter Layout-Technologie, die Server-Templates und Client-Eingaben miteinander kombiniert.

Print-to-Web beschreibt den Weg der Überführung von Informationen aus Print-Dokumenten in den Online-Bestand. Falls nicht die Inhalte des Printproduktes selbst aus einer XML-Datenquelle erzeugt wurden, gilt es, nach Möglichkeiten zu suchen, bereits proprietär gespeicherte Daten wieder in andere Dimensionen bearbeitbar zu machen und webgerecht aufzubereiten.

Unter Content Management versteht man die systematische und strukturierte Erzeugung, Aufbereitung, Verwaltung, Darstellung und Verarbeitung von Inhalten. Am Anfang steht die Unterscheidung von Inhalt und Darstellung. Traditionelle HTML- als auch PDF-Dokumente weisen eine Verzahnung von Inhalt und Darstellung auf. Die Struktur des Dokumentes erlaubt es nicht, zwischen Inhaltsobjekten genauer differenzieren zu können. In einem HTML-Dokument lässt sich aufgrund der Struktur nicht erkennen was Headline, Subline oder etwa Kommentar ist. Die konsequente Trennung von Inhalt und Darstellung dagegen speichert den Inhalt – also Headline, Subline, Text, Bilder – sowie die Darstellung – also Farbe, Formatierung, Aussehen, Gestaltungselemente – separat. Die Darstellungsdatei, oftmals das sogenannte Template [14], kennzeichnet an bestimmten Positionen die dort einzufügenden Inhaltsobjekte. Der Inhalt wird oft in einer Datenbank gespeichert, wo er administriert werden kann.

MySQL ist ein Multi-Thread und Multi-User SQL-Datenbank-Server. SQL steht für Structured Query Language. MySQL ist als Open-Source-Software für verschiedene Betriebssysteme verfügbar und bildet die Grundlage vieler Webauftritte.

Ein bevorzugtes Einsatzgebiet von MySQL ist die Datenspeicherung für Web-Services. MySQL wird häufig in Verbindung mit dem Webserver Apache [15] und PHP eingesetzt. Diese Kombination wird entsprechend der Anfangsbuchstaben der beteiligten Software als LAMP, MAMP beziehungsweise WAMP (XAMPP) bezeichnet, je nachdem ob als Betriebssystem Linux, Mac OS oder Windows benutzt wird. MySQL wird in vielen Produkten als eingebettetes Datenbanksystem eingesetzt – so arbeitet innerhalb von TYPO3 eine Datenbank auf MySQL-Basis.

Zur Festlegung der Vergleichskriterien verschiedener Konvertierungsmöglichkeiten wurden in Zusammenarbeit mit der One Advertising AG die folgenden Anforderungen an den „Print-to-Web“-Workflow definiert.

Wichtige Gesichtspunkte sind zum einen ein hoher Automatisierungsgrad des Konvertierungsprozesses, um kosteneffizient eine Zweitverwertung der Inhalte herstellen zu können, zum anderen ist aber auch der zielgruppenspezifische Nutzungsgehalt des Konversats und die Benutzbarkeit im Ausgabemedium entscheidend.

Alles wird natürlich unter der Berücksichtigung eines hohen Qualitätsniveaus, sowohl bei der optischen Darstellung und Wiedererkennung zum Print-Dokument beziehungsweise zum Corporate Design [16], als auch bei der technischen Umsetzung entsprechend den Anforderungen des Ausgabemediums und entsprechend im Internet validierbarer Gütekriterien [17] betrachtet.

Der Grad der Automatisierung hängt zum einen von der Qualität des Ausgangsmaterials und zum anderen von der Individualität des jeweiligen Konvertierungsprozesses ab. Dabei kann der Automatisierungsgrad von der Teil- bis hin zur Vollautomatisierung reichen.

Ein wesentlicher Faktor dabei ist die Layoutgestaltung: So ist der Automatisierungsgrad für einheitlich gestaltete und wiederkehrende Produkte höher als für Dokumente mit individuellen Designs.

Wenn alle Inhalte konvertiert und zu einer Webseite zusammengefügt wurden, wird die Prüfung des gesamten Systems durchgeführt.

Dieser Funktions- und Qualitäts-Test kann sowohl im Intranet als auch in einer externen Testrunde durchgeführt werden.

Im Rahmen einer externer Testgruppe können auch Personen aus der Zielgruppe eingebunden und somit Usability-Tests durchgeführt werden.

Eine Definition des Begriffes Usability stammt aus der Software-Ergonomie:

Obwohl die Entwickler dieser Norm dabei an die ergonomische Gestaltung von Software dachten, lässt sie sich genauso gut auf Webseiten anwenden.

Die Effektivität bezeichnet die Genauigkeit und Vollständigkeit, mit der ein Nutzer sein Ziel erreichen kann. Unterstützen können ihn Hilfefunktionen, verschiedene Sortieroptionen oder Navigationsmöglichkeiten zum selben Ziel.

Die Effizienz beschreibt, mit welchem zeitlichen Aufwand der Nutzer seine Aufgabe auf der Webseite lösen kann. Sie ist sehr stark von der Navigation abhängig, aber auch von technischen Parametern wie Ladezeiten und der Performance des Webservers.

Die Zufriedenheit beschreibt das subjektive Empfinden des Nutzers, sein Erleben der Interaktion. Der Nutzungskontext spielt eine zentrale Rolle bei der Definition, Entwicklung und Bewertung der Usability einer Webseite. Er beinhaltet auf der einen Seite den Benutzer (Eigenschaften, Erwartungshaltung, Gefühlswelt, Ziele und Aufgaben) und auf der anderen Seite die Kommunikationsabsichten des Anbieters und die Zielsetzung der Webseite.

Barrierefreies Internet bezeichnet Internet-Angebote, die von allen Nutzern unabhängig von körperlichen und/oder technischen Möglichkeiten uneingeschränkt genutzt werden können. Dies schließt sowohl Menschen mit und ohne Behinderungen, als auch Benutzer mit technischen (zum Beispiel Handy oder PDA) oder altersbedingten Einschränkungen (zum Beispiel Sehschwächen) sowie Webcrawler [19] ein, mit denen Suchmaschinen den Inhalt einer Seite erfassen.

Auch nichtbehinderten Nutzern soll nicht die Pflicht auferlegt werden, beim Abruf von Internet-Angeboten genau dieselbe Hard- und Softwarekonfiguration zu verwenden wie der Autor des Angebots.

Neben der Zugänglichkeit geht es hier auch um Plattformunabhängigkeit – ein Internetangebot soll sowohl mit Bildschirm als auch mit PDA oder Handy nutzbar bleiben. Es soll unabhängig vom verwendeten Betriebssystem und von der Software funktionieren. Mindestens ebenso wichtig wie technische Zugangsbedingungen ist, dass die Inhalte übersichtlich und in leicht verständlicher Sprache präsentiert werden.

InDesign ist ein Desktop-Publishing-Programm von Adobe Systems und gehört mit QuarkXPress zu den marktführenden DTP-Layoutprogrammen.

Mit diesem Programm ist es möglich in beliebigen Seitenformaten ein- oder mehrseitige Layouts zu erstellen. Dazu werden Elemente auf den Seiten in
Form von Rahmen angebracht, die anschließend mit Inhalten wie Text, Bildern und Tabellen oder auch mit anderen Objekten gefüllt werden.

Rahmen- und Inhaltsfarben, Zeichen- und Absatzattribute, verwendete Konturstile, Transparenzen, Effekte und andere Parameter können dabei frei und flexibel definiert und in Stilvorlagen für die spätere Wiederverwendung gespeichert werden.

Der (X)HTML-Export aus Adobe InDesign ermöglicht Publikationen in mehrere Ausgabekanäle, indem InDesign-Inhalte als (X)HTML-Dateien exportiert werden. Bearbeitet werden die exportierten Dateien anschließend im Web-Editor und können mithilfe von Cascading Style Sheets formatiert werden.

Durch XML-Export eines InDesign CS3-Dokuments in das InDesign-Interchange-Format kann es in InDesign CS2/CS geöffnet werden. Desweiteren dient das Format als Ausgangsbasis für xml-basierte Konvertierungen.

Das Interchange Format ist ein XML-basiertes Format, welches benutzt wird um das InDesign-DOM [2o] abzubilden und weiter verarbeiten zu können. Das Format wird gewöhnlich als Austauschbasis genutzt, InDesign-Dokumente in ältere Programmversionen zurückzuspeichern.

Eine INX-Datei ist der augelesene Zustand der DOM-Struktur eines InDesign-Dokumentes. Jedes InDesign-Dokument wird als eine Baumstruktur von Objekten, die allesamt in einem Wurzelobjekt zusammengefasst sind, beschrieben.

Beispielsweise hat jedes Dokument Farbeigenschaften und Ausdehnungseigenschaften, die als Unterelemente im Wurzelelement gelistet sind. Neben weiteren Kind-Elemente, kann jedes einzelne Objekt Eigenschaften und Attribute haben. Das Objekt color hat beispielsweise Eigenschaften, die den Farbnamen, den Farbraum und die Farbwerte beschreiben.

Wenn ein InDesign-Dokument in das INX-Format exportiert wird, wird jedes Objekt mit seinen gesamten Eigenschaften

und Werten in ein XML-basiertes Format überführt. Beim erneuten Importieren, werden all diese Informationen dann benutzt, um ein neues InDesign-Dokument zu generieren.

Innerhalb der gleichen Programmversion von Adobe InDesign wird beim Exportieren und beim anschließendem Re-Importieren der INX-Datei, ein komplett zum Original identisches Dokument erzeugt.Eine neuere Version einer INX-Datei kann bestimmte Objekte oder Objekteigenschaften besitzen, die in einer älteren Programmversion von Adobe InDesign nicht interpretierbar sind und deswegen beim Import ignoriert werden. Daher kann das neu generierte InDesign-Dokument vom Original abweichen.

InDesign-Snippets [21] sind einzeln isolierte InDesign-Objekte. Diese Objekte werden auch auf der XML-Basis des Adobe InDesign Interchange-Formats exportiert. InDesign-Snippets werden in dieser Ausarbeitung dazu benötigt, um beispielhaft den XML-Quellcode von einzelnen Objekten vereinfacht beschreiben zu können.

Das Exportieren in (X)HTML ist eine einfache Möglichkeit, InDesign-Inhalte in eine internetfähige Form zu bringen. Wenn Inhalte in das (X)HTML-Format exportiert werden, kann man zwar festlegen wie mit Bildern verfahren wird, die Textformatierung bleibt jedoch nicht erhalten. Die Namen von Absatz-, Zeichen-, Objekt-, und Tabellenformaten aus InDesign, die auf die exportierten Inhalte angewendet wurden, werden dagegen übernommen. Diese (X)HTML-Inhalte werden mit gleichnamigen CSS-Formatklassen gekennzeichnet.

InDesign exportiert alle Textabschnitte, verknüpfte und eingebettete Bilder, Fußnoten, Textvariablen (als Text), Aufzählungs- und nummerierte Listen sowie auf Text verweisende Hyperlinks. Tabellen werden ebenfalls exportiert, bestimmte Formatierungen, wie zum Beispiel Tabellen- und Zellkonturen, werden jedoch nicht exportiert.

InDesign exportiert keine gezeichneten Objekte (wie zum Beispiel Rechtecke, Ovale und Polygone), keine Filmdateien (abgesehen von SWF-Dateien), Hyperlinks (abgesehen von auf Text verweisende Hyperlinks), eingefügten Objekte (einschließlich eingefügten Illustrator
Bildern), keinen in Pfade konvertierten Text, keine XML-Tags, Bücher, Lesezeichen, Glyphen [22], Indexmarken, Objekte auf der Montagefläche oder Musterseitenobjekte (es sei denn, diese wurden manuell überschreiben oder vor dem Export ausgewählt).

InDesign bestimmt die Lesereihenfolge von Seitenobjekten durch Scannen von links nach rechts und von oben nach unten. Manchmal werden die Design-Elemente nicht in der gewünschten Lesereihenfolge angezeigt – dies kann insbesondere bei komplexen Dokumenten mit mehreren Spalten vorkommen. Das Gruppieren zusammengehöriger Elemente kann die Lesereihenfolge beim Export beeinflussen.

QuarkXPress ist ein rahmenorientiertes Layoutprogramm des US-amerikanischen Herstellers Quark Inc. und gehört mit InDesign zu den marktführenden DTP-Layoutprogrammen. QuarkXPress verfügt wie Adobe InDesign über zahlreiche im Bereich der Printmedien unverzichtbare Funktionen.

Seit QuarkXPress 5 können mit dem Programm auch direkt HTML-Webseiten erstellt werden, ohne auf externe Programm zugreifen oder sich mit HTML auseinanderzusetzen müssen.

Aufgrund der Tatsache, dass diese Ausarbeitung den Schwerpunkt auf die Layoutapplikation Adobe InDesign setzt, werden die Konvertierungsvarianten mit QuarkXPress teilweise gekürzt, teilweise auch nur auf kurze Stichpunkte verweisend beschrieben.

Wichtigster Unterschied zu den bisherigen Xpress-Versionen ist das völlig neue Dateiformat von Xpress 7. Quark setzt dabei mit QXML (Quark Xpress Markup Language) auf ein offenes Dateiformat, das die Spezifikationen von W3C [23] und Xpath berücksichtigt.

So lassen sich alle Bestandteile eines Xpress-Projektes als XML verfügbar machen, was die Weiterverarbeitung für andere Programme oder Ausgabegeräte erleichtert. Um Databased Publishing in Xpress zu erleichtern, hat Quark der Layoutsoftware die so genannte Personalized Print Markup Language (PPML) hinzugefügt. So sollen sich Xpress-Projekte besser für verschiedene Layouts in Print und Web aufbereiten lassen.

Per Quark XPress-DOM-Schnittstelle werden Dokumente für XTensions schreib- und lesbar. Somit sollen alle Bestandteile eines Layouts als XML verfügbar sein, um in weiteren Programmen oder ganzen Workflows problemlos und einheitlich verarbeitet werden zu können. Um die Entwicklungsarbeit noch weiter zu vereinfachen, stellt QXML QuarkXPress Projekte als XML-Baum dar. Alle Modifikationen an den XML Dateien wirken sich direkt auf das QuarkXPress Projekt aus.

Im Gegensatz zu anderen Programmen für die Webseitengestaltung ist QuarkXpress kein HTML-Editor. Das Web-Layout ist nur eine spezielle Benutzerumgebung zur Gestaltung von Webseiten, die man anschließend in das HTML-Format ex

portiert. Muss am Layout etwas geändert werden, öffnet man das XPress-Projekt, macht die Korrekturen und exportiert erneut in das HTML-Format.

Beim Gestalten eines Web-Layouts lassen sich die gewohnten XPress-Werkzeuge einsetzen; Funktionen, die in einem HTML-Dokument nicht umsetzbar sind, schaltet XPress aus.

Eine weitere Möglichkeit ein Web-Layout zu erzeugen, ist die Umwandlung eines Print-Layouts. Eine saubere HTML-Datei bekommt man dadurch aber nicht, denn QuarkXPress exportiert alle Elemente des umgewandelten Print-Dokumentes als Bildelemente, auch die Textrahmen!

InDesign kann Dokumente aus QuarkXPress 3.3 oder 4.1x konvertieren. Zum Konvertieren von Dokumenten aus QuarkXPress 5.0 oder höher müssen die Dokumente in QuarkXPress geöffnet und im 4.0-Format gespeichert werden.

Dateien aus QuarkXPress 5.x, 6.x und 7.x sind in einem Spezialformat gespeichert, sodass InDesign diese Dateien nicht direkt öffnen kann, um sie dann in InDesign-Dateien umzuwandeln.

Wenn man ein QuarkXPress-Dokument in InDesign öffnet, wird ein neues, nicht benanntes Dokument erstellt. InDesign konvertiert dann die ursprünglichen Dateiinformationen in programmeigene InDesign-Informationen.

Durch die Verwendung von dynamischem HTML kann die Benutzerfreundlichkeit von Webseiten verbessert werden.

Während eine normale HTML-Seite nach dem Abruf statisch und unveränderlich ist (von Hover-Effekten mit CSS einmal abgesehen), können Seiten mit dynamischem HTML weitere Funktionalität bieten, etwa Teile der Seite verändern oder animieren.

Der Begriff kann leicht mit dynamischen Webseiten verwechselt werden; damit werden Webseiten bezeichnet, die vor dem Abruf durch den Webbrowser vom Server generiert werden (etwa durch ein PHP-Script), während Webseiten mit dynamischen HTML durch Scripting dynamisiert werden, welches nach dem Abruf im Browser ausgeführt wird.

Beide Techniken können auch kombiniert werden, viele Anwendungsfälle von dynamischen HTML ergeben ohne dynamisch auf Serverseite generiertem Inhalt sogar kaum Sinn.

Diese Notwendigkeit ergibt sich aus dem Bedürfnis, auf Eingaben des Benutzers dynamisch reagieren zu können.

Als statische HTML-Seiten werden Webseiten bezeichnet, deren Inhalte für die Anzeige nicht aus einer Online-Datenbank gelesen und vom Webserver zur sichtbaren Seite zusammengesetzt werden müssen.

Sie werden – eben weil sie nicht aus einer Datenbank stammen und nicht erst beim Abruf erzeugt werden müssen – besonders schnell angezeigt.

Ein wichtiger Vorteil von statischen HTML-Seiten ergibt sich aus der Art und Weise, wie Suchmaschinen-Robots [24] die Internetseiten in ihren Index aufnehmen.
Robots von Google lesen HTML-Code und folgen den darin enthaltenen Links.

Inhalte aus Datenbanken, die erst beim Aufruf zu Webseiten zusammengesetzt werden, können, je nachdem welche Technik verwendet wird, nicht von den Robots indiziert werden. Ein klarer Nachteil vieler Content Management Systeme.

Die Auszeichnungssprache HTML wurde vom World Wide Web Consortium (W3C) bis Version 4.01 weiterentwickelt und soll durch (X)HTML ersetzt werden.

Da Kosten für die Pflege von umfangreichen Webseiten auf Dauer unrentabel werden, haben sich in den vergangenen Jahren Content Management Systeme für die Verwaltung der Inhalte durchgesetzt.

Häufig werden Content Management Systeme (CMS) als Redaktionssysteme bezeichnet, da sie vor allem von Redakteuren für die regelmäßige Pflege und Aktualisierung der Inhalte genutzt werden.

Neben der Erstellung und Bearbeitung der Inhalte ermöglicht ein CMS auch dessen Organisation. Durch Trennung von Inhalt, Struktur und Design tragen diese Systeme dazu bei, dass eine Ausgabe der Inhalte in verschiedenen Formaten möglich ist und dabei die Einhaltung eines vom Corporate Design vorgegebenen Gestaltungsrasters gewährleistet bleibt. Auch der Import und Export von Daten auf XML-Basis gehört mittlerweile zum Standard.

Das sogenannte Template (Vorlage) ist das Herz einer CMS-Internetpräsenz. Es besteht aus mehreren Dateien (HTML, CSS, Bilder) die das Grundgerüst und Layout der Seite bestimmen. Es werden spezielle Markierungen gesetzt, die später vom CMS automatisch mit den entsprechenden Inhalten gefüllt werden. Die gesamte optische Erscheinung eines Internetauftrittes kann in einem einzigen statischen Template festgelegt werden und garantiert dadurch ein einheitliches Erscheinugsbild. Selbstverständlich können aber bei Bedarf für verschiedene Bereiche (beispielsweise Unterseiten) eines Auftrittes auch verschiedene Templates angelegt werden.

Je nach Komplexität und Leistungsfähigkeit des Systems kommen detaillierte Benutzer- und Rechteverwaltungen sowie Steuerungen ganzer Arbeitsprozesse hinzu. Zugangskontrollen basieren auf einer Benutzerverwaltung, die die Rechte der einzelnen Benutzer kennt. Während der Anmeldung weist sich der Benutzer zunächst aus und basierend auf den Berechtigungen wird entschieden welche Interaktionen das CMS ihm gestattet.

Während einfache Systeme möglicherweise nur globale Lese- und Schreibrechte kennen, erlaubt ein High-end-System die individuelle Kontrolle aller Objekte im CMS, also zum Beispiel des Layouts, der Textblöcke, Bilder und Code-Blöcke.

Damit Webseiten im Hinblick auf Funktionsumfang und Leistungsfähigkeit erweitert werden können, sollten Content Management Systeme eine schnelle und einfache Integration zusätzlicher Bestandteile ermöglichen. Oftmals existieren bereits fertige Module für die gängigsten Erweiterungen. Gerade bei Systemen auf Open Source Basis gibt es eine große Entwicklergemeinde die viele und auch qualitativ hochwertige Erweiterungen produzieren und zur freien Verfügung bereitstellen.

Während einfache Systeme bei der Datensicherung kaum Möglichkeiten bieten, lassen datenbankbasierte CMS wenigstens die Datenbankreplikation auf DBMS-Ebene [25] zu. High-End CMS dagegen bieten sowohl Mechanismen für die explizite Sicherung von Teilbeständen als auch den Rollback basierend auf einer Protokollierungsfunktion.

Protokollfunktionen erfassen Bestandsänderungen der Datenbankinhalte und der Rollback macht Änderungen an Inhaltsbeständen so rückgängig, dass die Bestände auch nach der Wiederherstellung in einem definierten Zustand und in sich konsistent sind.

Content Management Systeme müssen mehrplatzfähig sein, damit mehrere Bearbeiter gleichzeitig an Inhalten arbeiten können, ohne sich gegenseitig zu behindern. Beim Check-Out teilt zum Beispiel ein Benutzer dem CMS mit, dass er die Inhalte x, y und z zur Bearbeitung haben möchte. Das CMS stellt die Inhalte zur Verfügung und markiert sie. Bis der Benutzer die Inhalte wieder per Check-In zurückgegeben hat, kann kein anderer sie verändern.

TYPO3 ist ein kostenloses Content Management Framework auf Open Source Basis (GNU/GPL) [26], welches von Kasper Skårhøj entwickelt wurde. TYPO3 basiert auf der serverseitigen Skriptsprache PHP und verwendet als Datenbank meist MySQL.

Zur Content-Pflege nutzt TYPO3 einen normalen Web-Browser als Editor. Es ist also keine weitere Software notwendig. TYPO3 verfügt auch über einen Rich Text Editor (RTE) [27]. Damit können Texte so eingegeben und formatiert werden, wie man es von einem Textbearbeitungsprogramm gewöhnt ist.

TYPO3 verfügt zur Template-Erstellung über eine eigene Konfigurationssprache namens TypoScript, mit der die Darstellung des Inhalts gesteuert wird. HTML-Dateien, die das Grundgerüst des Webauftritts bilden, können mit TypoScript bequem eingebunden werden. Bei der dynamischen Erzeugung einer Seite werden diese sogenannten Designvorlagen dann über TypoScript mit den eigentlichen Inhalten versehen.

Obwohl der Name TypoScript danach klingt, handelt es sich nicht um eine Skript- oder Programmiersprache im eigentlichen Sinn, sondern vielmehr um

eine Aneinanderreihung von Befehlen, mit denen eine TYPO3-interne Struktur gefüllt wird. TYPO3 wird intern über verschiedene PHP-Arrays gesteuert. Sie enthalten alle Informationen, die notwendig sind, um aus datenbankgespeicherten Inhalten über TypoScript-Befehle HTML-Code zu erzeugen

Durch den Einsatz von TypoScript ist es möglich, die Generierung von Menüs zu automatisieren. Das Aussehen der Elemente und die Funktionsweise werden über TypoScript-Anweisungen definiert. Das dynamische (scriptgesteuerte) Erzeugen von Bildern wird hauptsächlich bei grafischen Menüs und Elementen (Bildern) mit eingebetteten Textinformationen angewendet. Das gewinnt immer dann an Bedeutung, wenn eine spezielle Schriftart verwendet wird, deren Vorhandensein auf den Zielrechnern nicht vorausgesetzt werden kann.

TYPO3 kann auf vielen Ebenen erweitert werden. Die Architektur ermöglicht nicht nur die Datenverarbeitung mit eigenen PHP-Skripten, Klassen und Funktionen, sondern auch das Einfügen von eigenen Backend-Modulen, Webseiten-Plugins und Datenbanktabellen.

TYPO3 Erweiterungen (Extensions) sind vorgefertigte Module, werden einem gewünschten Design angepasst und ersparen sehr viel Entwicklungsarbeit. Beispiele für Extensions sind: News, Newsletter, FAQ, Shop, Suche, Statistik und Bewertung.

TYPO3 basiert auf einer internen MySQL-Datenbank. Innerhalb dieser Datenbank werden Inhalte aus verschiedenen Tabellen verwaltet.

Jede neu angelegte Seite in TYPO3 wird in der MySQL-Datenbank (in der Tabelle pages) gespeichert und jede dieser Seiten hat eine eindeutig zugewiesene Zeilennummer. Diese wird beim Mouseover über dem Seitensysmbol vor einer Seite angezeigt.

Die Arbeitsoberfläche von TYPO3 ist in drei Hauptbereiche unterteilt: Modulleiste, Navigationsansicht und Detailansicht.

Modulleiste: TYPO3 beinhaltet verschiedene Module zur Verwaltung und Bearbeitung der Webseite. Folgende wichtige Modulbereiche stehen dem Bearbeiter für die Pflege der Inhalte des Content Managements Systems zur Verfügung: Web, Datei und Benutzer.

Navigationsansicht: In der Navigationsansicht wird die komplette Seitenstruktur baumartig visualisiert. Es stehen zwei Seitenbäume zur Verfügung. Zum einen die Struktur der gesamten Webseite, bei der sich alle Inhalte anzeigen und kopieren lassen – je nach Berechtigung des Benutzer auch verändern und löschen lassen. Zum anderen die Struktur des eigenen Arbeitsbereiches, auf dessen Inhalte man vollen Zugriff zur Bearbeitung hat.

Detailansicht: Die Detailansicht (auch Datenansicht) stellt die eigentliche zentrale Arbeitsoberfläche für den Nutzer dar. In diesem Bereich werden die Details zu den in der Navigationsansicht ausgewählten Elementen angezeigt. Die Bearbeitungsoptionen (und damit auch die Art der Darstellung in der Detailansicht) sind abhängig von dem jeweiligen Modul, welches gerade benutzt wird. Die Detailansicht bietet dem Benutzer ebenfalls die für die einzelnen Objekte spezifischen Kontextmenüs an.

Modulbereich Web: Der Modulbereich Web wird für den Benutzer der am häufigsten verwendete sein. Hier befinden sich die Module zur Pflege der Inhalte.

Modulbereich Datei: Der Modulbereich Datei liefert eine Übersicht über die verwendeten Ressourcen. An dieser Stelle können Dateien hochgeladen und verwaltet werden.

Modulbereich Benutzer: Im Modulbereich Benutzer kann jeder Benutzer des Systems Einstellungen zu seinem Benutzeraccount und seiner persönlichen Oberfläche machen.

Der PDF-Export aus Layoutapplikationen ist der klassische und vermutlich auch schnellste Weg Daten nicht nur für den Druck, sondern gleichzeitig auch für das Internet zu erzeugen. In diesem Kapitel werden die Export-Wege beider Layoutprogramme QuarkXPress und Adobe InDesign beschrieben und darüberhinaus, wie die Einbindung einer PDF-Datei sowohl in eine einfache HTML-Seite als auch in TYPO3 vorgenommen wird.

Ein direkter PDF-Export ist aus Adobe InDesign möglich – ohne den Umweg über den Acrobat Distiller nehmen zu müssen. Einige PDF-Standards (Druck, Monitor, PDF/X-3 [28] ) sind von Adobe schon vordefiniert. Um eigene Definitionen anzulegen, kann man diese bei den PDF-Exportvorgaben konfigurieren. Verknüpfungen und Hyperlinks für interaktive PDF sind direkt in InDesign erstellbar, der Export ist aber nicht PDF/X-3-konform.

Analog hierzu funktioniert der QuarkXPress PDF-Export. Quark nimmt aber den Umweg über eine für den Anwender nicht sichtbare, temporäre Postscript-Datei. Erst diese wird dann in ein PDF umgewandelt und gespeichert. Das Instrument hierfür ist die von Global Graphics lizensierte Jaws PDF Library [29] , die in XPress 7 integriert ist. Alternativ kann

man auf die Umwandlung in ein PDF durch das Layoutprogramm verzichten, nur die Postscript-Datei exportieren und diese dann anschließend mithilfe des Acrobat Distillers in ein PDF konvertieren.

Oft erfahren PDF-Dateien für das Internet nur eine sehr mangelhafte Aufbereitung: Lediglich die Layoutdaten werden präsentiert, ohne jedoch Navigationshilfen zu bieten oder den Inhalt der PDF-Datei flexibel zu halten. Besonders umfangreiche Dokumente verderben dem Betrachter die Lust, am Bildschirm durch Hunderte von Seiten zu navigieren. Schaltflächen, Hyperlinks, Anker oder Lesezeichen werden erst dann in eine PDF-Datei exportiert, wenn die entsprechenden Optionen aktiviert wurden.

Standardmäßig kann ein Browser nur Texte und Bilder anzeigen. Doch die Browser können mehr: Die Schlagworte sind hier MIME [30] (Multipurpose Internet Mail Extentions), Plugins und Hilfsprogramme. Die sogenannten MIME-Typen legen fest, welche Medien erlaubt sind, in welchem Format sie kodiert und wie sie gekennzeichnet sind. Letzteres erfolgt durch die Dateinamenserweiterung.

Fehlt eine solche Festlegung für einen MIME-Typ, so wird der Browser häufig damit nichts anfangen können. In der Regel wird gefragt, was mit der Datei gemacht werden soll. Diese kann dann höchstens lokal gespeichert werden. Bei neueren Browser-Versionen wird der Benutzer alternativ gefragt, ob ein Zusatzprogramm installiert werden soll.

Bei den Hilfsprogrammen unterscheidet man Plugins und Helper. Bei Aktivierung eines der Multimedia-Formate werden Plugins im Browserfenster gestartet. Helper werden dagegen als getrennte Anwendung in einem gesonderten Fenster gestartet. Die Einbindung eines PDF-Dokumentes in eine HTML-Seite geschieht relativ einfach über folgenden Aufruf:

<a type=“application/pdf“ href=“pfadangabe/beispiel.pdf“>
Zum PDF-Dokument</a>

PDF-Dateien können entweder mit der Helper-Applikation Adobe Reader gelesen werden, oder über das Browser-Plugin geladen werden. Nach einem Klick auf ein PDF-Dokument im Internet startet der Browser das Programm Adobe Reader automatisch im Hintergrund und das PDF steht dann zum Lesen im Browser selbst zur Verfügung.

Die Adress- und Navigationsleisten des Browsers bleiben erhalten – der Adobe Reader ist Teil des Browsers geworden. Eine weitere Navigationsleiste des PDF-Plugins sorgt für eine Blätter-Möglichkeit durch die einzelnen Seiten des PDF-Dokumentes, für die Vergrößerung und die Positionierung der Dokumenteninhalte sowie zum Speichern, Kommentieren und Drucken.

Man kann PDF-Dokumente zum einen nach dem Inhalt durchsuchen lassen; oft sind PDFs aber auch mit einem Inhaltsverzeichnis versehen, das man sich auf der linken Seite des Readerfensters anzeigen lassen kann. In der Seitenleiste hat man dann die Wahl zwischen einer Bookmark und einer Inhaltsverzeichnisansicht (sofern ein solches vom Autor angelegt worden ist), der Ansicht der Seiten in verkleinerter Form als Bild (Thumbnails) sowie der eventuell im Dokument vorhandenen Kommentare und Signaturen.

Alle PDF-Dateien, die in das System eingebunden werden sollten, müssen im Modulbereich Datei in dem Modul Dateiliste des TYPO3 Backends oder per FTP auf den Server hochgeladen werden. Systembedingt besteht die Möglichkeit, Dateien in die einzelnen Inhaltselemente direkt einzubinden, allerdings können hier hochgeladene Dateien global nicht weiterverwendet werden.

Filelink (TypoScript) [31] – Erstellt eine Verlinkung und bietet die Möglichkeit ein Icon für den Dateityp, die Dateigröße oder eine Vorschau anzeigen zu lassen.

# Ein Link auf das PDF-Dokument wird ausgegeben.

10 = TEXT

10.value = beispiel.pdf

10.filelink {

path = pfadangabe/

icon = 1

icon.wrap = |

icon_link = 1

size = 1

size.noTrimWrap = | (| Bytes) |

stdWrap.wrap = <div>|</div>

}

Unter den Stichwort Flash und ePaper findet man bei Google mittlerweile viele Anbieter, die ihre Flash-basierten Konverter oder ihre Dienstleistung in diesem Segment anbeiten. Drei dieser Techniken mit jeweils unterschiedlichen Konzepten werden in diesem Kapitel näher erläutert.

Für die Ausgabe aus Adobe InDesign wurde die Möglichkeit geschaffen, Dateien für elektronische Bücher zu exportieren. Das Konzept nennt sich Adobe Digital Editions und basiert auf einem kodierten (X)HTML-Format, welches über einen Server verschlüsselt und nur mit einem speziellen Reader betrachtet werden kann. Digital Editions unterstützt sowohl das PDF-Format als auch (X)HTML-basierte, flexible Darstellungsformate, sodass Inhalte unabhängig von Displaygrößen und Ausgabegeräten im optimalen Layout angezeigt werden können. Mit der Adobe Rich Internet Applikation (RIA) auf Basis von Adobe Flash lassen sich multimediale, dynamische Elemente nutzen und außerdem viele Einschränkungen des Web umgehen.

Die Technik des „Livepaper“ hat Gruner + Jahr zugekauft, als sie Anfang 2007 den Entertainment Media Verlag übernahmen.Die PDF-Dateien werden direkt in die livepaper-Software geladen und von dieser in eine blätterbare Flash-Ausgabe umgewandelt. Über eine Audio- und Video-Datenbank können Videos, Grafiken, Soundfiles und Animationen verknüpft werden.

Leider wird beim Livepaper das Dokument nur optisch aufgebessert. Die Schriftinformation geht bei der Umwandlung verloren und somit wird die Durchsuchbarkeit des Dokumentes nach Inhalten unmöglich und der Suchmaschinenoptimierungsgrad tendiert gegen Null.

speedPaper ist eine webbasierende Dokumentenmanagement- und ePaper-Lösung, die es ermöglicht Print-Dokumente im Internet zu präsentieren. Der entscheidende Vorteil gegenüber anderen ePaper-Technologien liegt beim speedPaper in der Darstellungsqualität selbst bei kleinsten Datenmengen. Mithilfe einer intelligenten Datenbank bekommt der Benutzer nur relevante Seiten „on demand“ dargestellt, ohne Unmengen an Daten herunterladen zu müssen.

speedPaper lässt sich aus Adobe InDesign oder jedem anderen Programm als PDF publizieren, ist plattformunabhängig und benötigt lediglich einen installierten Adobe Flash-Player. Die Inhalte liegen als Textinformationen vor, damit lassen sich einfach Verlinkungen und Verknüpfungen herstellen und das Dokument bleibt für Suchmaschinen indizierbar.

speedPaper basiert auf Adobe Flash/Flex Technologie [36] und ermöglicht somit sowohl die Anreicherung der Dokumente mit Multimedia-Inhalten als auch den Einsatz auf Mobile Devices. Durch DRM (Digital Rights Management) [37] und dem Adobe-LiveCycle-PolicyServer [38] können die Inhalte geschützt werden und nur für bestimmte Benutzergruppen zugänglich gemacht werden.

Zum Einbinden von Flash-Dateien gibt es verschiedene Ansätze. Die beiden ältesten Verfahren entsprechen den Techniken zur Einbindung von Plugins, die Netscape und Microsoft unabhängig voneinander für ihre Browser entwickelten. Der Netscape Navigator erwartete ursprünglich die Einbindung über das Netscape-eigene embed-Element. Der Microsoft Internet Explorer hingegen erwartete, dass die Flash-Anwendung als ActiveX-Control eingebunden wird.

<object classid=“CLSID:D27CDB6E-AE6D-11cf-96B8-444553540000“ width=“600“ height=“400“ codebase=“http://active.macromedia.com/flash2/cabs/swflash.cab#version=4,0,0,0“>

<param name=“movie“ value=“beispiel.swf“/>

<param name=“quality“ value=“high“/>

<param name=“scale“ value=“exactfit“/>

<param name=“menu“ value=“true“/>

<param name=“bgcolor“
value=“#000000“/>

<embed src=“beispiel.swf“ quality=“high“ scale=“exactfit“ menu=“false“

bgcolor=“#000000“ width=“600“ height=“400“ swLiveConnect=“false“

type=“application/x-shockwave-flash“

pluginspage=“http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash“>

Diese umständliche doppelte Einbindung mit <object> und einem darin verschachtelten <embed> hat sich als robust erwiesen, der Nachteil dabei ist jedoch, dass ein HTML-Element verwendt wird, welches nicht zum HTML-Standard gehört. Die im HTML-4-Standard [39] geschaffene allgemeine Möglichkeit des Einbindens von Datendateien als Objekt ist auch zum Einbinden von Flash-Dateien zu gebrauchen. Damit existiert eine einheitliche, browserübergreifende Schreibweise.

<object data=“beispiel.swf“ type=“application/x-shockwave-flash“ width=“600“ height=“400“>

<param name=“movie“ value=“beispiel.swf“/>

<param name=“quality“ value=“high“/>

<param name=“scale“ value=“exactfit“/>

<param name=“menu“ value=“true“/>

<param name=“bgcolor“
value=“#000000“/>

</object>

Alle Flash-Dateien, die in das System eingebunden werden sollen, müssen im Modulbereich Datei in dem Modul Dateiliste des TYPO3 Backends oder per FTP auf den Server hochgeladen werden.
Systembedingt besteht die Möglichkeit, Dateien in die einzelnen Inhaltselemente direkt einzubinden, allerdings können hier hochgeladene Dateien global nicht weiterverwendet werden.

Multimedia-Objekt (TypoScript) [40] – für die Einbettung von Multimedia-Objekten setzt TYPO3 standardmäßig das Element <embed> ein. Aus diesem Grund müssen alle Objekte über das Inhaltselement HTML eingebunden werden, damit die Einbettung des Flash-Elementes standardkonform und barrierefrei erfolgen kann.

Generell wird auch die Verwendung eines Javascriptes zur Abfrage der Flash-Funktionalität des Browsers empfohlen.

# Erzeugt ein Flash-HTML-Objekt in einem div-Container.

10 = HTML

10.value=<div>

20 = TEXT

20.value=

<object data=“fileadmin/beispiel.swf“ type=“application/x-shockwave-flash“ width=“600“ height=“400“>

<param name=“movie“ value=“fileadmin/beispiel.swf“/>

<param name=“quality“ value=“high“/>

<param name=“scale“ value=“exactfit“/>

<param name=“menu“ value=“true“/>

<param name=“bgcolor“
value=“#000000“/>

</object>

30 = HTML

30.value=</div>

Ein interessanter und besonders vielversprechender Ansatz ist die Aufbereitung von Layoutdokumenten auf XML-Basis. Im Gegensatz zu dem programmeigenen XML-Export bei dem ausschließlich vorher mit diversen Tags versehene Inhalte exportiert werden, sind mit „BatchXSLT [41] “ auch unbehandelte InDesign-Dokumente exportierfähig. Da die Layoutapplikation Adobe InDesign ein Schwerpunkt dieser Ausarbeitung ist, wird in diesem Kapitel nur diese Möglichkeit beschrieben.

QuarkXPress-Dokumente können auch – nachdem diese in das InDesign-Format konvertiert wurden – entsprechend aufbereitet werden. Für eine native Dokumentverarbeitung gibt es die Software „BatchXPort Pro [42] “, die aber hier nicht weiter besprochen wird.

Aus dem InDesign-Dokument werden per Javascript automatisch alle zur Konvertierung benötigen Komponenten exportiert.

Notwendige Bestandteile sind zum einen das im Austausch-Format (INX) abgebildete InDesign-Dokument und zum anderen der Export jeder einzelnen Seite als JPG- und PDF-Datei. Das Javascript im Detail:

//BXSLTExport.jsx

function doDocumentExport(theExportFolder) {

var pageName, theFilePath, aFile;

var theDocument = app.documents.firstItem();

var theDocumentName = theDocument.name;

var theBaseDocumentName = theDocumentName;

// get the document name without file extension

if (theBaseDocumentName.indexOf(„.indd“) > 0) {

theBaseDocumentName = theBaseDocumentName.substr(0,theDocumentName.lastIndexOf(„.indd“));

}

// replace unwanted chars in filename: / - Ñ . ! ~ * Ô ( )

theBaseDocumentName = theBaseDocumentName.replace(/\//,“s“);

while (theBaseDocumentName.charAt(theBaseDocumentName.length - 1) == „.“) {

theBaseDocumentName = theBaseDocumentName.substr(0,theBaseDocumentName.length - 1);

}

// export the whole document to a single INX file

if (inxExists == false) {

//$.writeln(„*** BXSLTExport: Exporting Document to INX“);

theFilePath = theExportFolder + „/“ + theBaseDocumentName + „.inx“;

aFile = new File(theFilePath);

theDocument.exportFile(inxExportFormatString, aFile, false); // for CS2

}

// Export PDF and JPEG page per page

for (var ctr = 0; ctr < theDocument.pages.length; ctr++) {

sectionName = theDocument.pages.item(ctr).appliedSection.name;

pageName = sectionName + theDocument.pages.item(ctr).name;

// The name of the exported files will be: documentName + pageStr + „.pdf“

var pageStr = „“ + (ctr + 1); // the page number string

if (ctr == 0) pageStr = „“; // none for page #1

var theFilePathBase = theExportFolder + „/“ + theBaseDocumentName + pageStr;

// export to PDF

if (pdfExists == false) {

//$.writeln(„*** BXSLTExport: Exporting Page #“ + (ctr + 1) + „ to PDF“);

$.sleep(500);

app.pdfExportPreferences.pageRange = pageName;

// set here your PDF preferences if you want others than the current defaults

theFilePath = theFilePathBase + „.pdf“;

aFile = new File(theFilePath);

theDocument.exportFile(ExportFormat.pdfType, aFile, false);

}

// export page to JPG

if (jpgExists == false) {

//$.writeln(„*** BXSLTExport: Exporting Page #“ + (ctr + 1) + „ to JPEG“);

$.sleep(500);

app.jpegExportPreferences.jpegExportRange = ExportRangeOrAllPages.exportRange;

app.jpegExportPreferences.pageString = pageName;

app.jpegExportPreferences.jpegQuality = JPEGOptionsQuality.maximum;

app.jpegExportPreferences.jpegRenderingStyle = JPEGOptionsFormat.baselineEncoding; // or progressiveEncoding

theFilePath = theFilePathBase + „.jpg“;

aFile = new File(theFilePath);

theDocument.exportFile(ExportFormat.jpg, aFile, false);

}

}

}

Das InDesign-Interchange-Format ist XML-basiert und ein mehr als komplexes kaum interpretierbares Austauschformat. Jede INX-Datei beginnt mit einer XML-Deklaration, gefolgt von INX-spezifischen Verarbeitungsanweisungen und dem eigentlichen Wurzelelement, welches das Dokument-Objekt aus dem InDesign-DOM repräsentiert.

<?xml version=“1.0“ encoding=“UTF-8“ standalone=“yes“?>

<?aid style=“33“ type=“document“ DOMVersion=“4.0“ readerVersion=“3.0“ featureSet=“257“ product=“4.0(688)“ ?>

<docu [...] > [...]

</docu>

Jedes weitere Objekt aus dem InDesign-DOM wird als XML-Element beschrieben, alle Objekteigenschaften werden in XML-Attributen festgelegt und im InDesign-Interchange-Format über die sogenannten Script ID‘s [43] identifiziert.

InDesign benutzt ID‘s die immer aus vier Zeichen bestehen, beispielsweise:

<docu> – Dokument

<colr> – Farbe

<sprd> – Druckbogen

<cflo> – Textbereiche

<txsr> – Textformatbereiche

<IGeo> – Objektdimensionen und
Seitenposition

Die Art des Attributs wird im INX-Format über das Präfix definiert, der Inhalt oder Wert folgt nach dem ( _ )-Zeichen.

o_ object reference – Referenz

u_ unit – Einheit

s_ short integer – Ganzzahl(16bit)

l_ long integer – Ganzzahl(64bit)

c_ plain text – Inhalt/Text

b_ boolean – logischer Term

t_ datetime – Datum und Zeit

e_ enum – Aufzählung

f_ file – Datei

0_ void – Leerraum

x_ list – Anordnung

r_ read_only – Lesezugriff

In der Dateistruktur werden die InDesign-Voreinstellungen immer zuerst aufgeführt, gefolgt von dokumentspezifischen Eigenschaften und schließlich den individuellen Dokument-Objekten aus dem jeweiligen InDesign-DOM. Die Reihenfolge der Objekte entspricht immer dem Abbild des jeweiligen InDesign-Dokumentes und folglich kann es keine feste Struktur einer INX-Datei geben. Es gibt somit kein XML-Schema [44], welches diese Struktur beschreibt. In der „debug-version“ von InDesign kann man zwar eine DTD [45] der DOM-Struktur des aktuellen InDesign-Dokumentes erzeugen, nicht jedoch andere INX-Daten gegen diese Momentaufnahme eines einzelnen Dokumentes validieren. Trotzdem sind aber einige INX-Objekte immer nach einem festen Schema aufgebaut.

Die Dokument-Objekte erscheinen in folgender Reihenfolge:

XML items (c_XMLItem, ‚cxit‘);

XML export maps (c_XMLStyleToTagMap, ‚stmX‘);

XML import maps (c_XMLTagToStyleMap, ‚tsmX‘);

Colors (c_Color, ‚colr‘);

Mixed ink groups (c_MixedInkGroup, ‘MxSg‘);

Mixed inks (c_MixedInk, ‚MxSw‘);

Pasted smooth shades (c_AGMBlackBox, ‚ctbb‘);

Tints (c_Tint, ‚tint‘);

Swatchs (c_Swatch, ‚swch‘);

Gradients (c_Gradient, ‚grad‘);

Fonts (c_Font, ‚FonT‘);

Character styles (c_CharStyle,‘csty‘);

Paragraph styles (c_ParaStyle,‘psty‘);

Named grids (c_NamedGrid, ‚Jngd‘);

Kinsoku tables (c_KinsokuTable, ‚Jkst‘);

Mojikumi tables (c_MojikumiTable, Jmjt‘);

Languages (c_Language, ‚lang‘);

Preferences (all kind of preference objects);

Stroke styles (c_StrokeStyle, ‚StSt‘);

XML tags (c_XMLTag, ‚tagX‘);

Layers (c_Layer, ‚layr‘);

Master spreads (c_MasterSpread, ‚mspr‘);

Spreads (c_Spread, ‚sprd‘);

Sections (c_Section, ‚sctn‘);

PageItems (c_PageItem, ‚pitm‘);

(all types of page items document directly own);

Stories (all stories);

Hyperlink text destinations (c_HyperlinkTextDestination, ‚HLTd‘);

Hyperlink page destinations (c_HyperlinkPageDestination, ‚HLPD‘);

Hyperlink URL destinations (c_HyperlinkURLDestination, ‚HLUD‘);

Hyperlink ext. destinations (c_HyperlinkExternalPageDestination, ‚HLEP‘);

Hyperlink text sources (c_HyperlinkTextSource, ‚HLTS‘);

Hyperlink page item sources (c_HyperlinkPageItemSource, ‚HLPs‘);

Hyperlinks (c_Hyperlink, ‚HLOB‘);

Bookmarks (c_Bookmark, ‚Bkmk‘);

All other remaining children of document;

Druckbogen-Elemente werden folgendermaßen behandelt:

First write non-page items;

Then write page items in reverse z-order (to make importing more efficient)

Die Unterelemente einer Tabelle erscheinen in dieser Reihenfolge:

Table rows (c_TableRow, ‚crow‘);

Table columns (c_TableColumn, ‚ccol‘);

All other remaining children;

Textbereiche erscheinen in folgender
Abfolge:

Put all story preferences first.

Text style ranges (c_TextStyleRange, ‚txsr‘);

Tables (c_Table, ‘ctbl‘);

Page items (c_PageItem, ‚pitm‘,

all types of page items story own);

Notes (c_Note, ‚Note‘);

Changes (c_Change, ‚Chng‘);

All other remaining children;

Um die komplexe Datenstruktur der INX-Formates darzustellen und besser verständlich zu machen, wird zunächst einmal nur ein leeres Dokument, welches nach den Standardeinstellungen von InDesign angelegt und ohne weitere Bearbeitung anschließend in das Adobe InDesign-Interchange-Format (INX) exportiert wurde, betrachtet.