PDF komprimieren mit CF 9 noch nicht das Gelbe vom Ei
Die neue Funktion zum Optimieren von PDF-Dateien in ColdFusion 9 Beta hat mich neugierig gemacht. Das Resultat einer ersten Versuchsreihe mit verschiedenen Musterdateien brachte allerdings ein wenig Ernüchterung. Vorsicht beim Einsatz dieser Funktion, unerwünschte Effekte können auftreten – wenn überhaupt Effekte bemerkt werden.
Ich bin mir nicht sicher, ob es korrekt ist von einem Problem im Content-Management oder Document-Management zu sprechen im Bezug auf nicht fürs Internet optimierte PDF-Dateien. Tatsache bei meinem Arbeitgeber backslash ist jedenfalls, dass wir sehr häufig nicht optimierte PDF auf Kunden-Webseiten und in der Administration unserer Applikationen entdecken. In aller Regel stört sich ja niemand daran, wenn die Datei grösser ist als unbedingt nötig. Trotzdem wäre es natürlich interessant, wenn man autormatisiert Bandbreite sparen und Download-Zeiten verringern könnte. Und da kommt die neue Optimierungsfunktion von CF9 gerade recht.
source="#source#"
overwrite="yes"
algo="Bicubic"
destination="#Replace(source, '.pdf', '_bic.pdf')#">
</cfpdf>
Welche Methode?
Für den Optimierungsmodus stehen drei Varianten zur Verfügung: bicubic, bilinear und nearest_neighbour (Achtung: nearest_neighbour ist in der aktuellen Dokumentation falsch geschrieben, nearest_neighbor). Für meine Versuchsreihen habe ich jeweils alle drei Optimierungs-Varianten angewendet, um auch hier die Unterschiede feststellen zu können. Was bewirken diese Methoden eigentlich?
- bicubic = bikubisch:
Mit dieser Methode werden die Farben aller acht umgebenden Pixel miteinbezogen. Dadurch wird das Bild besonders stark geglättet, allerdings mit dem Nachteil, dass es das rechenintensivste der drei Verfahren ist. Geeignet ist die bikubische Interpolation vor allem für Fotos. - bilinear:
Für die bilinearen Interpolation werden die Farben der vier umliegenden Pixel verwendet – und damit gerade einmal halb soviel wie bei der bikubischen, was sich in der Berechnungsperfomance positiv im Ergebnis aber negativ bemerkbar macht. - nearest_neighbour = Pixelwiederholung:
Bei der Pixelwiederholung wird einfach die benötigte Anzahl von Pixeln hinzugefügt oder entfernt. Sie ist vergleichsweise performant, führt aber schnell einmal zu ausgefransten Ecken. Geeignet ist sie für grafische Darstellungen mit wenigen, flächigen Farben und klaren Konturen.
Wo Performance keine Rolle spielt, also beispielsweise im Desktop-Bereich mit Photoshop würde ich folglich in der Regel hauptsächlich die bikubische Methode wählen, um das beste Resultat zu erzielen. Wird ein Webserver mit diesen Transformationsaufgaben beschäftigt, muss man die Wahl der Waffen sicher überdenken.
Ausgangslage
Alle Tests habe ich mit einer lokalen Installation von ColdFusion 9 Beta unter Windows XP mit dem Built-in-Webserver durchgeführt. Der CF-Server hat 250 MB RAM zur Verfügung. Die Grundeinstellungen wurden nicht verändert.
Fall 1: Datei von der Druckerei
Mein erster Testfall ist ein druckfähiges PDF, ein Flyer, den man seinen Kunden gerne einmal zum Download anbietet.
| Datei | Methode | Dateigrösse | Zeit in ms | Bemerkung |
|---|---|---|---|---|
| original | 2’760 Kb | |||
| company_bic.pdf | bikubisch | 3’115 Kb | 23’700 | Bilder invertiert |
| company_bil.pdf | bilinear | 3’114 Kb | 9’297 | Bilder invertiert |
| company_NEAR.pdf | nearest_neighbour | 3’128 Kb | 3’500 | Bilder invertiert |
| company_low.pdf | Mit Acrobat | 396 Kb |
Ja, da kann sich schnell Ernüchterung einstellen. Mit dieser Datei ist CF gar nicht zurecht gekommen. Die Bilder wurden invertiert, von Optimierung keine Spur und der Prozess dauerte für meinen Geschmack sehr lange. Im Vergleich dazu das in Adobe Acrobat optimierte PDF: nicht einmal ganz 400 Kilobyte bei einwandfreier Qualität für die Bildschirmanzeige. Die Quelldaten sind also sehr entscheidend für die Optimierungsmöglichkeiten.
Fall 2: Pressemitteilung
Pressemitteilungen werden ebenfalls gerne verbreitet. Meine zweiseitiges Muster ist schlicht gehalten und enthält in der Kopfzeile ein Logo. Erstellt wurde das Dokument in Word, als PDF exportiert mit Bullzip PDF Printer in den Standard-Einstellungen.
| Datei | Methode | Dateigrösse | Zeit in ms | Bemerkung |
|---|---|---|---|---|
| original | 33 Kb | |||
| pr_bic.pdf | bikubisch | 30 Kb | 891 | |
| pr_bil.pdf | bilinear | 31 Kb | 322 | |
| pr_NEAR.pdf | nearest_neighbour | 32 Kb | 172 |
Offensichtlich gab es bei diesem Dokument nicht allzu viel zu optimieren. Es enhielt auch so gut wie keine Bilddaten, die noch weiter komprimiert hätten werden können. Aber auch hier sieht man einen deutlichen Performance-Unterschied, diesen Faktor werden wir in der Folge immer antreffen. Qualitativ lassen sich für mich keine Unterschiede erkennen – allerdings bin auch auch kein Fachmann.
Fall 3: Pressemitteilung, in Druckauflösung
Um vielleicht doch noch einen grössere Differenz erzielen zu können, habe ich bei diesem Versuch die Einstellungen beim Erstellen der Quelldatei angepasst, am Inhalt der Meldung aber nichts verändert. Der Fall ist zugegebenmassen in der Praxis nicht sinnvoll.
| Datei | Methode | Dateigrösse | Zeit in ms | Bemerkung |
|---|---|---|---|---|
| original | 70 Kb | |||
| PR_druck_bic.pdf | bikubisch | 43 Kb | 1438 | |
| PR_druck_bil.pdf | bilinear | 43 Kb | 547 | |
| PR_druck_NEAR.pdf | nearest_neighbour | 44 Kb | 203 |
Immerhin: ein Unterschied ist feststellbar, für mich aber wiederum nicht zwischen den optimierten Dateien sondern nur zum Original. Und das auch nur in Bezug auf die Dateigrösse. Allerdings hätte ich erwartet, dass die Dateigrösse nun in die Region des Testfalls 2 sinken sollte. Rund 25% hätte man also sicher noch irgendwo abspecken können.
Fall 3: Pressemitteilung mit Bild
Was man in der Praxis auch nicht unbedingt macht, diente mir als Grundlage für das letzte Szenario: die Pressemitteilung wurde mit einem Bild angereichert. Und wieder mit der Standard-Einstellung als PDF exportiert.
| Datei | Methode | Dateigrösse | Zeit in ms | Bemerkung |
|---|---|---|---|---|
| original | 279 Kb | |||
| PR_Barrierefrei_bild_bic.pdf | bikubisch | 152 Kb | 9’656 | |
| PR_Barrierefrei_bild_bil.pdf | bilinear | 153 Kb | 3’656 | |
| PR_Barrierefrei_bild_NEAR.pdf | nearest_neighbour | 155 Kb | 1’297 | |
| PR_Barrierefrei_bild_Web.pdf | Distiller Web | 42 Kb | ||
| PR_Barrierefrei_bild_Standard.pdf | Distiller Standard | 108 Kb |
Die Dateien konnten nicht ganz auf die Hälfte ihrer ursprünglichen Dateigrösse verkleinert werden. Die Qualität des Bildes hat sich für mein ungeschultes Auge nicht merklich verschlechtert. Für dieses Beispiel habe ich das Original zusätzlich als PostScript-Datei exportiert und mit dem Acrobat Distiller mit den Einstellungen Standard und Web in ein PDF umgewandelt. Die Dateigrösse schrumpft merklich, allerdings auch die Qualität. Gerade bei der Web-Version ist die Kopfzeile kaum mehr zu lesen und auch im Foto machen sich Qualitätseinbussen bemerkbar.
Fazit
Den Einsatz der Optimierungsfunktion kann ich derzeit nur bedingt empfehlen. Die Kontrolle über das Ergebnis nicht überzeugend, respektive es kann nicht im Voraus abgeschätz werden, ob gerade komplexe Dateien richtig optimiert werden. Dateifehler können so nicht ausgeschlossen werden. Und die wiederum sind automatisiert nur schwierig zu entdecken und abzufangen – wenn überhaupt. Das Optimierungspotential im Vergleich zu Offline-Variante auch nicht berauschend, wenn man bedenkt, wieviel Performance dafür gebraucht wird. Bei einem massenhaften Einsatz wäre dies vermutlich ein Fall für Cloud Computing.
TrackBacks
Die neue Funktion zum Optimieren von PDF-Dateien in ColdFusion 9 Beta hat mich neugierig gemacht. Da
Trackback URL dieses Eintrages:
http://www.samelis.ch/blog/mischa/trackback.cfm?id=8103D64C-ABBA-4CB4-93DC2BCE8EFDAB05


Kommentare
Für diesen Eintrag existieren keine Kommentare.