Warum ist meine PDF-Datei so groß? (Und wie du es wirklich behebst)

Die Verwirrung hinter der Frage „Warum ist dieses PDF so groß?" beginnt meist damit, PDF wie ein einziges, einheitliches Dateiformat zu behandeln, so wie es eine reine Textdatei ist – dabei ähnelt ein PDF eher einem Containerformat, im Geiste vergleichbar mit einem ZIP-Archiv, das mehrere wirklich unterschiedliche Arten von Inhalt bündelt: Seitenlayout-Anweisungen, eingebettete Schriften, eingebettete Bilder, Vektorgrafiken und Metadaten, jeweils in ihrer eigenen internen Darstellung gespeichert. Die Container-Struktur selbst – der Teil, der tatsächlich PDF-spezifisch ist – ist winzig; ein PDF, das nur reinen Text und einfaches Layout enthält, ohne eingebettete Bilder oder ungewöhnliche Schriften, ist meist nur wenige Kilobyte groß, egal wie viele Seiten es hat. Wann immer ein PDF auf zig oder hunderte Megabyte anschwillt, stammt die Größe von dem, was in diesen Container eingebettet wurde, nicht vom Containerformat selbst – genau deshalb hat die Frage „Warum ist meine PDF so groß?" fast immer eine konkrete, identifizierbare Antwort, statt eine dem Format innewohnende Eigenschaft zu sein.

Ein Dokument, das durch das Einscannen physischer Seiten entsteht, ist auf Dateiformat-Ebene eigentlich gar kein Textdokument – es ist eine Abfolge von Ganzseitenfotos, eines pro Seite, verpackt in einem PDF-Container, und jede Regel zur Dateigröße, die für Fotos gilt, gilt hier ebenso. Scanner erfassen standardmäßig oft mit 300 dpi oder mehr, einer Auflösung, die für die physische Druckreproduktion kalibriert ist – weit mehr Pixeldaten, als ein Bildschirm überhaupt darstellen kann oder ein Leser für ein Dokument braucht, das ohnehin nur am Monitor betrachtet wird. Ein zehnseitiges gescanntes Dokument in Druckauflösung landet aus genau diesem Grund routinemäßig bei zig Megabyte: Es sind eben nicht zehn Seiten Text, sondern zehn Fotos in voller Auflösung, und Fotos in dieser Auflösung sind von Natur aus groß, ganz unabhängig davon, wie wenig visuelle Information sie auf einem gewöhnlichen Bildschirm tatsächlich vermitteln.

Das erklärt auch, warum ein gescanntes PDF so drastisch auf Kompression reagiert, während ein wirklich textbasiertes PDF das oft nicht tut: Jede Seite mit niedrigerer Auflösung und einer aggressiveren, aber für den Bildschirm noch angemessenen Kompressionsstufe neu zu kodieren, kann ein gescanntes Dokument um 70 bis 90 Prozent verkleinern, mit kaum oder gar keinem spürbaren Verlust an Lesbarkeit am Bildschirm – weil das Original von Anfang an weitaus mehr Pixeldaten mitschleppte, als ein Bildschirm je nutzen könnte.

Ein PDF, das auf jedem Gerät identisch dargestellt werden soll, unabhängig davon, welche Schriften dort installiert sind, bettet die tatsächlich verwendeten Schriftdateien meist direkt in das Dokument ein, statt eine Schrift nur namentlich zu referenzieren und zu hoffen, dass das System des Betrachters eine passende parat hat – technisch genau die richtige Entscheidung für zuverlässiges, konsistentes Rendering, aber mit einem echten Preis in Sachen Größe. Eine einzelne eingebettete Schriftfamilie, besonders mit mehreren Schnitten und Stilen, kann einem Dokument, das sonst fast nur aus Text besteht, leicht mehrere hundert Kilobyte hinzufügen. Bei Dokumenten mit chinesischem, japanischem oder koreanischem Text fällt dieser Effekt drastisch größer aus: Diese Schriftsysteme brauchen Tausende einzelner Glyphen statt der rund 100 Zeichen, die eine lateinische Schrift benötigt, sodass eine vollständig eingebettete CJK-Schrift allein schon zig Megabyte ausmachen kann – oft die mit Abstand größte Komponente eines ansonsten bescheidenen Dokuments.

Gut gebaute PDF-Erzeugungswerkzeuge lösen das, indem sie nur die Teilmenge der Glyphen einbetten, die ein Dokument tatsächlich verwendet, statt die komplette Schriftdatei – so bleibt der Größenaufwand proportional zu der tatsächlich vorhandenen Textmenge. Ein Dokument, das für eine Schrift mit großem Zeichensatz die vollständigen, nicht reduzierten Schriftdateien einbettet statt nur der wirklich genutzten Glyphen, kann am Ende ein Vielfaches mehr an Schriftdaten mit sich tragen, als der Text auf der Seite je brauchen könnte.

Manche PDF-Bearbeitungsworkflows, insbesondere solche mit inkrementellem Speichern, bei denen jede Änderung an die Datei angehängt wird, statt das gesamte Dokument neu zu schreiben, können frühere Versionen bearbeiteter Inhalte technisch weiterhin in der Datei belassen, obwohl sie nicht mehr sichtbar angezeigt werden – vergleichbar mit einer Bearbeitungshistorie, die sich still im Dokument ansammelt, statt aufgeräumt zu werden. Ein PDF, das auf diese Weise mehrere Bearbeitungsrunden durchlaufen hat, kann spürbar mehr Daten enthalten, als sein aktuell sichtbarer Inhalt vermuten lässt, da ein Teil dessen, was darin gespeichert ist, niemandem mehr angezeigt wird. Das Dokument über einen Prozess neu zu speichern, der die Datei aus ihrem aktuellen sichtbaren Zustand neu aufbaut, statt weiter an die bestehende Struktur anzuhängen, räumt das auf.

Eingebettete Bilder in einer Auflösung und Kompressionsstufe neu zu kodieren, die zur tatsächlichen Nutzung des Dokuments passt, ist die wirkungsvollste Maßnahme – und zwar deshalb, weil sie genau die Ursache angeht, die bei der überwältigenden Mehrheit übergroßer PDFs für das Aufblähen verantwortlich ist: Bilddaten, die in weit höherer Qualität erfasst oder eingebettet wurden, als der eigentliche Verwendungszweck braucht. Die interne Struktur des Dokuments aus ihrem aktuellen Zustand neu aufzubauen und Reste inkrementeller Bearbeitungen zu entfernen, ist ein kleinerer, aber durchaus echter zweiter Hebel. Was dagegen kaum etwas bringt, ist eine allgemeine Dateikompression auf ein bereits gespeichertes PDF anzuwenden: PDF-Betrachter und -Generatoren komprimieren die meisten eingebetteten Inhalte bereits intern mit gängiger, gut verstandener Kompression, sodass eine weitere allgemeine Kompressionsschicht über die gesamte Datei typischerweise nur ein bis zwei Prozent spart – deutlich weniger, als die eigentlichen eingebetteten Bilder und die Struktur neu zu verarbeiten, weil in einer bereits komprimierten Datei kaum noch Redundanz übrig ist, die ein zweiter, unabhängiger Kompressionsdurchgang finden könnte.