Varför blev min PDF knappt mindre?
Jag körde min PDF genom en komprimerare och den gick från 4,1 MB till 4,0 MB. Är verktyget trasigt?
En PDF är ett arkivskåp
Den mentala bild som orsakar besvikelsen är att se en PDF som en bild av ett dokument. Det är den inte. En PDF är, enligt definitionen i ISO 32000, en behållare med numrerade objekt: sidträd, innehållsströmmar fulla av ritoperatorer, inbäddade teckensnittsprogram, bild-XObject, formulärfält, annoteringar, dokumentöversikter och en korsreferenstabell som anger var varje objekt börjar.
De flesta av objekten är redan komprimerade. Innehållsströmmar är oftast Flate-kodade, vilket är samma algoritm som en ZIP-fil använder. Inbäddade fotografier lagras vanligtvis som DCT-strömmar, alltså JPEG-data som skickats vidare oförändrad. När en generell komprimerare tittar på en PDF tittar den alltså på en låda med saker som var och en redan har komprimerats en gång.
Ta reda på var byten finns innan du komprimerar något
Den enskilt mest användbara diagnosen är att veta vilken sorts dokument du har, eftersom den förutsäger resultatet nästan helt.
| Dokumenttyp | Var byten finns | Vad en strukturell omskrivning kan göra |
|---|---|---|
| Textrapport från en ordbehandlare | Inbäddade teckensnittsprogram och små innehållsströmmar | Mycket lite; innehållet är redan kompakt |
| Inskannade sidor | En stor bild per sida | Nästan ingenting utan att röra bilderna |
| Presentationsexport | Inbäddade fotografier och gradienter | En del, om samma bilder förekommer på flera sidor |
| Teknisk ritning | Långa vektorbaserade innehållsströmmar | En del, genom att koda om strömmar och ta bort oanvända objekt |
| Formulär med bilagor | Inbäddade filer, JavaScript, annoteringsordlistor | Mycket, om extramaterialet går att ta bort |
Vad en strukturell omskrivning faktiskt tar bort
En strukturell omskrivning sparar om dokumentet utan att ändra hur någon sida ser ut. Den kan slänga objekt som ingenting längre refererar till, och sådana samlas varje gång ett dokument redigeras och sparas inkrementellt. Den kan komprimera korsreferenstabellen och packa små objekt i objektströmmar. Den kan slänga dokumentmetadata, miniatyrbilder och den redigeringshistorik som vissa program lämnar efter sig.
På ett dokument som har redigerats och sparats om många gånger kan det ge en stor vinst. På ett dokument som exporterats rent, en enda gång, från en ordbehandlare finns ingenting att samla in: filen är redan nära sin minsta form, och hundra kilobyte bort från fyra megabyte är precis det resultat man ska vänta sig.
Varför ett textdokument gör motstånd
I en text-PDF består en stor del av filen oftast av inbäddade teckensnitt. Ett teckensnittsprogram är en kompakt binärfil med glyfkonturer och hintningsinstruktioner, och det finns där för att dokumentet måste renderas identiskt på en maskin som inte har typsnittet installerat. Du kan inte komprimera bort det utan att antingen begränsa teckenurvalet ytterligare eller ta bort det, och att ta bort det ändrar hur sidan ser ut.
Själva texten är pytteliten. Hundra sidor prosa är några hundra kilobyte tecken före komprimering. Om din text-PDF är stor, titta på teckensnitten och på eventuella bilder som gömmer sig bakom texten — en logotyp som upprepas i ett sidhuvud, en vattenstämpel i bakgrunden — snarare än på orden.
Varför en skanning faller ihop
En inskannad sida är ett stort fotografi av ett pappersark, ofta taget i 300 punkter per tum eller mer. En A4-sida i 300 DPI är ungefär 2480 × 3508 pixlar — nästan nio miljoner av dem, för en sida vars informationsinnehåll är några kilobyte text. Det är därför skanningar svarar så dramatiskt på rastrerad komprimering: att sänka renderingsupplösningen och koda om sidbilderna angriper den del av filen som faktiskt är stor.
Det är också därför det läget är destruktivt. När en sida väl är en bild är det sökbara textlagret, länkarna, formulärfälten, annoteringarna, den taggade tillgänglighetsstrukturen och en eventuell digital signatur borta. FileSlimmer behandlar rastrering som ett separat, tydligt märkt läge med den varningen bifogad, i stället för som en tyst reservlösning när den strukturella omskrivningen gör dig besviken.
Varför ingen kan lova dig en siffra
En målstorlek för en PDF är en sökning över renderingsupplösning och bildkvalitet, och sökningen har ett golv: under en viss upplösning slutar texten i en skanning att vara läsbar. Om ett visst dokument når en viss budget ovanför det golvet beror på sidantalet, färgtäckningen, mängden fotografiskt innehåll och skannerns brus. Två dokument med samma sidantal kan hamna på mycket olika storlekar.
Det ärliga beteendet är att stanna vid golvet och rapportera var sökningen stannade, vilket är vad FileSlimmers förinställda PDF-mål gör. Ett verktyg som alltid träffar siffran du skrev in ljuger antingen om siffran eller förstör dokumentet för att nå den.
Innan du skyller på verktyget
- Kontrollera om PDF:en är en skanning. Försök markera en textrad: om markören inte kan markera något är varje sida en bild.
- Jämför sidantalet med storleken. En fil på 40 MB med tre sidor är bildtung; en fil på 40 MB med 900 sidor kan vara helt rimlig.
- Kontrollera om dokumentet är krypterat. En lösenordsskyddad PDF går inte att strukturera om alls förrän den är upplåst.
- Kontrollera om det är signerat. Att skriva om ett signerat dokument ogiltigförklarar signaturen, och det är oftast ett sämre utfall än en stor fil.
- Kontrollera vad du faktiskt behöver. Att plocka ut de sex sidor du måste skicka slår ofta att komprimera alla nittio.
Verktyg för det här
Källor
- ISO 32000-2 — Document management, Portable Document Format
- Adobe — PDF 32000-1:2008, the freely published PDF 1.7 specification
- PDF Association — ISO 32000 and the PDF standards family