Zunächst ist es hilfreich, um in der Vielzahl von Dateiformaten und Suffixen (Dateiendungen) durchzublicken, übergeordnete Kategorien zu verwenden und zwar zunächst in programmunabhängige und in programmabhängige Formate.
Der Name sagt hier schon einiges über die Problematik in der Verwendung der Dateiformate. Bei den programmabhängigen Dateiformaten benötigt man auch immer die kompatible Softwareapplikation oder Zusatzmodule um das jeweilige Dateiformat auszulesen oder gar weiterzubearbeiten. Meist handelt es sich dabei um die originären Formate der Layoutprogrammen (InDesign/.indd und QuarkXpress/.qxp) oder Grafik- bzw. Bildbearbeitungsprogrammen.
Programmunabhängige Dateiformate haben diese Einschränkungen nicht..
Unterscheidung von Pixel- und Vektordateiformat
Eine weitere Grobunterscheidung bietet sich an Hand dem Aufbau der Daten, also ob es sich um Pixel- oder Vektordaten handelt.
Bei vektorbasierte Dateien werden Grafiken über Punkte und Bezierkurven beschrieben. Solche Daten bieten den Vorteil, dass sie beliebig skaliert werden können ohne dass es zu einem Qualitätsverlust kommt. Das Standard-Austauschformat für Vektor-Grafiken ist EPS.
Pixelgrafiken sind hingegen auflösungsabhängig und mit einer Skalierung ist immer auch ein Qualitätsverlust verbunden. Gängige Pixelformate sind TIFF, JPEG und GIF.
Meta-Dateiformate
Metaformate können Pixel und Vektoren in einer Datei enthalten, wie das WMF (Windows Metafile Format) oder PDF.
Die Begriffe Datenformat und Dateiformat gebraucht man oft gleichbedeutend, sie sind aber nicht gleich. Wie unterscheiden sich die Begriffe?
Das Datenformat bestimmt, wie Daten geladen, gespeichert oder verarbeitet werden. Die Daten müssen logisch strukturiert sein, damit das Programm die Daten speichern und verarbeiten kann.
Textformate, Bildformate, Videoformate, Audioformate.
Das Dateiformat beschreibt, wie unterschiedliche Daten in einer Datei gespeichert werden. In einer Datei können z.B. Texte, Tabellen, Grafiken, Audio-Inhalte, Animationen oder Videos gespeichert sein. Damit man diese Inhalte nutzen kann, muss das Programm die Daten auswerten. Dafür braucht das Programm Informationen. Diese Informationen sind an den Dateinamen angehängt durch eine Endung, die aus 2, 3 oder 4 Buchstaben besteht und durch einen Punkt getrennt ist.
Es gibt viele Datei-Endungen und Dateiformate. Man unterscheidet:
Für programm-abhängige Dateiformate braucht man immer die richtige Software des Herstellers oder Zusatzmodule, damit man das jeweilige Dateiformat auslesen und bearbeiten kann.
Programm-abhängige Dateiformate gibt es meistens bei Layout-Programmen (z.B. InDesign/.indd), Grafik-Programmen oder Bildbearbeitungs-Programmen.
Für programm-unabhängige Dateiformate braucht man keine Software eines bestimmten Herstellers. Man kann diese Dateien mit der Software von verschiedenen Herstellern auslesen und bearbeiten (z.B. PNG-Datei oder JPEG-Datei).
Man unterscheidet Dateiformate nach dem Aufbau der Daten.
Bei Vektor-Dateiformaten werden Grafiken über Punkte und Bezierkurven dargestellt.
Das Standard-Format für Vektor-Grafiken ist EPS.
Man kann die Grafiken beliebig skalieren, die Qualität bleibt gleich gut.
Bei Pixel-Dateiformaten setzen sich die Grafiken aus einzelnen Punkten zusammen. Diese Punkte heißen Pixel. Viele Pixel zusammen ergeben die Pixel-Grafik. Wenn man die Grafiken skaliert, wird die Qualität der Grafik schlechter.
Häufige Pixel-Formate: TIFF, JPEG und GIF.
Damit die Druckerei Druckaufträge pünktlich und gut bearbeiten kann, müssen die Druckdaten vollständig sein. Die Druckdaten müssen den Empfehlungen des aktuellen Medienstandards Druck entsprechen.
Kunden sollen die Druckdaten im PDF-Format an die Druckerei schicken. Empfohlen werden die Formate
Vor dem Drucken kann man die druckfertige PDF-Datei mit einem Preflight-Check (= Programmfunktion) auf Fehler und Probleme prüfen. Wenn im Prüfbericht keine Fehler und Probleme gemeldet werden, kann man die PDF-Datei drucken.
Es gibt verschiedene Möglichkeiten Dateiformate in Gruppen zu klassifizieren. Entweder ob es sich um programmeigene oder programmübergreifende dateiformate handelt, oder nach ihrer »Datenstruktur«
Programmeigene Dateiformate
Diese originäre Dateiformate von programmen können in der Regel nur von den jeweiligen Programmen gelesen und erstellt werden. Andere Programme benötigen dazu Plugins oder es kommt zu darstellungsabweichungen.
Sie stammen z.B. von Layoutprogramme (.indd, .qxp, .pm, ...), von Grafikprogrammen(.ai, .cdr, ...) oder Bildbearbeitungsprogrammen (.psd)
Programmübergreifende Dateiformate
Solche Dateiformate können unabhängig vom Erstellungsprogramm in anderen Applikationen platziert und/oder verarbeitet werden. Beispiele sind hierfür .tiff, .eps, .jpg)
Unterscheidung nach Datenstruktur
1. Pixelbasierte Dateiformate
2. Vektorbasierte Dateiformate
3. Metafiles (Dateiformate, die Pixel- und Vektorformate speichern können)
PDF ist aus der Druck- und Medienbranche nicht mehr wegzudenken. Das Portable Document Format, kurz PDF, basiert auf PostScript und ist als plattformunabhängiges Austauschformat konzeptioniert worden. Es hat die Druckbranche damit revolutioniert, da endlich keine offenen Daten mit all dem Rattenschwanz von Problemem, die sich für die Druckereien damit ergaben, ersetzte.
Neben dem Einsatz in der Druckvorstufe verfügt das PDF über weitere Vorteile und zwar als Verwendung für elektronische Dokumente und die Verwendung in Online und Offline-Medien.
Die Dateigröße ist relativ klein und kann vom Ersteller bei der Generierung eines PDF angepasst werden.
Ein weiterer Vorteil ist, dass das Layout eines PDF-Dokuments unabhängig vom Ausgabemedium ist und somit immer gleich dargestellt wird.
PDF/X
Definition Workflow
PDF-Workflow
Eine der größten Herausforderungen für einen modernen Dienstleistungsbetrieb ist der Aufbau eines Daten-Workflows, der eine schnelle und fehlerfreie Produktion gewährleistet. Vor allem PDF/X ermöglicht hierbei einen vorlagentreuen Datenaustausch für unterschiedliche Medien inklusive Prüfung (Preflight).
PDF/X-Workflow
https://docplayer.org/1538669-Digitale-drucktechnologie-4-workflow.html
Mit dem PDF/X-Standard wird das Ziel verfolgt einen zuverlässigen Austausch von PDF-Dokumenten zwischen den, an der Produktion von Drucksachen Beteiligten, zu gewährleisten.
Mit dem "X" in PDF/S soll deutlich gemacht werden, dass ein solches PDF Dokument "blind" (blind eXchange) ausgetauscht und verarbeitet werden kann.
Die PDF/X Standards definieren druckvorstufen-spezifische Eigenschaften. Es handelt sich bei PDF/X-Datein nicht um eine Untermenge von PDF, sondern um Beschränkungen innerhalb des PDF-Formats, auf die in der Druckvorstufe relevanten Aspekte.
Alles, was nicht für die Druckausgabe notwendig ist, darf in einer PDF/X-kompatiblen Datei nicht enthalten sein.
Der kleinste gemeinsame Nenner einer solchen Anforderung ist die PDF-Spezifikation 1.3.
Die PDF/X-Anforderungen:
PDF/X-3 erlaubt die Verwendung von medienneutralen Farbräumen wie Lab der RGB (im Gegensatzu zu PDF/X1a, nur CMYK).
Vorraussetzung ist, dass RGB Daten mit ICC-Profilen versehen sind.
Nicht erlaubt sind:
Trim Box:
beschreibt das eigentliche, beschnittene Endformat. Funktioniert wie eine Maske, alles ausserhalb wird abgeschnitten.
Bleed Box:
erlaubt die Aufnahme von Anschnitt und Infobereich im PDF. Vergrößert die Maskierung der Trim Box.
XML dient zum Transport und zur Ablage/Sicherung von Daten, wohingegen HTML zur Darstellung von Daten gedacht ist.
XML strukturiert, speichert und transportiert Informationen.
Man kann mit dieser Sprache nichts senden, empfangen oder darstellen. Man kann lediglich Informationen zwischen Tags schreiben, welche die Information näher beschreiben.
Es ist wichtig zu verstehen, dass XML nicht HTML ersetzen kann oder soll. XML ist ein Zusatz zu HTML mit dem man Daten an das HTML Dokument sendet, welches dann die Daten darstellen kann.
Man kann XML, genau wie HTML, in jedem beliebigen Texteditor schreiben, der reinen Text darstellen kann.
XML Dokumente haben eine Baumstruktur. Sie starten mit dem Wurzelelement und diversifizieren sich dann bis zu "Zweigen" und "Blättern.
Beispiel:
1.: <?xml version="1.0" encoding="ISO-8859-1"?> 2.: <notiz> 3.: <an>Blubb</an> 4.: <von>Bla</von> 5.: <ueberschrift>Dings</ueberschrift> 6.: <inhalt>Palaver Palaver Rhabarber.</inhalt> 7.: </notiz>
Die erste Reihe ist die XML-Deklaration. Sie definiert die XML Version (1.0) und die Encodierung, welche benutzt wurde (ISO-usw, kann auch UTF-8 oder sonstwas sein). Die zweite Reihe is das Wurzelelement, welches alle anderen Tags umschließt. Es sagt in diesem Fall aus, dass es sich um eine Notiz handelt. Die nächsten 4 Elemente sind Kindelemente der Wurzel (Zweige). Die letzte Zeile schließt das Wurzelelement. Man erkennt also, dass es sich um eine Notiz von Bla an Blubb handeln muss.
XML Dokumente müssen ein Wurzelelement enthalten, welches das Elternelement aller anderen Elemente ist.
Da alle Elemente wiederum Kindelemente enthalten können, ergibt sich so eine Baumstruktur von der Wurzel, über die Zweige und deren Äste zu den Blättern (bildlich gesprochen).
Beispiel:
1.: <?xml version="1.0" encoding="ISO-8859-1"?> 2.: <wurzel> 3.: <kind> 4.: <kindvomkind> 5.: <kindeskind>Blubb</kindeskind> 6.: </kindvomkind> 7.: </kind> 8.: </wurzel>
Wie man sieht, könnte man das Ganze ad absurdum weiterführen. Zu beachten ist, dass jedes Element Inhalte und Attribute haben kann.
Ein erweitertes Beispiel für einen Buchladen, welcher seine Bücher in Kategorien einteilt und die einzelnen Bücher nach Titel, Autor, Jahr und Preis katalogisiert.
<?xml version="1.0" encoding="ISO-8859-1"?> <bookstore> <book category="cooking"> <title lang="en">Everyday Italian</title> <author>Giada De Laurentiis</author> <year>2005</year> <price>30.00</price> </book> <book category="children"> <title lang="en">Harry Potter</title> <author>J K. Rowling</author> <year>2005</year> <price>29.99</price> </book> <book category="web"> <title lang="en">Learning XML</title> <author>Erik T. Ray</author> <year>2003</year> <price>39.95</price> </book> </bookstore>
Die Syntaxregeln sind sehr einfach und logisch, deswegen kann man sie auch schnell und einfach erlernen.
Bei XML ist es illegal ein schließendes Tag wegzulassen!
Man geht dafür zwar nicht in den Knast, wenn man dies trotzdem tut, aber die Datei wird nie nicht funktionieren.
In HTML 4.01 und auch in HTML5 ist es erlaubt schließende Tags wegzulassen:
<p>Ein Paragraph
<p>Noch ein Paragraph
Der Browser wird die Paragraphen trotzdem darstellen.
Das einzige "Tag" bzw. Element, welches kein schließendes Tag hat, ist die XML Deklaration. Sie ist nicht Teil des XML Dokumentes sondern teilt nur dem darstellenden Medium mit, um welche Art von Dokument es sich handelt (wie bei HTML Doctype Deklarationen auch).
Es ist ein Unterschied ob man <Tag> oder <tag> notiert, deswegen ist es wichtig das öffnende und das schließende Tag in der selben Schreibweise zu notieren.
<tag>Bla</Tag> wird nicht funktionieren!
Es ist nicht erlaubt die Tags durcheinander zu wirbeln. Ein geöffnetes Tag muss auch nach seinem Inhalt wieder geschlossen werden.
Folgendes Beispiel wird nicht funktionieren:
<bla><blubb>text</bla></blubb>
Es darf nur "richtig verschachtelt" werden:
<bla><blubb>Text</blubb></bla>
Wie in HTML kann man auch XML-Tags Attributwerte zuweisen, indem man sie im Tag selbst notiert. Sie müssen immer folgender Notierung folgen:
<tag attribut="wert">
Das bedeutet, dass erst der Tag-Name kommt, dann der Name des Attributs, dann ein =-Zeichen und dann der Attributwert in doppelte Anführungszeichen gesetzt.
Sonderzeichen wie &, ', ", < und > dürfen nicht ausgeschrieben werden in einem XML-Dokument.
Dies wird einen Fehler generieren:
<tag>bla & blubb > blubb & bla</tag
Um den Fehler zu vermeiden müssen die Sonderzeichen als Entitätsreferenz geschrieben werden:
<tag>bla & blubb > blubb & bla</tag>
Es gibt (zum Glück) nur 5 vordefinierte Entitäten in XML:
< ergibt < (kleiner als)
> ergibt > (größer als)
& ergibt & (das "und-Zeichen oder ampersand)
' ergibt ' (ein Apostroph)
" ergibt " (Anführungszeichen)
Kommentare werden wie in HTML notiert:
<!-- Das ist ein Kommentar -->
Im Westen nichts Neues also.
Wenn man in HTML mehr als ein Leerzeichen setzt, so werden diese zu einem einzigen zusammengefasst.
In XML ist dies nicht der Fall und je mehr Leerzeichen man notiert, desto mehr werden auch ausgegeben.
HTML:
<tag>bla blubb</tag>
Ergibt:
bla blubb
XML:
<tag>bla blubb</tag>
Ergibt:
bla blubb
So, das wäre dann eigentlich alles zum Grundaufbau von XML. Ich werde weitergehend noch auf XML Elemente und Attribute detailiert eingehen, alles weitere führt definitiv zu weit, wenn man vom Grundaufbau spricht.
Ein XML Element ist alles vom öffnenden Tag bis zum schließenden Tag (diese mit eingeschlossen).
Ein Element kann folgendes beinhalten:
<bookstore> <book category="children"> <title>Harry Potter</title> <author>J K. Rowling</author> <year>2005</year> <price>29.99</price> </book> <book category="web"> <title>Learning XML</title> <author>Erik T. Ray</author> <year>2003</year> <price>39.95</price> </book> </bookstore>
Das Beispiel vom Buchladen zeigt sehr gut was das bedeutet.
<bookstore> und <book> haben Kindelemente als Inhalt.
<book> hat außerdem das Attribut "children".
<title>, <author>, <year> und <price> haben außerdem Textinhalte.
Wobei jedes Element alles von dem vorher genannten auch beinhalten kann:
<tag attribut="attributwert">Text
<kind>text</kind>
</tag>
Folgende Regeln sind zu beachten, wenn man XML-Elemente notiert:
Ansonsten kann man sich total austoben, was die Inhalte eines Elements angeht, da man ja die Tagnamen und Attributnamen selbst definieren kann, wie sie einem gefallen.
Ja, wie soeben erwähnt, kann man wild Tagnamen und Attributsnamen verteilen, wie man lustig ist. Aber natürlich macht es mehr Sinn die Namen passend zu den Inhalten der Elemente zu vergeben.
Man sollte Namen beschreibend wählen! Sie sollten kurz und einfach sein.
To do:
<buch_titel>
Not to do:
<der_titel_des_buchs>
Unterstriche sind gut geeignet um Namen zu strukturieren:
<buch_titel>, <buch_autor>, <buch_jahr>, <buch_preis> zum Beispiel
Man sollte keine Bindestriche, Punkte oder Doppelpunkte verwenden um Namen zu strukturieren, da es Programme gibt, die diese anders interpretieren könnten.
XML Elemente können erweitert werden um mehr Information zu transportieren.
Beispiel:
1.: <?xml version="1.0" encoding="ISO-8859-1"?> 2.: <notiz> 3.: <an>Blubb</an> 4.: <von>Bla</von> 5.: <inhalt>Palaver Palaver Rhabarber.</inhalt> 6.: </notiz>
Erweitern wir nun diese Notiz um einige Elemente um zu präzisieren, was für eine Notiz es ist und wann sie verfasst wurde.
Beispiel:
1.: <?xml version="1.0" encoding="ISO-8859-1"?> 2.: <notiz> 3.: <datum>tt.mm.yyyy</date> 4.: <an>Blubb</an> 5.: <von>Bla</von> 6.: <ueberschrift>Erinnerung</ueberschrift> 6.: <inhalt>Laber Palaver Rhabarber.</inhalt> 7.: </notiz>
Ein weiteres Beispiel, welches dies noch eindeutiger macht:
1.: <?xml version="1.0" encoding="ISO-8859-1"?> 2.: <notiz> 3.: <erinnerung> 4.: <an> 5.: <vorname>Bla</vorname> 6.: <nachname>Blabla</nachname> 7.: <strasse>Dingsweg</strasse> 8.: <hausnummer>123</hausnummer> 9.: <plz>12345</plz> 10.: <ort>Dingshausen</ort> 11.: </an> 12.: <von> 13.: <vorname>Blubb</vorname> 14.: <nachname>Blubbblubb</nachname> 15.: <strasse>Bumsweg</strasse> 16.: <hausnummer>321</hausnummer> 17.: <plz>54321</plz</plz> 18.: <ort>Bumshausen</ort> 19.: </von> 20.: <ueberschrift>Hömma</ueberschrift> 21.: <inhalt> 22.: <erstens>Laber</erstens> 23.: <zweitens>Palaver</zweitens> 24.: <ausserdem>Rhabarber</ausserdem> 25.: </inhalt> 26.: </erinnerung> 27.: </notiz>
Die Datei wird immernoch funktionieren, sie ist lediglich viel präziser angelegt, als die vorhergehende Notiz.
XML-Elemente können wie HTML-Elemente Attribute enthalten.
Attribute beschreiben zusätzliche Informationen über ein Element.
Beispiel: <person geschlecht="weiblich">
Hier sind mal zwei Beispiele wie mans machen kann:
<person geschlecht="weiblich"> <vorname>Anna</vorname> <nachname>Smith</nachname> </person> <person> <geschlecht>weiblich</geschlecht> <vorname>Anna</vorname> <nachname>Smith</nachname> </person>
Im ersten Beispiel ist das Geschlecht ein Attribut, im zweiten Beispiel ein Kindelement von Person. Beide Beispiele transportieren die selbe Information.
Es gibt in diesem Fall keine eindeutige Regel, wie man es besser macht. Attribute sind sehr nützlich in HTML, bei XML würde ich darauf eher verzichten und stattdessen Kindelemente notieren (ist aber eine persönliche Sache und somit nur eine Empfehlung).
Man sollte Attribute am besten dazu nutzen Informationen zu transportieren, die nicht relevant sind für die Daten.
Absolutes NO GO:
<note day="10" month="01" year="2008" to="Tove" from="Jani" heading="Reminder" body="Don't forget me this weekend!"></note>
Das ist XML Horror.
Ein sinnvoller Nutzen von Attributen und Attributwerten sind zum Beispiel ID-Vergaben an Elemente.
Das ist insofern nützlich, dass man eine laufende Nummer zu Einträgen hinzufügen kann, wenn es zum Beispiel um eine Personenliste geht und man einen Wert brauch, der auf jeden Fall frei von Redundanzen (Wiederholungen) bleiben muss.
Beispiel:
<namensliste> <person id="0001"> <vorname>Karli</vorname> <nachname>Knusper</nachname> </person> <person id="0002"> <vorname>Klausi</vorname> <nachname>Knusper</nachname> </namensliste>
Was das Beispiel deutlich macht ist, dass man nun eindeutiger zuweisen kann welches Element gemeint ist. Hat man eine endlose Datenbank mit endlos vielen Personen der Familie Knuspre, dann wird man sich darin totsuchen, bis man zu der Person gelangt, welche man nun sucht.
Da ist es doch viel einfacher die entsprechende ID zu suchen und somit direkt zu Person X zu gelangen.
Merke: Metadaten in das Element als Attribut notieren! Daten als neues Element notieren!
Jedes XML-Dokument sollte wohlgeformt (richtige Tag-Benennung, Verschachtelung… s. o.) und valide sein. Valide wird es erst durch die Referenzierung auf eine DTD (Doctyp definition). Dies ist eine Auflistung der möglichen Inhalte der XML-Datei und ihrer erlaubten Reihenfolge. Die DTD wird vom Erstersteller der XML-Datei miterstellt. Sie kann ebenfalls mit einem Texteditor geschrieben werden, muss aber die Endung .dtd beinhalten.
Als Beispiel nehme ich das folgendes XML-Dokument:
<?xml version="1.0" encoding="utf-8" ?> <root_element> <child1>Inhalt1</child1> <child1>Inhalt2</child1> <child2> <subchild1>SubInhalt1</subchild1> <subchild2>SubInhalt2</subchild2> <child2> </root_element>
Die dazugehörgie DTD wäre:
<!ELEMENT root_element (child1+, child2)> <!ELEMENT child1 (#PCDATA)> <!ELEMENT child2 (subchild1, subchild2)> <!ELEMENT subchild1 (#PCDATA)> <!ELEMENT subchild2 (#PCDATA)>
Bedeutung: ist gibt ein Element mit dem Namen root_element, das ein oder mehr (+) Elemente child1 und ein Element child2 enthalten darf. child1 darf wiederum PCDATA (Parced character data = Buchstaben, Ziffern…) enthalten. child2 enthält zwei weitere Elemente jeweils ein mal. Gleiches PCDADA dann für die subchilds.
Folgende Befehle stehen noch zur Verfügung:
Stimmt die XML-Datei nicht mit der zugehörigen DTD überein (z. B. 2 x child2 in diesem Fall), dann ist sie nicht valide und je nach Browser wird ein Fehler geworfen.
Eine DTD kann entweder direkt in die XML-Datei eingebunden werden (hier der DTD mit dem Namen testdatei):
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE testdatei [ <!ELEMENT root_element (child1+, child2)>… usw. ]> <root_element>… usw.
Oder ausgelagert in eine extra Datei mit der Endung .dtd eingebunden werden:
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE testdatei SYSTEM="testdoctype.dtd"> <root_element>… usw.