Wat er werkelijk gebeurt als u een PDF comprimeert
PDF123 Compress doet qpdf-streamrecompressie en object-stream-packing, geen beelddownsampling, lossy JPEG-hercodering of font-subsetting. Linearisatie verandert de bestandsgrootte nauwelijks.
Twee PDF's kunnen er op het scherm identiek uitzien en toch drie ordes van grootte verschillen: 50 KB tegenover 50 MB. Het verschil zit bijna nooit in de tekstoperatoren. In een contract van twintig pagina's zijn die meestal een paar tienduizend bytes; al het andere zijn beeldmonsters, een volledig ingebed fontprogramma en de vraag hoe strak streams en objecten zijn verpakt.
Dat heeft een gevolg dat u beter meteen benoemt: âeen PDF comprimerenâ is niet Ă©Ă©n handeling maar vier. Ze verkleinen verschillende dingen en vragen een verschillende prijs, en wie ze als Ă©Ă©n ding behandelt, krijgt tegenstrijdige ervaringen: het bestand is gecomprimeerd maar niet kleiner geworden, of het is kleiner geworden maar de pagina's hebben aan scherpte ingeboet.
Waar de grootte vandaan komt
De meeste gevallen van âwaarom is deze PDF zo groot?â beginnen met een scan of foto op hoge resolutie die nog op opnameformaat is ingebed. Het rekenwerk loont Ă©Ă©n keer: een pagina op Letter-formaat van 8,5 Ă 11 inch bij 300 DPI is ongeveer 2550 Ă 3300 pixels, en bij drie bytes per pixel is dat ongecomprimeerd ruwweg 25 MB. Twintig zulke pagina's komen vaak uit op 60 tot 80 MB voordat iemand compressie aanraakt.
De tweede bron zijn fonts. Een PDF kan een volledig fontprogramma insluiten zodat elke machine de tekst identiek weergeeft, en die kosten worden afgerekend op de omvang van de glyptabellen, niet op hoeveel tekst er werkelijk wordt gelezen. Daarom is font-subsetting een aparte grootteknop.
De derde bron is het inpakken zelf. Dezelfde inhoud kan met verspillende compressie-instellingen zijn opgeslagen, of de objecten kunnen verspreid door het bestand liggen, elk met eigen administratie. Niets daarvan verandert een pixel of een glyph, en juist dat deel kan streamrecompressie bereiken.
Achter âcomprimerenâ gaan vier verschillende knoppen schuil
Er zijn vier knoppen die de grootte beĂŻnvloeden. Ze grijpen op verschillende lagen aan en hun kosten overlappen elkaar nauwelijks. De verkeerde kiezen is de meest voorkomende reden waarom een compressierun niets lijkt te doen.
| Knop | Wat hij aanraakt | Winst in grootte | Prijs |
|---|---|---|---|
| Streamrecompressie en object streams | Hoe content streams worden gecomprimeerd, hoe objecten worden opgeslagen en ingepakt | Hangt af van hoe los het origineel was | Pagina-uiterlijk ongewijzigd |
| Beelddownsampling | Het aantal pixels, dus de resolutie | Groot | Resolutie permanent verlaagd |
| Lossy hercodering van beelden | De byteweergave van de bitmap | Groot | Beeldkwaliteit verlaagd |
| Font-subsetting | De ingebedde glyptabellen | Matig | Niet-gebruikte glyphs zijn niet meer bewerkbaar |
| Linearisatie | De volgorde van de objecten | Vrijwel nul | Levert in plaats daarvan laadtijd van de eerste pagina op |
De eerste vier rijen heten in de volksmond allemaal âcompressieâ, maar alleen de eerste laat de inhoud ongemoeid. Van die rij is de opbrengst ook het makkelijkst verkeerd in te schatten: een scan waarvan de omvang vooral uit onbewerkte beeldmonsters bestaat, bevat weinig redundantie om weg te halen. De knoppen die hem flink zouden verkleinen zijn downsampling en lossy hercodering, tegen de prijs dat u die resolutie en kwaliteit voorgoed kwijtraakt.
Welke van de vier knoppen PDF123 Compress indrukt
PDF comprimeren (POST /api/v1/misc/compress-pdf) gebruikt alleen de eerste rij. Het draait qpdf met compressie van ongecomprimeerde streams (--compress-streams=y), een tweede ronde over streams die al met Flate zijn gecomprimeerd (--recompress-flate), en het inpakken van objecten in object streams (--object-streams=generate).
Het downsamplet geen beelden, het hercodeert bitmaps niet naar een lagere JPEG-kwaliteit en het subset geen fonts. De pagina's horen er hetzelfde uit te zien, en de besparing komt van Flate-hercompressie en het inpakken van object streams.
De faalvoorwaarde verdient dezelfde duidelijkheid. Bestaat de omvang van een bestand vooral uit beelddata die al als JPEG is gecomprimeerd, dan valt er voor Flate niets meer samen te persen, omdat die beeldbytes buiten bereik liggen van wat de drie schakelaars hierboven aanraken. Daarom kan een scanpakket er maar een paar procent kleiner uit komen, terwijl een tekstzware PDF van vergelijkbare omvang merkbaar meer wint.
Het omgekeerde pad is PDF decomprimeren, dat streams uitvouwt voor inspectie (--qdf, object streams uitgeschakeld) en het uiterlijk van de pagina's evenmin verandert.
Wanneer een ander pad de juiste keuze is
| Wat u nodig hebt | Het pad dat u moet nemen |
|---|---|
| Identiek uiterlijk, alleen de verpakkingskosten weg | Comprimeren |
| Een scanpakket dat echt te groot is en kwaliteitsverlies acceptabel is | Downsampling of lossy hercodering, niet deze Compress |
| Nog steeds bewerkbaar, maar het volgende teken typt niet | Andere exportinstellingen of bronbestand, zie font-subsetting |
| De browser moet pagina Ă©Ă©n eerder zien | Linearisatie lost de eerste weergave op, niet de grootte |
| Het bestand gaat helemaal niet open | Repareren, een structureel probleem en geen grootteprobleem |
Een valkuil zit in die laatste rij: PDF lineariseren is hier geen aparte implementatie maar een alias van Compress. Beide wijzen naar dezelfde operatie, de canonieke id is misc/compress-pdf met linearize-pdf als alias, de portal stuurt voor dat hulpmiddel altijd linearize=true en optimizeLevel=1, de server leest geen van beide velden, en qpdf krijgt nooit --linearize mee. De operatie die een bestand wél lineariseert is Beveiligen, wanneer het versleutelt.
Wilt u dus hetzelfde uiterlijk in een kleiner bestand, dan is Comprimeren het hele antwoord. Wilt u lossy beeldverkleining of font-subsetting, dan is dit pad de verkeerde knop. Het bestand komt direct terug, zonder account. Waar objecten, streams en de kruisverwijzingstabel werkelijk staan, leest u verder in Wat er in een PDF zit.