Cara Kerja Pengeditan PDF Berbasis Browser (Dan Mengapa Privasi Penting)

Setiap kali Anda mengunggah dokumen ke alat PDF berbasis cloud, dokumen tersebut tersimpan di server yang tidak Anda kendalikan, diproses oleh perangkat lunak yang tidak dapat Anda periksa, dan disimpan oleh perusahaan dengan kebijakan penyimpanan data dan keamanan sendiri. Untuk sementara waktu, infrastruktur pihak lain menyimpan kontrak, laporan pajak, catatan medis, atau dokumen bisnis rahasia Anda.

LuraPDF bekerja secara berbeda. Semuanya terjadi di tab browser Anda, pada perangkat keras Anda, dengan manajemen memori sistem operasi Anda. Artikel ini menjelaskan arsitektur teknis yang memungkinkan hal ini dan pertimbangan rekayasa yang terlibat.

Browser sebagai Platform Pemrosesan Dokumen

Browser modern bukan lagi sekadar perender HTML. Mereka adalah lingkungan eksekusi aplikasi lengkap dengan:

• Mesin JavaScript (V8 di Chrome, SpiderMonkey di Firefox): mengeksekusi kode dengan kecepatan mendekati kecepatan native.
• WebAssembly (WASM): mengeksekusi kode C/C++ yang telah dikompilasi dengan kecepatan mendekati kecepatan native dalam lingkungan sandbox.
• API Kanvas: memungkinkan manipulasi gambar tingkat piksel.
• API Akses Sistem Berkas: memungkinkan membaca berkas lokal tanpa mengunggah
• Web Workers: menjalankan komputasi pada thread latar belakang tanpa membekukan UI.
• ArrayBuffer / Blob: mengelola data biner mentah (seperti byte PDF) di memori

Gabungan kemampuan ini memungkinkan terciptanya alur pemrosesan dokumen yang lengkap, yang lima tahun lalu membutuhkan server backend.

Tiga Pustaka Inti

LuraPDF dibangun di atas tiga pustaka sumber terbuka fundamental:

perpustakaan pdf

pdf-lib adalah pustaka TypeScript untuk membuat dan memodifikasi dokumen PDF di lingkungan JavaScript apa pun. Pustaka ini mengimplementasikan sebagian besar spesifikasi PDF (ISO 32000), termasuk:

• Pembuatan, modifikasi, dan penghapusan halaman
• Penyematan font (baik 14 font standar maupun font TTF/OTF kustom)
• Penyematan gambar (JPEG, PNG)
• Penempatan anotasi teks
• Pembuatan dan manipulasi kolom formulir
• Metadata dokumen (judul, penulis, tanggal pembuatan, dll.)
• Enkripsi PDF (AES-128 dan AES-256)
• Manajemen tabel referensi silang

Saat LuraPDF menggabungkan PDF, ia menggunakan pdf-lib untuk membaca struktur halaman setiap dokumen, menormalisasi sumber daya bersama, dan menyusun PDF baru. Saat mengompresi, ia mengkode ulang objek gambar dengan faktor kualitas yang lebih rendah. Saat mengenkripsi, ia menerapkan AES-256 ke dokumen menggunakan Web Crypto API.

pdf-lib beroperasi sepenuhnya pada objek ArrayBuffer — data biner mentah dalam memori browser. Tidak ada panggilan jaringan yang dilakukan.

pdfjs-dist

PDF.js adalah mesin rendering PDF milik Mozilla, yang didistribusikan sebagai pdfjs-dist di npm. Ini adalah mesin yang mendukung penampil PDF bawaan Firefox, yang telah diuji terhadap jutaan PDF di dunia nyata.

LuraPDF menggunakan pdfjs-dist untuk:

• Rendering halaman: Mengonversi halaman PDF ke Canvas ImageData untuk ditampilkan
• Ekstraksi teks: Membaca aliran konten teks dari halaman PDF
• Metadata halaman: Mendapatkan dimensi halaman, nilai rotasi, dan tipe konten

Saat Anda melihat PDF yang ditampilkan di antarmuka LuraPDF — pratinjau visual halaman — itu adalah hasil rendering setiap halaman oleh pdfjs-dist ke elemen HTML Canvas.

Tesseract.js

Tesseract.js adalah versi Tesseract OCR yang dikompilasi dengan WebAssembly. Tesseract adalah mesin OCR sumber terbuka yang awalnya dikembangkan oleh HP Labs (1985) dan saat ini dikelola oleh Google. Ia menggunakan model jaringan saraf LSTM (Long Short-Term Memory) untuk pengenalan karakter.

Menjalankan Tesseract melalui WebAssembly di browser berarti:

• File biner WASM berukuran 22 MB dimuat sekali dan disimpan dalam cache oleh browser.
• Pemrosesan OCR berjalan pada CPU melalui WebAssembly, bukan GPU.
• Prosesnya lebih lambat daripada OCR berbasis cloud (yang menggunakan klaster GPU) tetapi menghasilkan kualitas output yang sama.
• Konten dokumen Anda tidak pernah meninggalkan perangkat Anda

Untuk pemindaian 20 halaman: OCR browser membutuhkan waktu sekitar 30–120 detik. Layanan cloud mungkin membutuhkan waktu 2–5 detik. Pilihan yang ada adalah privasi versus kecepatan.

Arsitektur: Dari File ke Output

Inilah yang terjadi ketika Anda, misalnya, mengompres PDF di LuraPDF:

1. Pemilihan berkas: Anda menyeret PDF ke area seret. API Berkas peramban membaca berkas ke dalam ArrayBuffer — byte mentah di memori peramban. Tidak ada pengunggahan yang terjadi.

2. Validasi: Pemeriksaan cepat untuk memastikan bahwa byte ajaib %PDF muncul di awal ArrayBuffer.

3. Memuat: PDFDocument.load() dari pdf-lib menguraikan tabel referensi silang, membaca pohon objek, dan membangun representasi dokumen dalam memori.

4. Enumerasi gambar: Pustaka ini menelusuri aliran konten halaman untuk menemukan XObject gambar (gambar yang disematkan). Lebar, tinggi, jenis kompresi, dan data byte setiap gambar diekstrak.

5. Pengkodean Ulang: Untuk setiap gambar, data piksel mentah digambar ke elemen HTML Canvas, kemudian diekspor ulang dengan faktor kualitas JPEG yang lebih rendah menggunakan canvas.toBlob('image/jpeg', quality) . Objek gambar asli diganti dengan versi terenkode yang lebih kecil.

6. Serialisasi dokumen: Metode save() dari pdf-lib menserialisasikan dokumen yang telah dimodifikasi kembali ke byte. Aliran objek dikompresi menggunakan DEFLATE.

7. Unduh: Byte dibungkus dalam objek Blob, URL objek sementara dibuat ( URL.createObjectURL(blob) ), dan klik terprogram <a> memicu mekanisme unduhan browser.

Total data yang dikirimkan ke server eksternal mana pun: nol byte.

Web Workers: Menjaga UI Tetap Responsif

Pemrosesan PDF membutuhkan banyak daya CPU. Menjalankannya pada thread JavaScript utama akan membuat tab browser membeku — Anda tidak dapat menggulir, mengklik, atau melihat pembaruan kemajuan saat file sedang diproses.

LuraPDF menjalankan semua komputasi berat (OCR, penguraian PDF besar, pengkodean ulang gambar) di Web Workers — thread JavaScript terpisah yang berjalan di latar belakang. Thread utama menangani UI, menampilkan bilah kemajuan, dan berkomunikasi dengan worker melalui pengiriman pesan (postMessage / onmessage).

Saat OCR berjalan, sebuah event kemajuan akan dipicu setelah setiap halaman diproses. Worker mengirimkan { page: 5, total: 20, confidence: 94 } ke thread utama, yang kemudian memperbarui progress bar. UI Anda tetap interaktif sepanjang proses.

Manajemen Memori

Memori browser terbatas. Sebuah PDF berukuran 200 MB yang dimuat ke dalam memori, diproses, dan disimpan dapat membutuhkan 400–600 MB RAM (byte asli + data Canvas perantara + byte keluaran). Pada sistem dengan RAM terbatas, hal ini dapat memicu tekanan memori.

Strategi yang digunakan:

• Pemrosesan halaman streaming: Untuk operasi multi-halaman, halaman diproses dan elemen Canvas perantara dibuang setelah digunakan.
• URL.revokeObjectURL(): URL blob sementara dicabut setelah diunduh untuk memungkinkan GC (Garbage Collection).
• Penghentian Worker: Web Worker dihentikan setelah menyelesaikan tugasnya untuk mengembalikan memori yang telah digunakan.

Untuk file yang sangat besar (>100 MB), browser modern dapat menanganinya tanpa masalah pada sistem dengan RAM 8 GB ke atas. Sistem yang lebih lama atau dengan keterbatasan memori mungkin akan kesulitan menangani file sumber berukuran 100 MB ke atas.

Arsitektur Privasi

Model keamanan tersebut diterapkan oleh kebijakan same-origin dan arsitektur isolasi browser:

• Tidak ada permintaan HTTP: Tidak ada panggilan API eksternal, tidak ada telemetri, tidak ada panggilan analitik selama pemrosesan dokumen.
• Eksekusi dalam lingkungan terisolasi (sandbox): Web Worker tidak dapat melakukan panggilan jaringan ke sumber eksternal.
• Tidak ada penyimpanan permanen: File yang diproses tidak ditulis ke penyimpanan browser (localStorage, IndexedDB, atau Akses Sistem File)
• Memori lingkup tab: Saat Anda menutup tab, semua objek ArrayBuffer dan Blob yang terkait dengannya akan dihapus oleh pengumpul sampah (garbage collector).

Arsitektur ini dapat diverifikasi: buka tab Jaringan di DevTools pada browser saat memproses sebuah file. Anda akan melihat nol permintaan selama operasi pemrosesan.

Pustaka Sumber Terbuka: Dapat Diperiksa, Bukan Kotak Hitam

Ketiga pustaka inti — pdf-lib, pdfjs-dist, dan Tesseract.js — adalah perangkat lunak sumber terbuka dengan repositori publik di GitHub. Implementasinya dapat diperiksa oleh siapa pun. Kode pemrosesan PDF yang berjalan di LuraPDF bukanlah kotak hitam berpemilik; ini adalah kode publik dengan pengguna, masalah, dan kontribusi nyata.

Hal ini penting untuk kepercayaan. Ketika layanan cloud mengatakan "kami memproses dan menghapus file Anda," Anda mempercayai begitu saja perkataan mereka. Ketika LuraPDF menggunakan pustaka sumber terbuka dalam lingkungan terisolasi peramban tanpa panggilan jaringan, Anda dapat memverifikasi klaim tersebut dengan mengamati tab jaringan.

Kompromi vs. Pemrosesan Cloud

Model berbasis browser memiliki kelemahan nyata yang perlu kita akui secara jujur:

Kecepatan: Layanan cloud memiliki klaster GPU dan infrastruktur khusus. OCR berbasis browser pada dokumen besar membutuhkan waktu 2–10 kali lebih lama dibandingkan dengan layanan cloud yang setara. Kompresi cepat karena menggunakan API Canvas secara langsung.

Batasan ukuran file: Batasan utamanya adalah memori browser. File yang sangat besar (>300 MB) mungkin mencapai batas memori pada beberapa sistem. Layanan cloud tidak memiliki batasan seperti itu.

Daya pemrosesan: WASM berjalan pada 40–80% kecepatan C++ asli. Layanan cloud menjalankan kode asli yang dioptimalkan. Untuk sebagian besar dokumen, perbedaan ini tidak terasa; untuk pekerjaan OCR dengan lebih dari 100 halaman, perbedaannya akan terlihat.

Fitur: Beberapa fitur PDF tingkat lanjut (pemeriksaan kepatuhan PDF/X, manajemen warna profesional, alur kerja CMYK) memerlukan alat khusus di sisi server. Pemrosesan berbasis browser menangani 95% kasus.

Untuk pemrosesan dokumen sehari-hari — kompresi, penggabungan, penandatanganan, konversi, penyuntingan — model berbasis browser cukup cepat, bersifat pribadi sejak awal, dan tidak memerlukan akun atau langganan.

Pertanyaan yang Sering Diajukan

Apakah LuraPDF mengumpulkan data telemetri atau data penggunaan? LuraPDF menggunakan Google Analytics untuk statistik tampilan halaman agregat. Operasi pemrosesan dokumen tidak menghasilkan peristiwa analitik apa pun. Isi file Anda tidak pernah dikirimkan.

Bisakah saya memastikan bahwa tidak ada pengunggahan yang terjadi? Ya. Buka Alat Pengembang (F12), klik tab Jaringan, filter berdasarkan "XHR" atau "Ambil". Proses sebuah file. Amati tidak ada permintaan jaringan terkait dokumen selama pemrosesan.

Mengapa proses OCR memakan waktu lebih lama dibandingkan layanan lain? Tesseract.js berbasis browser berjalan di CPU melalui WebAssembly. Layanan OCR berbasis cloud berjalan di klaster GPU yang memproses karakter jauh lebih cepat. Kelemahannya adalah dokumen Anda tidak pernah meninggalkan browser Anda.

Apa yang terjadi jika saya menutup tab saat proses sedang berlangsung? Pemrosesan berhenti seketika. Memori tab browser akan dihapus oleh pengumpul sampah. File asli Anda di disk tidak berubah.

Apakah kode tersebut bersifat open source? Pustaka pemrosesan inti (pdf-lib, pdfjs-dist, Tesseract.js) bersifat sumber terbuka. Kode antarmuka LuraPDF saat ini bukan sumber terbuka, tetapi alur pemrosesan hanya menggunakan komponen sumber terbuka.

Pergeseran ke pemrosesan dokumen berbasis browser bukanlah sekadar trik. Ini adalah pilihan arsitektur yang nyata dengan keunggulan privasi dan kepercayaan yang terukur — dengan mengorbankan kecepatan pada operasi yang intensif. Untuk dokumen yang Anda lebih suka tidak berada di server orang lain, ini adalah kompromi yang tepat.