www.fabiankeil.de/pdf-sucks.html

Warum PDF kein Austauschformat ist

Immer mehr Leute kommen auf die schlechte Idee, Informationen in proprietären Binärformaten zu verstecken. Firmen verzichten darauf, Handbücher zu drucken, ganze Webseiten werden unbenutzbar.

Führend im Bereich Datengrab ist momentan Adobes PDF – auch wenn sich Micros~1 mit DOC redlich bemüht. Dieser Text liefert ein paar Argumente, warum PDF nicht die Nummer 1 als Austauschformat ist, und legt dar, warum diese Position von HTML beansprucht werden darf.

Es geht lediglich um Austauschformate mit offener Zielgruppe und den Irrglauben, jeder könnte etwas mit PDFs anfangen. Niemand soll daran gehindert werden, weiterhin in PDF zu veröffentlichen, vorher sollte man aber bitte für eine Alternative sorgen, die jeder nutzen kann.

Argumente gegen PDF

• Wenig verbreitete Lese-Software

  Wenig bezieht sich hier nicht auf die absolute Zahl derer, die PDFs lesen können – das sind schon ein paar. Im Verhältnis zur Anzahl der Leute, die in der Lage sind etwas mit HTML-Dateien anzufangen, sind es jedoch wenige.

  Jedes ansatzweise verbreitetes Desktop-Betriebssystem bietet mittlerweile auch HTML-Unterstützung in Form von mehr oder weniger tauglichen Browsern, so dass deren Verbreitung nahe 100% liegt.

  Bei PDFs sieht die Sache deutlich schlechter aus. Während bei den meisten GNU/Linux-Distributionen noch Ghostscript vorhanden ist, das mit den wichtigsten PDF-Funktionen klar kommt, werden die Betriebssysteme aus Redmond ohne derartige Software verkauft.

  PDF-Leser können daher keinesfalls als überall vorhanden angesehen werden, Browser schon.

• PDF ist nicht abwärtskompatibel

  Adobe implementiert mit jeder neuen Version Spielereien, die dafür sorgen, dass PDFs nicht abwärtskompatibel sind. Schon beim Hochzählen der Nachkommastelle kommt Freude auf.

  fk@r51 ~/downloads/studium $xpdf bafög-Fbl1_07_04.pdf 
  Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)
  Error: Bad annotation action
  Error: Bad annotation action
  Error: Bad annotation action
  Error: Bad annotation action
  Segmentation fault (core dumped)

  Die Freude wird weiter gesteigert, da es für die meisten Plattformen selbst von Adobe keine aktuellen Leser gibt.

  HTML dagegen ist abwärtskompatibel. Browser ignorieren ihnen unbekannte HTML-Erweiterungen einfach, in den meisten Fällen kommt der Benutzer dennoch an alle für ihn wichtigen Informationen ran, lediglich die Seitendarstellung ist schlichter.

  Auf dieser Seite verwende ich teilweise HTML-Elemente, die in älteren Browsern nicht unterstützt werden. Außerdem setze ich CSS ein, um das grafische Erscheinungsbild geringfügig aufzumotzen.

  Benutzer von sehr alten grafischen Browsern werden nicht wahrnehmen, dass ich Überschriften grau hinterlegt habe. Sie können sich nicht die Bedeutungen von verwendeten Abkürzungen anzeigen lassen und sehen außerdem nicht, welche Textstellen ich stark oder schwach hervorheben möchte.

  Benutzer von Text-Browsern verzichten zusätzlich noch auf die Bilder, bekommen bei den meisten Browsern aber den Ersatztext angezeigt.

  Mit jedem Browser ist es jedoch möglich, dieser Seite die wesentlichen Informationen zu entnehmen.

• PDFs bauen Barrieren auf

  Für Blinde und stark sehbehinderte Menschen stellen PDF-Dateien eine unnötige Hürde dar.

  HTML-Dateien sind dagegen, Dank semantischer Auszeichnung und Textformat, auch für Screenreader geeignet. Blinde können sich die Inhalte vom Rechner vorlesen lassen oder eine Braillezeile nutzen.

  Im Rahmen seiner Accessibility-Page gibt Matthias Hänel genauere Informationen über die Probleme, die Screenreader mit PDF-Dateien haben. Er empfiehlt, Alternativ-Versionen in anderen Formaten anzubieten. Amen.

• PDFs sind aufgebläht

  Den Inhalt von PDF-Dateien wird man so gut wie immer mit HTML datensparender vermitteln können.

  Falls man auf CD-ROM veröffentlicht, spielt die Dateigröße zwar keine großen Rolle mehr, im Internet jedoch sehr wohl.

• PDFs sind ein Sicherheitsrisiko

  In der Vergangenheit hat es immer wieder Probleme mit PDF-Lesern gegeben. Unbeabsichtigt erlaubte Adobe den PDF-Autoren, Systemaufrufe dazu zu nutzen, den Rechner des Benutzers fernzuwarten, Daten zu löschen, zu manipulieren, bzw. anderweitig kreativ zu sein.

  Siehe: Sicherheitsrisiko durch Adobes PDF und Cracker spills the beans on PDF flaw.

  Einen ordentlich konfigurierten Browser wird man kaum zu solchen Späßen überreden können.

• PDFs sind unkomfortabel zu lesen

  Während jeder seinen Browser einigermaßen bedienen kann, ist die Arbeit mit PDF-Lesern für viele ungewohnt, und lenkt vom Lesen ab.

  Darüber hinaus hat der Acrobat Reader – der wohl am weitesten verbreitete PDF-Leser – eine miese Oberfläche.

  Die Rechneranforderungen sind abenteuerlich: es ist kein Problem, einen Gigahertz-Rechner damit zu überlasten, in einer zehnseitigen PDF-Datei mit vereinzelten Bildern zu scrollen.

  Der Programmstart dauert Jahre, die Schriftgröße lässt sich nicht anständig skalieren und man hat die ganze Zeit Adobe-Werbung vor der Nase.

  Daraus folgt ...

• PDF ist unbeliebt

  Jakob Nielsen formuliert es in seiner Alertbox PDF: Unfit for Human Consumption noch ein Bisschen deutlicher:

  Users Hate PDF

  Selbst das kann man meiner Meinung nach noch präzisieren:

  Die Benutzer hassen sowohl PDF, als auch die Intellektuell-Anders-Befähigten, die keine lesbaren Alternativen anbieten.

  Bevor man seine Informationen PDF-verschlüsselt sollte man darüber nachdenken, wie hoch die Motivation des anvisierten Lesers sein wird. Wenn der Leser nicht auf die enthaltenen Informationen angewiesen ist, wird er möglicherweise allein aufgrund des Format darauf verzichten. Ich tue es täglich und bin sicher nicht der einzige.

Argumente für PDF (die keine sind)

• PDFs bieten DRM

  PDF bietet eine Reihe von "Sicherheitsfunktionen": Beim Erstellen der PDFs kann angegeben werden, was der Benutzer mit den Dokumenten noch machen dürfen soll (z.B. lesen, aber kein c&p oder Drucken), und wer überhaupt Benutzer sein soll (Passwortschutz).

  An die Tauglichkeit dieser Restriktionen glaubt nicht einmal Adobe.

  Wie aus dem PDF-verschlüsselten Dokument How Secure Is PDF? hervorgeht, erwartet Adobe lediglich, dass die Software-Entwickler die hinter dem Security System steckende Absicht anerkennen.

  Da die erwartete Anerkennung bei einigen Entwicklern fehlt, fehlt diesem Security System die Security.

  Am bekanntesten für die Nichtanerkennung ist die Firma ElcomSoft mit dem Produkt Advanced PDF Password Recovery. Bekannt auch deshalb, weil Adobe mit einem lächerlichen DMCA-Prozess fleißig Werbung gemacht hat.

  An Stelle des PDF-DRMs kann man in den Head-Bereich seiner HTML-Dateien auch Wünsche wie <meta name="DRM" content="print=NO, read=YES, password=SCHWERTFISCH, encryption=heavy"> einbauen.

  Da diese Zeile auch Niemand anerkennt, wird es möglicherweise nicht so viele Browser daran hindern, dem Benutzer das Kopieren zu erlauben – der erzielte Schutz ist damit gleichwertig.

• PDFs erlauben pixelgenaue Formatierung

  Dieses Argument ist natürlich nicht zu widerlegen. Mangels eigener Erfahrung habe ich Adobes Marketing-Abteilung hier etwas zu ernst genommen. Das Foto zeigt ein gedrucktes PDF-Dokument: das dreieckige Formular-Feld war vom abstrakten Künstler sicher so nicht beabsichtigt und trat erst beim Druck in Erscheinung.

  Da ich aufgrund meiner begründeten Abneigung keine PDF-Software installiert habe, musste ich zum Drucken einen fremden Rechner nutzen. Irgend ein Teil der Kette: Windows XP, Adobe Acrobat, Canon-Drucker-Treiber und Canon-Drucker half den Pixel-Genauigkeits-Mythos zu widerlegen.

  Trotz meiner hundertprozentigen Fehlerquote mag die Pixel-Genauigkeit unter Laborbedingungen den Druck manchmal unverändert überleben, bringt aber selbst dann nicht nur Vorteile.

  Bei den meisten Dokumenten interessiert es den Benutzer herzlich wenig, ob eine Überschrift zwei Pixel verschoben dargestellt wird oder nicht. Wichtig ist ihm, dass er möglichst schnell an die Information kommt, die ihn interessiert.

  Pixelgenaue Darstellung kann den Leser jedoch bei der Informationssuche behindern, nämlich dann, wenn er eventuell nicht über so einen schönen 22-Zoll-Flatscreen wie der Designer verfügt, und daher horizontal scrollen muss.

• PDFs bündeln alle Inhalte in einer Datei

  Das ist sicher wahr, jedoch kein wesentlicher Vorteil.

  Wenn die Datei auf CD-ROM verteilt wird, spielt es keine Rolle, ob der Browser in X verschiedenen Verzeichnissen suchen muss, und auch im Web ist es egal. Vor dem E-Mail-Versand kann man die verwendeten Dateien in ein Archiv packen, und muss eben auf ein klein wenig Komfort verzichten.

Argumente für PDF, die HTML-Alternativen verbieten

• Keine

  Mir ist kein Argument bekannt, das Alternativen zu vorhanden PDFs verbietet.

  HTML hat in einigen Bereichen Schwächen: die Darstellung von komplexeren Formel oder Vektor-Grafiken erfordert Erweiterungen, die bei den meisten Anwendern momentan noch nicht installiert sind. Das bedeutet jedoch nicht, man dürfe sie deshalb nicht einsetzen.

  Der Rest des Inhalts bleibt auch ohne Erweiterungen zugänglich und die Installation der Erweiterungen stellt keine größere Hürde als die Installation eines PDF-Lesers dar.

  Wer PDF auf CD-ROM packt, um sich das Drucken von Handbüchern zu sparen (schon Sünde genug), sollte zumindest eine HTML-Version dazulegen und die Format-Wahl dem mündigen Nutzer überlassen. Auf eine CD-ROM passen ca. 700 MB, auch wenn die PDFs noch so aufgebläht sind, wird der Platz dafür ausreichen.

  Im Web sieht die Sache anders aus, hier kann man – wenn man die Sache mit den Stylesheets nicht verstanden hat – eine sogenannte Druckversion (PDF) als Alternative zur normalen Version (HTML) anbieten. Nicht umgekehrt!

  Auch wenn das Dokument ausschließlich für den Druck bestimmt ist, folgt daraus übrigens nicht, dass nur PDF in Frage kommen würde. Der Firlefanz-ärmerer Vorgänger PostScript ist in den meisten Fällen gleichwertig, kommt aber ohne die Kompatibilitäts-Probleme daher.

  Auch Anton Ertl beantwortet seine rhetorische Frage What is the PDF format good for? daher mit:

  Nothing. Use HTML and/or (compressed) Postscript instead.

Ich hoffe hier keine Killerargumente vergessen zu haben, falls doch, würde ich sie gerne per Mail entgegen nehmen. Bitte weder in PDF noch in HTML – aber das ist eine andere Baustelle.