Taruh laporan pindaian 80 MB di balik tautan, buka di browser, dan amati yang terjadi: viewer duduk di panel kosong sampai sebagian besar byte tersebut tiba, kemudian melukis halaman pertama sekaligus. Lompat ke halaman 40 dan, pada file yang dibangun buruk, seluruh unduhan mungkin dimulai ulang. Bagian yang membuat frustasi adalah reader hanya pernah menginginkan halaman pertama. Linearisasi adalah jawaban struktural untuk masalah itu. Ini mengatur ulang PDF sehingga viewer dapat merender halaman pembuka dari sebagian kecil file dan mengambil sisanya sesuai permintaan, itulah mengapa Adobe memasarkan fitur ini sebagai "Fast Web View."
Tidak satu pun dari ini adalah format file yang berbeda. PDF yang dilinearisasi adalah PDF biasa yang akan dibuka reader yang sesuai tanpa penanganan khusus. Triknya sepenuhnya ada pada bagaimana byte dipesan dan pada dua struktur ekstra yang dibawa file. ISO 32000-1 menentukan seluruh pengaturan dalam Lampiran F, dan begitu Anda melihat tata letaknya, perilakunya berhenti terlihat seperti sihir dan mulai terlihat seperti pertukaran deliberat antara urutan file dan latensi cat pertama
Apa yang sebenarnya diatur ulang oleh linearisasi
PDF normal dapat menyebarkan objeknya dalam hampir semua urutan. Tabel referensi silang di akhir file adalah yang membuatnya bekerja: reader mencari ke akhir, membaca penunjuk startxref, memuat xref, dan dari sana dapat menemukan setiap objek berdasarkan offset-nya. Desain tersebut sangat baik untuk file lokal, di mana mencari ke akhir tidak memerlukan biaya, dan buruk untuk file yang streaming melalui jaringan, di mana ujungnya adalah bagian yang tiba paling akhir. Untuk merender halaman pertama, reader konvensional membutuhkan objek halaman, content stream-nya, font yang direferensikannya, dan gambar apa pun yang digambarnya, dan dalam file yang tidak berurutan, semuanya dapat duduk di mana saja, termasuk megabyte terakhir
Linearisasi memperbaiki urutan. Objek yang dibutuhkan untuk menampilkan halaman pertama dikumpulkan ke dalam blok yang bersebelahan di dekat depan, tepat setelah bagian header kecil, sehingga mereka tiba lebih awal dalam aliran byte. Semua yang lain, halaman yang tersisa dan sumber daya yang dibagikannya, mengikuti dalam urutan yang dapat diprediksi. Tabel referensi silang kedua yang lengkap masih ada di akhir untuk reader yang mengabaikan optimasi, tetapi file yang dilinearisasi juga menempatkan referensi silang halaman pertama dan parameter yang dibutuhkan reader streaming di depan. Reader tidak lagi harus mencapai ekor sebelum dapat menggambar apa pun
Set objek halaman pertama dan kamus parameter linearisasi
Objek pertama dalam file yang dilinearisasi, setelah header %PDF, adalah kamus parameter linearisasi. Itulah yang dicari reader streaming untuk memutuskan apakah optimasi ada dan cara menggunakannya. Kamus mencatat panjang seluruh file, offset byte di mana bagian referensi silang utama dimulai, nomor objek halaman pertama, dan lokasi serta panjang hint stream yang mengikuti. Dengan angka-angka tersebut, reader mengetahui, dari kilobyte pembuka saja, berapa banyak yang harus diambil untuk menampilkan halaman pertama dan di mana mencari indeks yang memungkinkannya melompat ke tempat lain
Lampiran F ketat tentang apa yang dimaksud "halaman pertama" di sini. Bagian halaman pertama harus berisi objek halaman itu sendiri, content stream-nya, dan sumber daya yang direferensikan oleh aliran tersebut, sehingga halaman mandiri begitu awalan tersebut telah diunduh. Sumber daya bersama, font yang digunakan di setiap halaman, logo yang berulang di header, ditangani secara khusus: mereka muncul cukup awal untuk melayani halaman pertama tetapi ditandai sebagai bersama sehingga reader tidak mengambilnya kembali saat kemudian merender halaman 30. Perbedaan antara objek privat-halaman dan bersama itulah yang banyak "pengoptimal" buatan rumah salah dapatkan, dan mendapatkannya salah adalah yang menghasilkan file yang mengklaim dilinearisasi tetapi masih terhenti
Hint stream: indeks yang membuat lompatan halaman murah
Menampilkan halaman pertama dengan cepat hanya setengah nilainya. Setengah lainnya adalah melompat ke halaman mana pun tanpa mengunduh semua yang ada di antaranya, dan itulah yang disediakan hint stream. File yang dilinearisasi membawa tabel offset halaman dan tabel hint objek bersama, disimpan sebagai aliran yang direferensikan dari kamus parameter. Tabel offset halaman mencatat, untuk setiap halaman, di mana objeknya dimulai dalam file dan seberapa jauh jalannya. Tabel objek bersama melakukan hal yang sama untuk sumber daya yang digunakan di beberapa halaman
Dengan tabel-tabel tersebut, reader yang menginginkan halaman 40 tidak mengurai file secara berurutan. Ia berkonsultasi dengan tabel hint untuk mengetahui rentang byte yang ditempati halaman 40, meminta server untuk tepat rentang tersebut, dan merender halaman begitu byte tersebut tiba, menarik sumber daya bersama yang belum dimilikinya melalui mekanisme yang sama. Hint stream adalah, secara efektif, peta akses acak yang dilapisi di atas dokumen, dan itulah alasan file 500 halaman yang dilinearisasi dengan baik terasa responsif melalui tautan lambat sementara yang tidak dioptimalkan dengan ukuran yang sama tidak
Mengapa server harus bekerja sama
Linearisasi mengasumsikan transport dapat mengirimkan irisan file yang sewenang-wenang, dan asumsi itu layak untuk diperiksa sebelum Anda mengkreditkan format untuk hasil yang buruk. Mekanismenya adalah pengiriman byte HTTP: reader mengeluarkan permintaan range, dan server menjawabnya dengan respons 206 Partial Content. Jika server tidak mengiklankan Accept-Ranges: bytes, atau jika proxy atau CDN di depannya menciutkan permintaan range menjadi transfer penuh, reader tidak memiliki cara untuk mengambil halaman 40 secara terpisah dan jatuh kembali ke mengunduh seluruh file. Struktur di dalam PDF kemudian sempurna benar dan sepenuhnya terbuang sia-sia
Ini adalah kegagalan yang paling sering salah didiagnosis sebagai "linearisasi tidak bekerja." Filenya baik-baik saja; jalur pengirimannya tidak. Sebelum Anda membangun ulang dokumen, konfirmasi dengan permintaan kondisional bahwa host benar-benar mengembalikan konten parsial untuk URL yang ditekan reader. Banyak host statis melakukan ini secara default, dan banyak server aplikasi yang salah konfigurasi dan lapisan caching tidak melakukannya
Pembaruan inkremental secara diam-diam merusak linearisasi
Inilah kendala yang mengejutkan orang yang menghasilkan file yang dilinearisasi dengan benar dan kemudian bertanya-tanya mengapa optimasinya menghilang. Linearisasi bergantung pada tata letak tunggal yang dipesan dengan cermat dengan indeksnya di depan. Pembaruan inkremental melanggar itu berdasarkan desain. Ketika alat menambahkan tanda tangan, mengisi bidang formulir, atau menambahkan anotasi melalui penyimpanan inkremental, ia tidak menulis ulang file. Ia menambahkan objek yang diubah, bagian referensi silang baru, dan trailer baru ke akhir, membiarkan byte asli tidak tersentuh. Tambahan itu adalah seluruh poin pembaruan inkremental: cepat, dan mempertahankan revisi sebelumnya untuk audit atau validasi tanda tangan
Efek sampingnya adalah file sekarang memiliki data referensi silang terbaru di ekor, setelah blok halaman pertama yang ditempatkan dengan cermat, dan kamus parameter linearisasi di depan mendeskripsikan tata letak yang tidak lagi cocok dengan file. Reader yang sesuai mendeteksi ketidakcocokan dan memperlakukan dokumen sebagai PDF normal yang tidak dilinearisasi. Fast Web View sudah hilang, meskipun struktur asli yang dilinearisasi masih duduk di paruh pertama file. Jika Anda menambahkan beberapa pembaruan, masing-masing menumpuk revisi lain di akhir dan celah antara indeks depan yang basi dan keadaan nyata melebar
Jika alur kerja Anda membutuhkan pengeditan dan Fast Web View, aturannya mengikuti langsung dari strukturnya: edit secara inkremental saat dokumen dalam perubahan, kemudian re-linearisasi sekali di akhir. Penulisan ulang penuh adalah yang memulihkan tata letak. Dalam istilah HotPDF, itu berarti pengeditan yang sedang berlangsung melalui BeginIncrementalUpdate dan SaveIncrementalUpdate, yang menambahkan delta, sementara langkah penyelesaian memuat seluruh dokumen dan menyerialkannya segar dengan LoadFromFile diikuti oleh SaveLoadedDocument, yang menghilangkan revisi lama yang terakumulasi dan memancarkan satu tata letak bersih. Pertukaran yang sama muncul dengan object stream: mengaktifkan UseObjectStreams bersama dengan UseXRefStream mengompres referensi silang dan mengemas objek dengan rapat, yang membantu ukuran file tetapi, seperti pilihan struktural apa pun, harus diterapkan selama penulisan ulang akhir itu daripada dibaut pada revisi yang ditambahkan
// In-flight edits: append a delta, keep prior revisions intact.
// This leaves the file NOT linearized.
Pdf.BeginIncrementalUpdate('report.pdf');
Pdf.AddPage;
Pdf.CurrentPage.TextOut(72, 760, 0, 'Addendum');
Pdf.SaveIncrementalUpdate('report.pdf');
// Finishing step: full re-serialization produces one clean layout,
// dropping the stacked revisions. Re-run your linearizer on the output.
Pdf.LoadFromFile('report.pdf');
Pdf.SaveLoadedDocument('report-final.pdf');HotPDF tidak mengekspos rutinitas "linearisasi" satu panggilan, sehingga pola praktisnya adalah menghasilkan file yang bersih dan ditulis ulang sepenuhnya dan menjalankan pengoptimal khusus di atasnya. Alat baris perintah menangani penataan ulang secara langsung. qpdf menulis ulang file ke dalam bentuk yang dilinearisasi dengan satu flag:
qpdf --linearize report-final.pdf report-web.pdfCara mengetahui apakah file dilinearisasi
Jangan percaya nama file atau alat yang mengklaim menghasilkannya; verifikasi byte. Pemeriksaan paling langsung adalah kepala file: buka dan cari kamus parameter linearisasi sebagai objek pertama setelah header, membawa kunci /Linearized. Pintasan yang menghadap reader adalah dialog Properti Dokumen Acrobat, yang melaporkan "Fast Web View: Yes" hanya ketika struktur benar-benar ada dan terkini
Untuk pemeriksaan skrip, qpdf melaporkan baik keberadaan maupun integritas struktur, yang penting karena file dapat membawa kamus linearisasi yang tidak lagi mencerminkan tata letaknya, tepat kondisi yang ditinggalkan pembaruan inkremental:
# Reports "File is linearized" and validates hint tables against the layout
qpdf --check report-web.pdf
# Dumps the linearization parameters and hint data in detail
qpdf --show-linearization report-web.pdfLangkah validasi adalah yang mendapat manfaatnya. Pass yang hanya mengkonfirmasi kamus ada akan dengan senang hati memberkati file yang indeksnya menunjuk ke offset yang salah; pemeriksaan yang merekonsiliasi tabel hint dengan posisi objek aktual adalah yang memberi tahu Anda optimasi akan bertahan di bawah permintaan range reader nyata
Linearisasi tetap layak diterapkan pada dokumen besar apa pun yang disajikan melalui web, terutama ke reader seluler pada koneksi yang tidak merata, dan biayanya beberapa persen ukuran file untuk indeks yang dimuat di depan. Dua hal yang harus dijaga lurus adalah bahwa struktur di dalam PDF dan pengiriman byte di luarnya keduanya harus benar, dan bahwa pengeditan apa pun setelahnya membatalkan optimasi sampai Anda menulis ulang file. Perlakukan re-linearisasi sebagai langkah terakhir dalam pipeline, setelah setiap perubahan lain sudah selesai. Perilaku referensi silang, object stream, dan pembaruan inkremental yang dijelaskan di sini adalah bagian dari model struktural yang diimplementasikan HotPDF Component untuk Delphi dan C++Builder; untuk latar belakang tata letak file yang lebih luas lihat cara PDF disusun, dan untuk alur kerja pembaruan inkremental dan file besar dalam kode lihat memproses PDF besar dari Delphi