Test kompresji PDF: metoda, rozmiar pliku i funkcje

Co przetestowano, a czego nie?

Przetestowano ten sam, niezmieniony kod kompresji, którego używa kompresor PDF na tej stronie. Na potrzeby pomiaru nie uruchomiono go jednak w przeglądarce, lecz wywołano bezpośrednio w Node.js. Pozwala to dokładnie zapisać dane wejściowe, ustawienia i zapisany wynik każdego przebiegu.

• Moduł kompresji: QPDF 12.2.0 jako WebAssembly, wersja wrappera 0.3.0. Skrypt budowania wrappera określa QPDF 12.2.0, a zainstalowany moduł po sprawdzeniu również zgłasza wersję 12.2.0.
• Środowisko: Node.js 24.18.1 w systemie Windows 11, kompilacja 26200, x64.
• Zakres: trzy syntetyczne pliki wejściowe, dziewięć przebiegów kompresji oraz plik testowy z atrapą podpisu, który powinien zostać odrzucony.
• Weryfikacja: dwanaście zapisanych plików PDF o łącznej liczbie 24 stron; dla każdego sprawdzono strukturę i wyrenderowany widok stron.

Ten pomiar nie obejmuje:

• czasu przetwarzania; nie mierzono czasu,
• działania w poszczególnych przeglądarkach ani na rzeczywistych smartfonach i tabletach,
• rzeczywistych zdjęć, skanów, dużych plików ani dokumentów użytkowników,
• innych programów do kompresji ani usług internetowych,
• średniej oszczędności, jakiej można oczekiwać dla własnego pliku.

Pliki testowe, ustawienia i pliki do pobrania

W teście wykorzystano wyłącznie samodzielnie utworzone pliki PDF. Nie ma wśród nich dokumentów klientów, zdjęć ze świata rzeczywistego ani podpisów prawdziwych osób. Obraz w pliku z obrazem również został wygenerowany: przedstawia teksturę z gradientem kolorów i nie jest ani zdjęciem, ani skanem.

• Plik z tekstem, 3029 bajtów: dwie strony z tekstem, wypełnionym polem formularza, linkiem, obrotem strony oraz znacznikiem w drzewie struktury.
• Plik z obrazem, 1 359 079 bajtów: te same elementy, a dodatkowo wygenerowany obraz o wymiarach 640 × 800 pikseli. Plik z tekstem bez obrazu ma tylko 3029 bajtów, więc większość rozmiaru tego pliku przypada na obraz.
• Już zoptymalizowany plik z tekstem, 2721 bajtów: służy jako przykład sytuacji, w której nie da się już nic zaoszczędzić.
• Plik z atrapą podpisu, 3139 bajtów: zawiera jedynie strukturę podpisu, ale nie prawdziwy podpis cyfrowy. Służy do sprawdzenia, czy kompresor odrzuca podpisane pliki.

Taki sam punkt wyjścia dla każdego przebiegu

• Każdy przebieg rozpoczyna się od niezmienionych bajtów oryginału. Jeśli przebieg wymaga kilku prób, każda kolejna próba również zaczyna się od oryginału, a nie od poprzedniego wyniku.
• Wszystkie wyniki zawierają obie kompletne strony. Nie usuwano stron, niczego nie pakowano do ZIP, nie zmniejszano liczby pikseli obrazów ani nie zamieniano całych stron w obrazy. Tylko dzięki temu liczby bajtów uzyskane w poszczególnych trybach są ze sobą porównywalne.
• Każdy wynik zapisano pod osobną nazwą pliku. Dla pliku wejściowego i wyjściowego zapisano liczbę bajtów oraz sumę kontrolną SHA-256. Suma kontrolna jest odciskiem palca pliku: zmiana choćby jednego bajtu zmienia sumę kontrolną.
• Dla każdego przebiegu zapisano tryb, ewentualny docelowy rozmiar oraz faktycznie zastosowaną jakość JPEG.

Jak technicznie działają trzy tryby

W protokole i tabelach tryby noszą nazwy lossless, balanced i small. W narzędziu znajdziesz je pod następującymi nazwami: lossless to Optymalizacja bezstratna, balanced to Zrównoważona, a small to Mniejszy plik. Optymalizacja bezstratna optymalizuje wyłącznie strukturę pliku, czyli obiekty i skompresowane strumienie danych. Tryb Zrównoważona dodatkowo ponownie koduje odpowiednie obrazy jako JPEG z poziomem jakości 80. Jeśli docelowy rozmiar nie zostanie osiągnięty, następuje próba z poziomem 70. Tryb Mniejszy plik zaczyna od poziomu 65, a jeśli nie osiągnie celu, przechodzi do 50, a następnie do 40. Jeśli podasz docelowy rozmiar, a już oryginał lub wersja ze zoptymalizowaną strukturą spełnia ten cel, próba stratnego kodowania JPEG nie jest potrzebna. Na końcu wybierana jest najmniejsza ze sprawdzonych wersji. Jeśli żadna nie jest mniejsza od oryginału, zachowany zostaje oryginał. Nie gwarantuje to określonej oszczędności.

Zgodnie z dokumentacją QPDF 12.2 QPDF nie zmniejsza przy tym rozdzielczości obrazów. Ponowne kodowanie JPEG może jednak powodować widoczne artefakty, a QPDF przyjmuje ponownie zakodowane dane obrazu tylko wtedy, gdy są mniejsze. Znaczenie tego dla jakości obrazu wyjaśnia poradnik Kompresja PDF bez utraty jakości.

Pliki i sumy kontrolne do samodzielnej weryfikacji

Poniższa tabela zawiera linki do wszystkich plików testowych i wynikowych. Po pobraniu porównaj sumę kontrolną SHA-256 za pomocą wybranego narzędzia do obliczania sum kontrolnych. Jeśli się zgadza, masz dokładnie ten plik, którego dotyczył pomiar. Anglojęzyczny protokół reproducibility-manifest.json zawiera dokładne wywołania i ustawienia wszystkich przebiegów.

Wyniki: rozmiar pliku przedstawiony rzetelnie

Na podstawie tego testu nie można przewidzieć, o ile zmniejszy się Twój plik PDF. Zależy to od jego zawartości. Już trzy pliki testowe pokazują rozpiętość wyników: mały plik z tekstem zmniejszył się w trybie lossless o 10,17 procent, a plik z obrazem w tym samym trybie tylko o 0,02 procent. Dopiero ponowne kodowanie JPEG przyniosło w przypadku pliku z obrazem oszczędność 86,78 procent. Tabela zawiera wszystkie dziewięć przebiegów, również te bez znaczącej oszczędności.

Oszczędność zawsze oblicza się na podstawie rzeczywistej liczby bajtów: liczbę zaoszczędzonych bajtów dzieli się przez rozmiar oryginału. W przebiegu z balanced jest to 1 179 371 z 1 359 079 bajtów, czyli 86,78 procent. Dla własnego pliku możesz to obliczyć za pomocą kalkulatora stopnia kompresji.

Jakość JPEG nie oznacza procentowej oszczędności

Wartości 80, 65 lub 40 to ustawienia kodera JPEG, a nie procentowe zmniejszenie rozmiaru. Poziom jakości 80 pozwolił tutaj zaoszczędzić 86,78 procent, a poziom 65 — 90,75 procent. W przypadku innego pliku te same poziomy mogą dać zupełnie inne wyniki.

Dlaczego uwzględniono przypadek bez oszczędności

Test pokazujący wyłącznie największą oszczędność pomija ważny przypadek: co się dzieje, gdy nie da się już nic zaoszczędzić? Dla już zoptymalizowanego pliku z tekstem o rozmiarze 2721 bajtów tryb lossless nie uzyskał mniejszej wersji. Kompresor zachował więc oryginał: plik wyjściowy ma 2721 bajtów, oszczędność wynosi 0 bajtów, a plik wejściowy i wyjściowy mają tę samą sumę kontrolną SHA-256. W ten sposób przy użyciu rzeczywistego modułu kompresji wykazano, że w takim przypadku nie otrzymasz ponownie zapisanego pliku bez żadnej korzyści. To, co możesz wtedy zrobić, opisuje poradnik Rozmiar PDF się nie zmniejsza.

Docelowy rozmiar osiągnięty, nieosiągnięty lub osiągnięty już wcześniej

• Cel 250 000 bajtów: już pierwsza próba z poziomem 65 dała 125 710 bajtów. Cel został zatem osiągnięty, a wynik jest nawet identyczny co do bajtu z wynikiem przebiegu bez celu.
• Cel 128 bajtów: dla dwóch stron z obrazem jest to nierealistycznie mały rozmiar. Nawet ostatni poziom 40 pozwolił uzyskać jedynie 74 707 bajtów. Kompresor zgłasza nieosiągnięcie celu, a mimo to dostarcza plik. W przypadku tego pliku testowego zapisany plik wynikowy o rozmiarze 74 707 bajtów zawiera obie strony i przeszedł opisane poniżej testy funkcji. Dane obrazu zostały przy tym ponownie zakodowane stratnie. Ten przebieg nie dowodzi, że w każdym innym pliku zostanie zachowana cała zawartość.
• Cel 1 359 079 bajtów, czyli dokładnie rozmiar oryginału: cel uznano za już osiągnięty. Wykonano jedynie bezstratną optymalizację struktury. Dała ona 1 358 764 bajty, czyli tyle samo, ile uzyskano w przebiegu z lossless. Obraz nie został ponownie zakodowany jako JPEG, ponieważ zapisane wywołania nie zawierają ustawienia JPEG.

Ten sam rozmiar, inna suma kontrolna

Powtórzenie przebiegu z balanced ponownie dało dokładnie 179 708 bajtów, ale inną sumę kontrolną SHA-256. Również wynik przebiegu z już spełnionym celem ma taki sam rozmiar jak wynik przebiegu z lossless, a mimo to inną sumę kontrolną. Jednym z możliwych powodów jest to, że podczas zapisywania pliku PDF może na przykład powstać nowy identyfikator dokumentu. Natomiast przebiegi z small bez celu i z celem 250 000 bajtów dały wyniki zgodne co do bajtu. Suma kontrolna identyfikuje więc konkretny zapisany plik. Jeśli powtórzysz przebieg, również w przeglądarce, niekoniecznie otrzymasz plik identyczny co do bajtu, nawet jeśli jego rozmiar pozostanie taki sam.

Wygląd i funkcje sprawdzono oddzielnie

Mniejszy plik nie mówi jeszcze nic o tym, czy zachowały się tekst, formularz i link. Dobry podgląd również tego nie dowodzi. Dlatego zapisane pliki sprawdzono za pomocą dwóch niezależnych od siebie bibliotek: pdf-lib odczytuje zapisaną strukturę wewnętrzną, a PDF.js 6.4.299 renderuje strony oraz odczytuje tekst i adnotacje. W tym celu PDF.js działał w odizolowanej instancji Chromium w wersji 151.0.7922.34. To sprawdzenie gotowych plików jest oddzielone od kompresji, której pomiar przeprowadzono w Node.js w systemie Windows 11. Nie mierzono kompresji w przeglądarce ani na urządzeniach mobilnych, a test nie mówi nic o działaniu innych programów do obsługi PDF. Każdy test ma własną metodę i dotyczy wyłącznie tych plików testowych.

Szczegół dotyczący pola formularza: jego wartość nie zawsze pojawia się przy zwykłym wyodrębnianiu tekstu przez PDF.js, dlatego odczytano ją z adnotacji. Jeśli szukasz wpisanej wartości formularza w skompresowanym pliku PDF i jej nie znajdujesz, nie oznacza to więc automatycznie, że jej brakuje.

W trybach balanced i small obraz został ponownie zakodowany stratnie jako JPEG, z wyjątkiem przebiegu small z już wcześniej spełnionym celem. Zdekodowane instrukcje zawartości dotyczące tekstu i linii pozostały przy tym takie same, ale dane obrazu tekstury już nie. Na wyrenderowanych stronach wyników uzyskanych z pliku z obrazem położenie i wymiary obrazu oraz obrót strony pozostały takie jak w oryginale. Ważna informacja, jeśli samodzielnie oglądasz pliki: już w oryginale wygenerowany obraz zasłania kilka wierszy tekstu. To nakładanie się elementów jest częścią pliku testowego, a nie uszkodzeniem spowodowanym kompresją. Pozostaje ono w wynikach. Nie wynika z tego ocena czytelności każdego wiersza ani ocena jakości. Wygenerowany obraz z teksturą i gradientem kolorów niewiele też mówi o tym, jak zdjęcia, skany lub drobny tekst na skanach zareagują na ten sam poziom jakości. Z tym tematem wiąże się poradnik Zmniejsz zeskanowany PDF.

Atrapa podpisu pokazuje jedynie, że kompresor rozpoznaje plik ze strukturą podpisu i go nie przetwarza. Zgodnie z kodem kompresji odrzucane są także pliki zaszyfrowane i certyfikowane. Ten test nie sprawdza, czy prawdziwy podpis jest ważny, ani nie omija żadnych zabezpieczeń. Więcej na ten temat w poradniku Kompresja PDF z podpisami i formularzami.

Ograniczenia i samodzielna weryfikacja

Czy narzędzie jest lepsze od PDF24 lub Adobe?

Ta strona nie odpowiada na to pytanie. Nie uruchamialiśmy innych programów ani usług internetowych z tymi samymi plikami. Ocena porównawcza jakości, szybkości lub ceny nie byłaby więc poparta dowodami. Rankingi z wartościami procentowymi lub suwakami również nie zastępują takiego porównania. Rzetelne porównanie wymaga tego samego kompletnego pliku wejściowego, tych samych stron, zapisanych ustawień, dokładnej liczby bajtów oraz tych samych testów funkcji dla wszystkich wyników.

Jak sprawdzić własny plik PDF

1. Zachowaj niezmienioną kopię oryginału.
2. Otwórz kompresor PDF i wybierz plik. Jeśli ważne są szczegóły obrazu, zacznij od trybu bezstratnego.
3. Zapisz dokładny rozmiar oryginału i wyniku w bajtach, na przykład z właściwości pliku, i oblicz oszczędność za pomocą kalkulatora stopnia kompresji.
4. Każdą kolejną próbę zaczynaj od oryginału, a nie od już skompresowanego pliku. Zapisuj każdy wynik pod nową nazwą pliku, aby niczego nie nadpisać.
5. Otwórz zapisany plik w programie, z którego korzysta również odbiorca. Sprawdź wszystkie strony, wyszukaj znane ci słowo, sprawdź wartości pól formularza i linki oraz obejrzyj obrazy i drobny tekst w rzeczywistym rozmiarze.
6. Jeśli twój plik PDF jest podpisany cyfrowo, zaszyfrowany lub certyfikowany, nie kompresuj go za pomocą tego narzędzia. Ustal sposób postępowania z wystawcą dokumentu.