Co naprawdę dzieje się, gdy kompresujesz PDF
Compress w PDF123 wykonuje rekompresję strumieni i pakowanie obiektów w qpdf, nie zmniejsza rozdzielczości obrazów, nie przekodowuje bitmap do JPEG-a o niższej jakości ani nie zawęża zestawu fontów. Linearyzacja prawie nie zmienia rozmiaru pliku.
Dwa pliki PDF mogą wyglądać na ekranie identycznie, a różnić się o trzy rzędy wielkości: 50 KB i 50 MB. Ta różnica prawie nigdy nie siedzi w operatorach tekstu. W dwudziestostronicowej umowie zajmują one zwykle kilkadziesiąt kilobajtów; cała reszta to próbki obrazu, w pełni osadzony program fontu oraz to, jak ciasno upakowano strumienie i obiekty.
Ma to konsekwencję, którą warto wypowiedzieć od razu: „kompresja PDF” to nie jedna czynność, lecz cztery. Zmniejszają różne rzeczy i mają różną cenę, a traktowanie ich jak jednej czynności daje sprzeczne doświadczenia: plik został skompresowany, ale się nie zmniejszył, albo się zmniejszył, ale strony straciły ostrość.
Skąd bierze się rozmiar
Większość przypadków „dlaczego ten PDF jest taki duży?” zaczyna się od skanu lub zdjęcia w wysokiej rozdzielczości, wciąż osadzonych w rozmiarze, w jakim powstały. Rachunek warto wykonać raz: strona w formacie Letter o wymiarach 8,5 × 11 cala przy 300 DPI to około 2550 × 3300 pikseli, a przy trzech bajtach na piksel daje to nieskompresowane mniej więcej 25 MB. Dwadzieścia takich stron często sięga 60 do 80 MB, zanim ktokolwiek dotknie kompresji.
Drugim źródłem są fonty. PDF może osadzić cały program fontu, aby każda maszyna renderowała tekst identycznie, a ten koszt rozlicza się rozmiarem tablic glifów, a nie ilością faktycznie czytanego tekstu. Dlatego zawężanie zestawu fontów to osobna dźwignia rozmiaru.
Trzecim jest samo pakowanie. Ta sama treść może być zapisana z marnotrawnymi ustawieniami kompresji albo jej obiekty mogą leżeć rozrzucone po pliku, każdy z własną księgowością. Nic z tego nie zmienia ani jednego piksela czy glifu, i właśnie po tę część sięga rekompresja strumieni.
Za „kompresją” stoją cztery różne dźwignie
Na rozmiar działają cztery dźwignie. Działają na różnych warstwach, a ich koszty prawie się nie pokrywają. Wybór niewłaściwej to najczęstsza przyczyna tego, że uruchomienie kompresji wygląda, jakby nic nie robiło.
| Dźwignia | Czego dotyczy | Zysk rozmiaru | Koszt |
|---|---|---|---|
| Rekompresja strumieni i strumienie obiektów | Jak kompresowane są strumienie treści, jak przechowywane i pakowane są obiekty | Zależy od tego, jak luźny był plik źródłowy | Wygląd stron bez zmian |
| Zmniejszanie rozdzielczości obrazów | Liczba pikseli, czyli rozdzielczość | Duży | Rozdzielczość trwale obniżona |
| Stratne przekodowanie obrazów | Reprezentacja bajtowa bitmapy | Duży | Jakość obrazu obniżona |
| Zawężanie zestawu fontów | Osadzone tablice glifów | Umiarkowany | Nieużywane glify przestają być edytowalne |
| Linearyzacja | Kolejność obiektów | Prawie zerowy | W zamian kupuje czas wczytywania pierwszej strony |
Pierwsze cztery wiersze bywają ogólnie nazywane „kompresją”, ale tylko pierwszy nie rusza treści. To także wiersz, którego zysk najłatwiej ocenić błędnie: skan, którego rozmiar to głównie surowe próbki obrazu, ma niewiele redundancji do usunięcia, a dźwignie, które naprawdę by go zmniejszyły, to zmniejszanie rozdzielczości i stratne przekodowanie, za cenę utraty tej rozdzielczości i jakości na stałe.
Którą z czterech dźwigni pociąga Compress w PDF123
Skompresuj PDF (POST /api/v1/misc/compress-pdf) wykonuje tylko pierwszy wiersz. Uruchamia qpdf z kompresją nieskompresowanych strumieni (--compress-streams=y), drugim przebiegiem po strumieniach już skompresowanych przez Flate (--recompress-flate) oraz pakowaniem obiektów do strumieni obiektów (--object-streams=generate).
Nie zmniejsza rozdzielczości obrazów, nie przekodowuje bitmap do JPEG-a o niższej jakości ani nie zawęża zestawu fontów. Strony powinny wyglądać tak samo, a oszczędność pochodzi z rekompresji Flate i pakowania strumieni obiektów.
Warunek porażki zasługuje na taką samą jasność. Gdy rozmiar pliku to głównie dane obrazu już skompresowane jako JPEG, Flate nie ma czego ściskać, bo te bajty obrazu leżą poza zasięgiem trzech powyższych przełączników. Dlatego paczka skanów może wrócić mniejsza tylko o kilka procent, podczas gdy PDF z przewagą tekstu o podobnym rozmiarze zyskuje zauważalnie więcej.
Ścieżka odwrotna to Dekompresuj PDF, które rozwija strumienie do wglądu (--qdf, strumienie obiektów wyłączone) i również nie zmienia wyglądu stron.
Kiedy wybrać inną ścieżkę
| Czego potrzebujesz | Ścieżka, której użyć |
|---|---|
| Identyczny wygląd, tylko usunąć narzut pakowania | Skompresuj |
| Paczka skanów naprawdę za duża, a utrata jakości jest do przyjęcia | Zmniejszanie rozdzielczości albo stratne przekodowanie, nie ten Compress |
| Ma pozostać edytowalne, ale następny znak się nie wpisuje | Inne ustawienia eksportu albo plik źródłowy, zobacz zawężanie zestawu fontów |
| Przeglądarka ma zobaczyć pierwszą stronę wcześniej | Linearyzacja rozwiązuje pierwsze malowanie, nie rozmiar |
| Plik w ogóle się nie otwiera | Napraw, problem strukturalny, a nie rozmiarowy |
W ostatnim wierszu czai się pułapka: Linearyzuj PDF nie jest tu osobną implementacją, lecz aliasem Compress. Oba wskazują na tę samą operację, kanoniczny identyfikator to misc/compress-pdf z linearize-pdf jako aliasem, portal dla tego narzędzia zawsze wysyła linearize=true i optimizeLevel=1, serwer nie odczytuje żadnego z tych pól, a qpdf nigdy nie otrzymuje --linearize. Operacją, która faktycznie linearyzuje plik, jest Chroń, gdy szyfruje.
Jeśli więc chcesz ten sam wygląd w mniejszym pliku, Skompresuj to cała odpowiedź. Jeśli chcesz stratnego zmniejszenia obrazów albo zawężenia zestawu fontów, ta ścieżka to niewłaściwa dźwignia. Plik wraca bezpośrednio, bez konta. A gdzie naprawdę leżą obiekty, strumienie i tablica odsyłaczy, przeczytasz dalej w Co siedzi w PDF.