Seberapa besar penghematan kompresi PDF lossless, diukur pada sebelas file

Setiap kompresor PDF menawarkan opsi lossless, dan hampir tidak ada yang menyebutkan seberapa besar manfaatnya. Kami mengukur milik kami sendiri.

Dua istilah, definisinya

Kompresi struktural adalah menulis ulang cara PDF menyimpan objek-objeknya, yaitu tabel referensi silang, pengemasan objek-objek kecil ke dalam stream, dan filter kompresi pada setiap stream, tanpa mengubah satu glyph atau piksel pun. Inilah satu-satunya jenis kompresi yang secara jujur bisa disebut lossless.

Object stream adalah fitur PDF 1.5 yang mengemas banyak objek kecil (kamus halaman, deskriptor font, anotasi) ke dalam satu stream terkompresi, alih-alih menulis masing-masing tanpa kompresi. Dari sinilah hampir seluruh penghematan struktural berasal, dan karena itulah program pembuat file sudah menentukan hasilnya sebelum kompresor dijalankan.

Pengukurannya

Kami membuat sebelas PDF pada 1 Oktober 2026: dua puluh halaman teks yang sama, dicetak oleh Chromium 153 (pembuat Skia/PDF m153), oleh macOS Quartz melalui cupsfilter, oleh jsPDF 4.2.1, dan oleh pdf-lib dengan dan tanpa object stream; sepuluh foto berukuran 1600 piksel yang disematkan oleh Chromium dan oleh pdf-lib; lima halaman bergaya hasil scan, masing-masing berupa JPEG grayscale satu halaman penuh dengan kualitas 55; dokumen satu baris satu halaman; dokumen yang lima dari sepuluh halamannya sudah dihapus; dan file terenkripsi AES-256. Masing-masing diproses melalui compressStructural di src/lib/pdf/ops.ts, kode yang persis sama di balik pengaturan lossless kompresor kami, di Node 24 dengan @cantoo/pdf-lib 2.11.1.

File	Pembuat	Sebelum	Sesudah	Penghematan
20 halaman teks	Cetak Chromium	82 109 B	81 426 B	0.8%
20 halaman teks	macOS Quartz	48 441 B	45 278 B	6.5%
20 halaman teks	jsPDF 4.2.1	72 814 B	69 977 B	3.9%
20 halaman teks	pdf-lib, tanpa object stream	34 041 B	33 168 B	2.6%
20 halaman teks	pdf-lib, dengan object stream	33 166 B	33 173 B	−0.02%
10 foto	Cetak Chromium	1 528 699 B	1 528 112 B	0.04%
10 foto	pdf-lib	1 509 614 B	1 508 973 B	0.04%
5 halaman hasil scan	pdf-lib	1 816 323 B	1 815 924 B	0.02%
1 baris, 1 halaman	pdf-lib	1 307 B	1 059 B	19.0%
10 halaman, 5 dihapus	pdf-lib	13 900 B	13 441 B	3.3%
Terenkripsi	pdf-lib	2 940 B	ditolak	tidak ada

Membaca tabel

Tidak satu pun dari keempat program pembuat menulis object stream, dan keempatnya menulis tabel referensi silang klasik. Proses ini melakukan hal yang sama pada masing-masing: mengganti tabel dengan cross-reference stream dan mengemas objek-objek kecil, seperti kamus halaman, deskriptor font, dan daftar resource, ke dalam object stream. Jadi, penghematannya dibatasi oleh byte yang sejak awal berada di luar stream. Pada file Chromium, jumlahnya 8 374 dari 82 109 byte, yang turun menjadi 6 896; pada file Quartz, 8 234 dari 48,441, yang turun menjadi 4 224. Quartz menghemat paling banyak karena menulis 71 objek untuk dua puluh halaman, sedangkan Chromium menulis 52, dengan tabel paling bertele-tele di antara keempatnya. File pdf-lib yang sudah memiliki object stream justru kembali 7 byte lebih besar: itulah satu-satunya kasus “file Anda bisa menjadi lebih besar” dalam sampel ini, dan selisihnya hanyalah perbedaan antara dua cara pengemasan objek yang sama baiknya.

File jsPDF menunjukkan batas metode ini paling jelas. jsPDF 4.2.1 secara default menulis content stream-nya tanpa kompresi: 65 255 dari 72 814 byte file itu adalah instruksi menggambar mentah, dan zlib memampatkannya menjadi 19 053. Artinya ada penghematan lossless 63.5% yang tersimpan di dalam file. Proses struktural tidak meng-encode ulang stream yang sudah ada, jadi ia hanya menemukan 3.9% dan membiarkan seluruh 65 255 byte mentah itu di tempatnya. Proses yang men-deflate stream mentah akan sama lossless-nya, karena Flate mengembalikan byte yang persis sama saat di-decode, dan pada pembuat yang satu itu dampaknya enam belas kali lebih besar daripada pengemasan ulang.

Karena itu, pengaturan lossless sekarang melakukannya. Setiap stream yang ditulis tanpa filter akan di-deflate dan hanya disimpan jika hasilnya lebih kecil; stream yang sudah memiliki filter, seperti gambar JPEG, dibiarkan apa adanya, begitu pula metadata XMP, yang menurut spesifikasi harus tetap bisa dibaca oleh alat yang tidak mengurai PDF. Diukur ulang pada dokumen jsPDF dua puluh halaman yang sebanding: 132 980 byte menjadi 18,855, penghematan 85.8%, dengan teks setiap halaman tetap bisa diekstrak dari hasilnya.

Pada file yang didominasi gambar, penghematannya hanya sebesar galat pembulatan, karena byte-nya berada di stream gambar dan proses struktural tidak membukanya. Sepuluh foto sebesar 1.5 MB hanya menghemat 587 byte. Lima hasil scan sebesar 1.8 MB hanya menghemat 399 byte. Angka 19% pada dokumen satu baris berasal dari beberapa ratus byte overhead tabel yang sama, pada file yang begitu kecil sehingga overhead itu menjadi sebagian besar isinya.

Halaman yang dihapus ternyata masih ada

Dokumen yang disunting inilah temuan yang mengubah cara kami mendeskripsikan pengaturan ini. Kami membuat sepuluh halaman, masing-masing dengan penanda unik di teksnya, menghapus lima, lalu menyimpannya. File yang disimpan berukuran 13 900 byte dan masih menyimpan content stream dari kesepuluh halaman: halaman yang dihapus tidak lagi dirujuk, tetapi pdf-lib menulis setiap objek yang pernah diurainya. Proses struktural mengemas ulang file itu menjadi 13 441 byte dengan kesepuluh penanda masih di dalamnya, dan jumlah objeknya naik dari 19 menjadi 21.

Sebaliknya, menyalin kelima halaman yang masih aktif ke dokumen baru menghasilkan 7 518 byte, 46% lebih kecil daripada hasil yang “dikompresi”, dengan penanda 0 hingga 4 saja. Pengemasan ulang mempertahankan objek yatim; pembangunan ulang membuangnya.

Hal itu penting untuk ukuran, dan lebih penting lagi untuk privasi: halaman yang Anda hapus sebelum mengirim file masih bisa diekstrak dari file yang sudah melewati kompresor lossless kami. Lebih buruk lagi, deskripsi pengaturan itu sendiri menyatakan bahwa ia “drops unreferenced ones”. Kenyataannya tidak.

Apa yang kami ubah

Pengaturan lossless sekarang menyalin halaman-halaman yang aktif ke file baru setiap kali aman untuk dilakukan, dan hanya menyimpan hasilnya jika lebih kecil. Hal itu tidak selalu aman: kolom formulir interaktif dan kerangka bookmark adalah milik dokumen, bukan milik halaman tertentu, sehingga pembangunan ulang akan menghapusnya diam-diam. File yang memuat salah satunya hanya dikemas ulang, dan hasilnya menyatakan hal itu, alih-alih menyiratkan bahwa objek yatimnya sudah hilang.

Diukur ulang setelah perubahan pada file sepuluh halaman yang sebanding dengan lima halaman dihapus: pengemasan ulang biasa menghasilkan 12 578 byte dengan kesepuluh penanda masih di dalamnya; proses baru menghasilkan 9 211 byte dengan penanda 0 hingga 4 saja, 27% lebih kecil, dan halaman yang dihapus benar-benar hilang. Sebuah tes di repositori kini membuat file persis seperti ini dan gagal jika isi halaman yang dihapus masih bertahan setelah proses tersebut.

Dibandingkan dengan metode destruktif

Dua pengaturan lain di alat kami merender setiap halaman menjadi JPEG pada 150 atau 110 dpi lalu menyematkannya kembali. Cara itu mengecilkan hasil scan secara drastis, tetapi mengubah dokumen teks menjadi gambar teks, tanpa bisa dipilih, tanpa bisa dicari, dan tanpa apa pun untuk dibaca screen reader. Layanan umum mendapat penghematan besar tanpa pengorbanan itu dengan menjalankan Ghostscript di server untuk menurunkan resolusi gambar sambil membiarkan lapisan teks tetap utuh; Ghostscript berlisensi AGPL-3.0, dan menyertakannya di browser akan membuat seluruh situs ini tunduk pada lisensi tersebut.

Jadi, tawaran yang jujur adalah apa yang ditunjukkan tabel: proses struktural yang akan menemukan beberapa persen penghematan pada file dari program pembuat yang lebih lama dan nihil pada yang modern, atau proses rasterisasi yang mengorbankan lapisan teks. Jika dokumen memiliki kolom formulir atau bookmark dan Anda ingin isi yang dihapus benar-benar hilang, proses lossless tidak akan melakukannya untuk Anda, dan kini alat ini menyatakannya: ekstrak halaman yang ingin Anda simpan ke file baru, yang memang menjadi tugas Split PDF.