Dann sind Sie genau richtig, um Ihre Urlaubsbriefe über das Briefdruckzentrum.de zu versenden. Sie erstellen einfach eine PDF-Datei — und gedruckt und versendet wird von Deutschland aus — nach Deutschland. Schnell und einfach. Ich wette: so schnell haben Sie (Schnecken-)Post vom Ausland noch nie nach Hause geschickt!

Aber eigentlich handelt es sich hier um eine ganz ernsthafte Angelegenheit, die eher als Nebeneffekt für solch überraschende Momente genutzt werden kann: Vor allem für geschäftliche Kunden bietet sich diese neue Dienstleistung von WIVA-Werbung Fürth an. So könnten Sie z.B. Ihren Kunden in Deutschland Rechnungen per Post (aus Deutschland) schicken — egal wo in der Welt sie sich gerade aufhalten. Weltweites Arbeiten bei grenzenloser Mobilität wird hierdurch noch ein Stück einfacher.

Einige Kunden koppeln auch Ihren automatisierten Rechnungsausgang mit PDF-Erstellung und automatischer Übertragung an das Briefdruckzentrum. So sparen Sie sich das Ausdrucken, Kuvertieren, Adressieren, Frankieren und Einliefern bei der Post. Die Post verarbeitung wird an einen Dienstleister delegiert, der dies zuverlässig und schnell erledigt. Clevere Zusatzleistungen und technische Kniffe ermöglichen z.B. Seriendrucke unterschiedlich langer Briefe über eine einzelne PDF-Datei oder die Initiierung des Versandes durch eine einfache E-Mail.

RalphGL meint: Diese „Schnittstelle“ der virtuellen Welt zum realen Postversand ist eine innovative Idee, gut umgesetzt, einfach und schnell zu handhaben, mit der ganz neue Möglichkeiten der Korrespondenz-Automatisierung offen stehen.

Selbstverständlich bin ich nicht Autor des Buches, die Rechte entsprechen der Lizensierung der Wikipedia. Die immer aktuelle Version des Buches findet sich auf der Wikipediaseite Mediengestalterbuch.

Was es heutzutage alles gibt: Da hat man schneller ein 200seitiges Buch erstellt — als gelesen. Bin gespannt, was sich in „meinem“ Buch alles Interessantes findet.

Microsoft Publisher ist eine Software, welche die meisten Grafiker und Drucker am liebsten abschaffen möchten. Nicht etwa, weil sie so gut ist, sondern weil die Daten, die damit erzeugt werden nicht zu gebrauchen sind¹.

Doch was macht man nun als „Verarbeiter“ mit pub-Datein von Kunden? Entweder man bittet den Kunden irgendwie eine PDF-Datei zu erstellen (was mitunter dazu führt, dass man erklären muss, wie das geht) oder man macht diese Pub-Datei sichtbar, indem man selbst ein PDF daraus generiert. Doch sicherlich bin ich nicht der einzige „Druckvorstufler“, der sich weigert sowas wie den Microsoft Publisher auf seinem Computer zu installieren. Erfreulicherweise ist das aber auch nicht möglich, denn es gibt eine Webseite, die Datein in pdf konvertiert — und auch Publisher-Dokumente annimmt, zumindest wenn diese nicht größer sind als 6 MB.

Die Webseite heißt conv2pdf

Alle möglichen Dateien können dorthin übertragen werden und werden dann von diesem Server in eine PDF konvertiert. Selbstverständlich verbietet es sich dorthin vertrauliche Daten zu senden! Man kann wählen, ob man die generierte PDF herunterladen oder per E-Mail versenden möchte.

Die erhaltene PDF ist natürlich NICHT für den Druck geeignet — aber zumindest erhält man hierdurch eine vage Vorstellung davon, was der Kunde eigentlich möchte.

conv2pdf ist ein toller kostenfrei nutzbarer Dienst, den wir gerne weiterempfehlen!

Tipp:

¹ Laut einem Microsoft youtube-Video kann man mit dem Publisher 2010 auch PDF für die Druckvorstufe erzeugen. Ich habe das nicht geprüft. Wer aber seine Drucksachen gerne mit Publisher gestalten möchte, der soll doch bitte so freundlich sein und diese Funktion auch benutzen — und dann druckgeeignete PDF abliefern. Wer nicht die aktuelle Version des Publishers einsetzen, aber selbst Grafiken erstellen oder seine Drucksachen gestalten möchte (ohne Geld für kommerzielle Software auszugeben) der sollte mal inkscape als Grafikprogramm (freie Alternative zu Corel Draw oder Illustrator), Gimp als Bildverarbeitungsprogramm und Scribus als Layoutprogramm probieren.

Deshalb beschreibe ich an dieser Stelle kurz die Webseite http://pdfmyurl.com über die man ein PDF einer Webseite erstellen kann. Das finde ich zwar zunächst mal eher langweilig, schließlich haben wir wohl so ziemlich alle einen PDF-Druckertreiber auf unseren Computern installiert. Spannend hingegen finde ich, dass man pdfmyurl.com auch mit Parametern aufrufen kann, und dass dieser Aufruf freundlicherweise auch von wget geduldet wird. Dies entnehme ich der Beschreibung der Advanced Options, in denen es heißt:

How to use on your server

Synopsis (the first -O <filename> is wget's own output file option):
  wget -O opentracker.pdf "pdfmyurl.com?url=www.opentracker.net&-O=Landscape&--header-left=hello"

Es wird also ausdrücklich die Möglichkeit zum Aufruf mittels wget und damit die Basis zu einer eleganten Automatisierung per CRON beschrieben.
Zahlreiche Parameter wie z.B.

-t, --toc                           Insert a table of content in the beginning
                                     of the document

  --print-media-type              Use print media-type instead of screen

ermöglichen das Aussehen der PDF anzupassen.
Leider gibt es mit Umlauten in URLs Probleme.

Nun fehlt mir nur noch eine gute Idee, was man damit sinnvolles anstellen könnte

Die Vorhersehbarkeit des Darstellungsergebnisses von Webseiten hängt von zahlreichen Faktoren ab und ist leider nur bedingt vorhersehbar. Darin unterscheiden sich Online-Publikationen ganz erheblich von Drucksachen. In der Druckvorstufe wurden Standardformate und spezielle Workflows entwickelt, um keine bösen Überraschungen in der Produktion zu erleben (siehe PDF/X1a, PDF/X3 etc.). Hält sich der Grafiker bzw. Druckdatenersteller an den vereinbarten Standard, verwendet er normierte, profilierte Farbangaben und berücksichtigt die Papiereigenschaften, kann er sich ziemlich sicher sein, am Ende auch das gewünschte Ergebnis auf Papier in Händen halten zu können. Und — ist die Drucksache erst mal produziert — wird auch wirklich jeder Betrachter das gleiche Druckergebnis in Händen halten können.

Im Onlinebereich verhält es sich (leider) völlig anders.

Einflussfaktoren für die Darstellung von Webseiten

Leider ist es keine Selbstverständlichkeit, dass eine Webseite beim Betrachter X auch nur annähernd so aussieht, wie beim Betrachter Y. Denn nicht jeder Betrachter betrachtet die vom Server ausgelieferte Seite unter gleichen Bedingungen. Einfluss auf das konkrete Darstellungsergebnis haben:

• Bildschirmauflösung des Betrachters
• Betriebssystem und installierte Schriften
• Browser, –version und –einstellungen
• Farbmanagement von Betriebssystem, Browser und nicht zuletzt die Farbtiefe und Bildschirmeinstellungen

Die Einhaltung von Webstandards wie XHTML 1.0 oder HTML 4.x bieten leider nur bedingt eine Gewähr für ein vorhersehbares Ergebnis, denn

• ältere Browser haben mit neueren Standards naturgemäß Probleme
• auch einige aktuelle Browser erfüllen nur teilweise die Standardanforderungen

Typografie im Web — Denkste!

Für professionelle Drucksachengestalter ist es eine Selbstverständlichkeit Elemente durch Tabulatoren oder optimierten Zeichenausgleich bündig auszurichten, den Zeilenumbruch durch eine Worttrennung zu optimieren, „typografische Anführungszeichen“ einzusetzen, zwischen Bindestrich und Halbgeviert zu unterscheiden etc. All dies wurde leider bis heute im www nicht einmal in den aktuellen Standards berücksichtigt. Es gibt zwar erfreuliche Ansätze hierzu, wie z.B. das auf dieser Webseite verwendete WordPress-Plugin wp-typography welches u.a. eine Silbentrennung und zumindest unterschiedliche Anführungs– und Schlusszeichen ermöglicht. (Nachtrag vom 20.8.09: Toll, dass nach dem heutigen Update und der Änderung der Einstellung der Anführungszeichen in „deutsch“ auch „richtige deutsche Anführungszeichen“ verwendet werden. Dieses empfehlenswerte Modul stellt einen Meilenstein für die Web-Typografie dar!). Aber letztlich können solche Hilfsmittel nur durch einen zusätzlichen Implementationsaufwand auf einer Webseite verwendet werden.

Der Weg aus dem Dilemma

Vor einigen Jahren meinten einige Designer, dass der beste Weg um eine einheitliche Darstellung von Webseiten zu gewährleisten darin bestünde die Seiten möglichst komplett als Bilder zu speichern und auszuliefern. Oft wurden die Webseiten aus mehreren Einzelbildern zusammengesetzt, um so z.B. das Bild für den Inhalt unabhängig von Kopf– oder Fußbereich zu wechseln — z.B. durch eine entsprechende Interaktion wie einen Menüklick des Benutzers. Diese zerschnittenen Einzelbilder wurden dann in einer Tabelle wieder zusammen gesetzt.
Diese „Lösung“ welche die Grundidee von Hypertext — und dabei handelt es sich schließlich beim www — ad absurdum führt, erregte die Gemüter nicht nur der Programmierer und derjenigen, die der Meinung waren eine Webseite würde in erster Linie Inhalt — also Texte und Links transportieren und eine Tabelle wäre zur tabellarischen Darstellung von Inhalten da. Auch bei gemäßigterer Interpretation ergaben sich ernsthafte Kritikpunkte:

1. Eine Webseite, die nur aus Bildern besteht ist weder für Suchmaschinen, noch für Menschen mit einem visuellen Handicap „sicht„bar
2. Eine Webseite, die aus Bildern aufgebaut ist, gibt eine fixe Größe in Pixel vor — unabhängig von der Bildschirmauflösung des Betrachters. Ob die Schrift also im Ergebnis 4mm groß auf dem Bildschirm erscheint, oder nur 1mm groß ist eben gerade nicht vorhersehbar, das Ziel der Designer folglich verfehlt.

Solche Pixelseiten sind erfreulicherweise mittlerweile kaum noch anzutreffen. Und auch Webseiten, die kompetente Autoren mit Werkzeugen wie Flash erstellt haben sind nicht mehr zwangsläufig „Pixelseiten“ sondern können durchaus kompatibel, barrierefrei und Suchmaschinenfreundlich sein.

Stattdessen hat sich in den letzten Jahren die Einsicht durchgesetzt, dass eine pixelidentische Darstellung von Webseiten unter allen Bedingungen nicht das Ziel sein sollte. Denn — von den oben bezeichneten Problemen dies zu erreichen einmal abgesehen — eleminiert man die Vorzüge, die man durch die Beteiligung zweier Seiten (dem Server der die Seiten generiert und ausliefert und dem Client mit Browser an dem sie betrachtet werden) an der Darstellung einer Webseite erreichen könnte.
Schließlich ist es doch gut und kein Problem, wenn z.B. ein kurzsichtiger Benutzer oder einer an einem sehr hoch auflösenden Bildschirm, bei dem ein Pixel folglich sehr klein ist, die Möglichkeit haben die Darstellung der Schrift im Browser zu vergrößern. Oder wenn ein Mobiltelefon mit einem sehr schmalen Display Inhalte in einer Spalte darstellt, die man auf dem PC in mehreren Spalten nebeneinander sieht. Das „Problem“ der unterschiedlichen Darstellung ist eigentlich nicht unbedingt eines, sondern kann zu einem Vorteil gereichen, wenn man die Möglichkeiten von XHTML 1.0 bzw. HTML4.x zu nutzen weiß.

Doch der Designer, der naturgemäß alles unter seiner Kontrolle haben möchte, (aber auch der technisch unbedarfte Kunde) hat damit oft ein Problem, schließlich führt z.B. eine Vergrößerung der Schrift zu veränderten Zeilenumbrüchen und einer Verkleinerung der Abstände zwischen der Schrift. Befindet sich die Schrift in einer fixen Spalte, oder vor Hintergrundgrafiken, z.B. im Menü, kann es dazu führen, dass die Schrift über die vorgesehenen Bereiche hinausragt.
Ein Meilenstein zur Lösung dieser Probleme war die Einführung der Skalierung von Bildern, die zunächst Opera, dann auch Firefox und mittlerweile auch der Internet Explorer (ab Version 7) eingeführt hat. Nun vergrößert und verkleinert der Benutzer über entsprechende Interaktion nicht nur den Text, sondern in gleichem Maße auch die Grafiken.

Browserweichen und angepasste Stylesheets einsetzen

Eine Möglichkeit die Darstellung einer Seite unter einer ganz bestimmten Umgebung zu beeinflussen, ist für genau diese Bedingung einen speziell hierfür konzipierten Inhalt auszuliefern. Ein häufig verwendeter Fall ist z.B. bei der Verwendung von PNG-Grafiken mit Alphakanal (für weiche Transparenzen) eine Spezialversion für den Internet-Explorer vor Version 7 auszuliefern, da der IE erst abVersion 7 PNG mit Alphakanal beherrscht.

Das Problem bei solchen Weichen ist, dass zunächst ganz genau ermittelt werden muss unter welchen Bedingungen eine abweichende Version ausgeliefert werden soll. Diese Bedingung muss sauber formuliert und ebenso sauber umgesetzt werden. Hätte man z.B. zu Zeiten, als es noch keinen Internet Explorer 7 gab eine PNG-Weiche programmiert, die für den Internet Explorer eine abweichende Version liefert, so wäre diese Umsetzung mit Einführung des Internet Explorers 7 überholt gewesen.

Man muss sich klar sein, dass jede Browserweiche einen zusätzlichen Implementations– und Testaufwand bedeutet. Folglich sollte man diesen Lösungsansatz nur im Ausnahmefall wählen und auf jeden Fall ausgiebig testen.

Fehler eliminieren

Mit Fehlern im html-Code wird von verschiedenen Browsern unterschiedlich umgegangen. Der eine Browser „rät“, was gemeint sein könnte, der andere ignoriert ein fehlerhaftes Element einfach. Wer eine einheitliche Darstellung von Webseiten erreichen möchte, sollte deshalb auf einen standardkonformen validierten Code wert legen, der möglichst keine Fehler aufweist. Dass dies in der Praxis meist nicht zu 100% erreicht werden kann sollte nicht dazu führen, dass man dieses Ziel aus den Augen verliert.

Moderne Standards nutzen und Workarounds minimieren

Idealerweise stellen alle modernen Browser eine Webseite die fehlerfreien Code enthält identisch dar. Von diesem Ziel ist man gar nicht mehr so weit entfernt. Aktuelle Versionen von Opera, Firefox und Internet Explorer beherrschen weitgehend die aktuellen W3C-Standards. Für welche Browser sich eine individuelle Anpassung und Optimierung lohnt ist immer individuell anhand der Zielgruppe, der Reichweite des Projektes und des damit einhergehenden Budgets sowie der zu erwartenden Quote an Nutzern zu entscheiden. Ob es sich lohnt für einen Browser, den 2% der Webseitenbesucher nutzen zu optimieren und evtl. einen workaround zu erstellen, das muss jeder für sich entscheiden. Heutzutage (Stand August 2009) nutzen bedauerlicherweise immer noch zwischen 5 und 10% der Webseitenbesucher (meiner Webseiten) den Internet Explorer in der Version 6. Diese nicht geringe Anzahl lässt einen Test und eine Anpassung für den IE 6 sinnvoll erscheinen.

Doch wie testet man die Darstellungsergebnisse mit verschiedenen Browsern. Die gängisten Browser und Systeme sollte man selbst auf einem Live-System testen, also z.B. Windows XP, Vista und Windows 7 mit Internet Explorer 7 und 8 sowie Firefox 3. Natürlich sollte man bei der Wahl seiner Testsysteme auch die Zielgruppe im Auge behalten. Eine Webseite, die sich mit OS X-Themen und Druckvorstufe beschäftigt, sollte auch für Mac-User verträglich sein, wohingegen das bei einer Schnäppchenjägerseite für gebrauchte Computerteile evtl. eher keine Rolle spielt. Um nicht einen ganzen Rechnerpark in die Ecke stellen zu müssen, empfiehlt es sich mit virtuellen Maschinen zu arbeiten. So kann z.B. eine Basisinstallation von Windows XP mit Internet Explorer in einer virtuellen Maschine ebenso gute Dienste leisten, wie ein Internet Explorer 5 in einer Windows 2000 VM.

So sieht die Seite blog.agentur-lindner.com in 34 verschiedenen Browsern aus

Doch egal wie viele PCs und VMs man in die Ecke stellt, irgendwann ist Schluss und manchmal ist es auch einfach zu aufwändig für eine schnelle Revalidierung Tests an mehreren Rechnern direkt durchzuführen. Die Alternative hierzu heißt www.browsershots.org. Dieser Webdienst liefert Bildschirmabbildungen der gewünschten Webseite unter fast allen Betriebssystemen und Browsern an. Selbst Exoten können hiermit getestet werden. Interessant ist auch die Möglichkeit eine bestimmte Bildschirmbreite oder Farbtiefe vorzugeben. Browsershots leitet die Anfrage an eine Vielzahl von Systeme mit unterschiedlichsten Browsern und Betriebssystemen weiter und erhält von diesen die jeweiligen Bilder der angefragten Webseite wieder zurück um sie dann an den Anfrager auszuliefern. Die Bilder können als PNG-Grafiken im Browser angesehen oder als ZIP-Archiv heruntergeladen werden. Eine geniale Sache! Jede Webseite sollte vor Abschluss der Arbeiten mit diesem System überprüft werden!

Dieser Artikel ist durch ein Passwort geschützt.
Um ihn anzusehen, trage es bitte hier ein:

Passwort:

Es werden überwiegend PDF/X1a-Daten an Offsetdruckereien übergeben. Je nach verwendetem Papiersorten werden die aktuellen Profile „ISO Coated V2 (ECI)“ für gestrichene Papiere oder „ISO Uncoated“ eingebunden.

Mit Produzenten, welche die optimale Separation der profilierten Farbdaten selbst vornehmen möchten, sprechen wir gerne einen individuellen Ablauf ab und übergeben z.B. unseparierte PDF/X3-Daten.

Kunden, die farbverbindliche Proofs unserer Daten wünschen, stellen wir unsere fertigen Daten zur Verfügung oder lassen durch ein Partnerunternehmen (z.B. www.crossover-mediagroup.de überregional, oder die Druckerei Tümmels in Nürnberg-Eibach einen normgerechten und FOGRA-zertifizierten PROOF erstellen).