Vad som faktiskt händer när du komprimerar en PDF
PDF123 Komprimera utför qpdf-omkomprimering av strömmar och packning i objektströmmar, inte nedsampling av bilder, förstörande JPEG-omkodning eller teckensnittssubsetting. Lineariseringen ändrar filstorleken knappt.
Två PDF-filer kan se identiska ut på skärmen och ändå skilja sig med tre storleksordningar: 50 KB mot 50 MB. Skillnaden sitter nästan aldrig i textoperatorerna. I ett avtal på tjugo sidor är de oftast några tiotal kilobyte; allt annat är bildsamplar, ett fullständigt inbäddat teckensnittsprogram och hur tätt strömmar och objekt är packade.
Det får en konsekvens som är värd att säga tidigt: ”komprimera en PDF” är inte en åtgärd utan fyra. De krymper olika saker och tar olika betalt, och den som behandlar dem som en enda får motsägelsefulla erfarenheter: filen komprimerades men blev inte mindre, eller den blev mindre men sidorna tappade skärpa.
Var storleken kommer ifrån
De flesta fall av ”varför är den här PDF:en så stor?” börjar med en högupplöst skanning eller ett foto som fortfarande är inbäddat i sin inspelningsstorlek. Räkningen är värd att göra en gång: en sida i Letter-format på 8,5 × 11 tum vid 300 DPI är ungefär 2550 × 3300 pixlar, och med tre byte per pixel är det okomprimerat runt 25 MB. Tjugo sådana sidor landar ofta på 60 till 80 MB innan någon rör komprimeringen.
Den andra källan är teckensnitt. En PDF kan bädda in ett komplett teckensnittsprogram så att varje maskin återger texten identiskt, och den kostnaden mäts i storleken på glyftabellerna, inte i hur mycket text som faktiskt läses. Det är därför teckensnittssubsetting är en egen storleksspak.
Den tredje källan är packningen i sig. Samma innehåll kan vara lagrat med slösaktiga komprimeringsinställningar, eller så kan objekten ligga utspridda i filen, var och en med sin egen bokföring. Inget av det ändrar en enda pixel eller glyf, och det är precis den delen som omkomprimering av strömmar kan komma åt.
Bakom ”komprimera” ligger fyra olika spakar
Det finns fyra spakar som påverkar storleken. De verkar på olika lager och deras kostnader överlappar knappt. Att välja fel är den vanligaste orsaken till att en komprimeringskörning verkar göra ingenting.
| Spak | Vad den rör | Storlekvinst | Kostnad |
|---|---|---|---|
| Omkomprimering av strömmar och objektströmmar | Hur innehållsströmmar komprimeras, hur objekt lagras och packas | Beror på hur löst originalfilen var packad | Sidornas utseende oförändrat |
| Nedsampling av bilder | Antalet pixlar, det vill säga upplösningen | Stor | Upplösningen sänks permanent |
| Förstörande omkodning av bilder | Bitmappens byte-representation | Stor | Bildkvaliteten sänks |
| Teckensnittssubsetting | De inbäddade glyftabellerna | Måttlig | Glyfer som inte används går inte längre att redigera |
| Linearisering | Ordningen på objekten | Nästan noll | Köper i stället laddningstiden för första sidan |
De fyra första raderna kallas alla löst för ”komprimering”, men bara den första lämnar innehållet i fred. Det är också den rad vars utbyte är lättast att bedöma fel: en skanning vars storlek mest består av råa bildsamplar har lite redundans för den att ta bort, och de spakar som skulle krympa den rejält är nedsampling och förstörande omkodning, till priset av att den upplösningen och kvaliteten försvinner för gott.
Vilken av de fyra spakarna PDF123 Komprimera drar i
Komprimera en PDF (POST /api/v1/misc/compress-pdf) gör bara den första raden. Den kör qpdf med komprimering av okomprimerade strömmar (--compress-streams=y), en andra omgång över strömmar som redan komprimerats med Flate (--recompress-flate) och packning av objekt i objektströmmar (--object-streams=generate).
Den samplar inte om bilder, kodar inte om bitmappar till lägre JPEG-kvalitet och subsettar inga teckensnitt. Sidorna bör se likadana ut, och besparingen kommer från Flate-omkomprimering och packning i objektströmmar.
Felfallet förtjänar samma tydlighet. När en fils storlek mest består av bilddata som redan komprimerats som JPEG har Flate inget kvar att pressa, eftersom de bildbytena ligger utanför vad de tre omkopplarna ovan rör. Därför kan ett skanningspaket komma tillbaka bara några procent mindre, medan en texttung PDF av liknande storlek vinner märkbart mer.
Den omvända vägen är Dekomprimera PDF, som expanderar strömmar för inspektion (--qdf, objektströmmar avstängda) och inte heller ändrar hur sidorna ser ut.
När en annan väg är den rätta
| Det du behöver | Vägen du ska ta |
|---|---|
| Identiskt utseende, bara bli av med packningskostnaden | Komprimera |
| Ett skanningspaket som är genuint för stort och kvalitetsförlust är acceptabel | Nedsampling eller förstörande omkodning, inte denna Komprimera |
| Fortsatt redigerbart, men nästa tecken går inte att skriva | Andra exportinställningar eller källfil, se teckensnittssubsetting |
| Webbläsaren ska se första sidan tidigare | Linearisering löser första målningen, inte storleken |
| Filen går inte att öppna alls | Reparera, ett strukturellt problem och inte ett storleksproblem |
En fälla ligger i den sista raden: Linearisera PDF är ingen egen implementation här utan ett alias för Komprimera. Båda pekar på samma operation, det kanoniska id:t är misc/compress-pdf med linearize-pdf som alias, portalen skickar alltid linearize=true och optimizeLevel=1 för det verktyget, servern läser inget av fälten, och qpdf får aldrig --linearize. Den operation som faktiskt lineariserar en fil är Skydda, när den krypterar.
Om du alltså vill ha samma utseende i en mindre fil är Komprimera hela svaret. Vill du ha förstörande bildkomprimering eller teckensnittssubsetting är den här vägen fel spak. Filen kommer tillbaka direkt, utan konto. Var objekt, strömmar och korstabellen faktiskt ligger fortsätter du med Vad som finns inuti en PDF.