Apa yang sebenarnya terjadi saat Anda mengompres PDF
Compress PDF123 menjalankan rekompresi stream qpdf dan pengemasan object stream, bukan downsampling gambar, pengodean ulang JPEG secara lossy, atau subsetting font. Linearisasi hampir tidak mengubah ukuran berkas.
Dua PDF dapat tampak identik di layar namun berbeda tiga orde besaran: 50 KB berbanding 50 MB. Selisih itu hampir tidak pernah terletak pada operator teks. Pada kontrak dua puluh halaman, operator teks biasanya hanya beberapa puluh kilobyte; sisanya adalah sampel gambar, program font yang tertanam utuh, dan seberapa rapat stream serta objek dikemas.
Ada satu konsekuensi yang layak disebut sejak awal: "mengompres PDF" bukan satu tindakan, melainkan empat. Masing-masing mengecilkan hal yang berbeda dan memungut biaya yang berbeda, dan memperlakukannya sebagai satu hal menghasilkan pengalaman yang saling bertentangan: berkas sudah dikompres tetapi tidak mengecil, atau mengecil tetapi halamannya jadi kabur.
Dari mana ukurannya berasal
Sebagian besar kasus "mengapa PDF ini begitu besar?" dimulai dari hasil pindai atau foto resolusi tinggi yang masih tertanam pada ukuran tangkapannya. Aritmetikanya layak dihitung sekali: satu halaman ukuran letter 8,5 × 11 inci yang ditangkap pada 300 DPI berukuran sekitar 2550 × 3300 piksel, dan pada tiga byte per piksel itu berarti sekitar 25 MB sebelum dikompresi. Dua puluh halaman seperti itu sering kali mencapai 60 hingga 80 MB sebelum ada yang menyentuh kompresi.
Sumber kedua adalah font. PDF dapat menanamkan seluruh program font agar setiap mesin merender teks secara identik, dan biayanya ditentukan oleh ukuran tabel glyph, bukan oleh seberapa banyak teks yang benar-benar dibaca. Itulah sebabnya subsetting font menjadi tuas ukuran yang terpisah.
Yang ketiga adalah pengemasan itu sendiri. Konten yang sama dapat disimpan dengan pengaturan kompresi yang boros, atau objeknya tersebar di seluruh berkas dan masing-masing membawa beban pembukuannya sendiri. Semua itu tidak mengubah satu piksel atau glyph pun, dan justru bagian itulah yang dapat dijangkau oleh rekompresi stream.
"Compress" adalah empat hal yang berbeda
Ada empat tuas pada ukuran, mereka bekerja pada lapisan yang berbeda, dan biayanya hampir tidak bertumpang tindih. Memilih tuas yang salah adalah alasan paling umum sebuah proses kompresi tampak tidak melakukan apa pun.
| Tuas | Apa yang disentuh | Keuntungan ukuran | Biaya |
|---|---|---|---|
| Rekompresi stream dan object stream | Cara content stream dikompresi, cara objek disimpan dan dikemas | Bergantung pada seberapa longgar berkas aslinya | Tampilan halaman tidak berubah |
| Downsampling gambar | Jumlah piksel, yaitu resolusi | Besar | Resolusi berkurang secara permanen |
| Pengodean ulang gambar secara lossy | Representasi byte bitmap | Besar | Kualitas gambar menurun |
| Subsetting font | Tabel glyph yang tertanam | Sedang | Glyph yang tidak terpakai tidak lagi dapat diedit |
| Linearisasi | Urutan objek | Hampir nol | Sebagai gantinya mempercepat pemuatan halaman pertama |
Empat baris pertama semuanya disebut "kompresi" secara longgar, tetapi hanya baris pertama yang membiarkan kontennya utuh. Baris itulah yang hasilnya paling mudah salah dinilai: hasil pindai yang ukurannya sebagian besar berupa sampel gambar mentah hanya punya sedikit redundansi untuk dihapus, dan tuas yang benar-benar dapat memangkasnya adalah downsampling dan pengodean ulang lossy, dengan harga kehilangan resolusi dan kualitas itu untuk selamanya.
Dari empat tuas itu, PDF123 Compress hanya menjalankan satu
Compress a PDF (POST /api/v1/misc/compress-pdf) hanya menjalankan baris pertama. Perintah ini menjalankan qpdf dengan kompresi untuk stream yang belum terkompresi (--compress-streams=y), satu lintasan kedua untuk stream yang sudah dikompresi dengan Flate (--recompress-flate), dan pengemasan objek ke dalam object stream (--object-streams=generate).
Perintah ini tidak menurunkan resolusi gambar, tidak mengodekan ulang bitmap ke kualitas JPEG yang lebih rendah, dan tidak menyubset font. Halaman seharusnya tampak sama, dan penghematannya berasal dari rekompresi Flate dan pengemasan object stream.
Kondisi kegagalannya layak dijelaskan dengan kejelasan yang sama. Ketika ukuran sebuah berkas sebagian besar berupa data gambar yang sudah dikompresi sebagai JPEG, Flate tidak punya sisa untuk diperas, karena byte gambar itu berada di luar jangkauan tiga sakelar di atas. Itulah sebabnya satu paket hasil pindai bisa kembali hanya beberapa persen lebih kecil, sementara PDF padat teks dengan ukuran serupa bertambah ramping jauh lebih terasa.
Jalur sebaliknya adalah Decompress PDF, yang mengembangkan stream untuk pemeriksaan (--qdf, object stream dinonaktifkan) dan juga tidak mengubah tampilan halaman.
Kapan harus memilih jalur lain
| Yang Anda butuhkan | Jalur yang dipakai |
|---|---|
| Tampilan identik, hanya menghapus beban pengemasan | Compress |
| Paket hasil pindai yang benar-benar terlalu besar dan kehilangan kualitas dapat diterima | Downsampling atau pengodean ulang lossy, bukan Compress ini |
| Tetap dapat diedit, tetapi karakter berikutnya tidak bisa diketik | Ganti pengaturan ekspor atau berkas sumber, lihat subsetting font |
| Browser sebaiknya melihat halaman pertama lebih cepat | Linearisasi menyelesaikan render pertama, bukan ukuran |
| Berkas sama sekali tidak bisa dibuka | Repair, itu masalah struktur, bukan masalah ukuran |
Ada satu jebakan di baris terakhir: Linearize PDF bukan implementasi terpisah di sini, melainkan alias dari Compress. Keduanya menunjuk ke operasi yang sama, id kanonisnya misc/compress-pdf dengan linearize-pdf sebagai alias, portal selalu mengirim linearize=true dan optimizeLevel=1 untuk alat itu, server tidak membaca kedua field tersebut, dan qpdf tidak pernah menerima --linearize. Operasi yang benar-benar melinearisasi berkas adalah Protect, saat ia mengenkripsinya.
Jadi jika yang Anda inginkan adalah tampilan yang sama dalam berkas yang lebih kecil, Compress adalah jawaban lengkapnya. Jika Anda ingin pengecilan gambar secara lossy atau subsetting font, jalur ini adalah tuas yang salah. Berkasnya kembali langsung, tanpa perlu akun. Untuk melihat di mana objek, stream, dan tabel referensi silang sebenarnya berada, lanjutkan ke What's inside a PDF.