𝗦𝘁𝗼𝗽 𝗣𝗮𝗿𝘀𝗶𝗻𝗴 𝗣𝗗𝗙𝘀 𝗮𝘁 𝗥𝗲𝗻𝗱𝗲𝗿 𝗧𝗶𝗺𝗲

Most developers build PDF extraction tools the wrong way.

They try to guess document structure from the visual output. They render a page to a canvas and look at pixel positions. They use computer vision to find columns or tables.

This approach is backwards.

A PDF already contains the structure you need in the operator stream.

A table is not just a set of pixels. It is a set of path operators like moveTo, lineTo, and rectangle. Zone boundaries are encoded in the CTM stack. You do not need to reconstruct what is already there.

Stop using visual heuristics. Use the source data.

I previously tried using De Casteljau subdivision for bounding boxes. I rejected it during testing.

De Casteljau is a subdivision algorithm. You split curves until the segments are small enough. This works for rendering, but it is bad for bounding boxes.

You have to choose a tolerance. If the tolerance is too loose, the box is wrong. If it is too tight, you waste resources on recursion. There is a better way. An analytical solution using the quadratic formula is exact. It does not recurse. It does not allocate segments.

The same logic applies to zone detection.

Many tools calculate zone boundaries by finding the midpoint between two text groups. This is a visual guess. It is not structural.

If you use midpoints, sub-pixel rounding will place regions in the wrong zones.

The fix is simple. Use the top edge of the bounding box. A region belongs to a zone based on where it starts. Use the actual Y-coordinate of the top edge.

Building a real PDF extractor is harder. You must:

• Read the operator stream instead of just text content.
• Build a CTM stack to track matrix state.
• Classify subpaths geometrically.
• Emit segments with provenance.

This is more work than pixel-based guessing. But it produces deterministic results.

A pixel-based tool gives different results at 100% zoom than it does at 150% zoom. It is pattern-matching visual artifacts, not extracting structure.

If you do not parse the operator stream, you are building a demo. It might work on your test files, but it will fail on real user uploads.

The path through the operator stream is difficult. You must understand the fill and stroke state machines and the PDF specification. But you only have to learn it once. Then it works for every PDF.

Berhenti melakukan parsing PDF saat waktu render: Arsitektur yang lebih baik untuk ekstraksi terstruktur

Melakukan parsing PDF saat aplikasi sedang merender data adalah resep menuju bencana.

Jika Anda pernah membangun aplikasi yang mengunggah PDF dan langsung mencoba menampilkan datanya di UI, Anda mungkin telah merasakan masalahnya. Aplikasi terasa lambat, UI membeku, dan terkadang proses tersebut gagal tanpa alasan yang jelas.

Masalah utamanya bukan pada PDF itu sendiri, melainkan kapan Anda melakukan parsing.

Masalah dengan Parsing pada Waktu Render

Banyak pengembang melakukan parsing PDF di dalam siklus render atau saat permintaan API sedang diproses untuk memberikan respons kepada pengguna. Meskipun ini terlihat mudah di awal, pendekatan ini memiliki beberapa kelemahan fatal:

1. Latensi yang Tinggi

PDF adalah format yang sangat kompleks. Tidak seperti JSON yang terstruktur, PDF adalah instruksi untuk menggambar karakter di koordinat tertentu. Untuk mengekstrak teks atau tabel, mesin parser harus membaca seluruh struktur file, menghitung posisi elemen, dan sering kali melakukan OCR (Optical Character Recognition). Melakukan semua ini saat pengguna menunggu respons API akan menyebabkan latensi yang sangat tinggi.

2. Kompleksitas dan Beban CPU

Parsing PDF adalah tugas yang intensif secara komputasi. Jika Anda melakukan ini di dalam server web yang menangani permintaan HTTP, Anda menghabiskan sumber daya yang seharusnya digunakan untuk melayani pengguna lain. Hal ini dapat menyebabkan penurunan performa seluruh sistem.

3. Kerentanan (Brittleness)

PDF tidak memiliki skema yang kaku. Perubahan kecil dalam tata letak dokumen dapat menyebabkan parser gagal atau menghasilkan data yang salah. Jika proses ini terjadi saat render, kegagalan tersebut akan langsung berdampak pada pengalaman pengguna (misalnya, halaman error atau data yang rusak).

Solusi: Ekstraksi yang Terpisah (Decoupled Extraction)

Alih-alih melakukan parsing saat data dibutuhkan, pendekatan yang lebih baik adalah melakukan parsing segera setelah file diunggah dan menyimpan hasilnya dalam format terstruktur (seperti JSON).

Berikut adalah alur kerja arsitektur yang direkomendasikan:

1. Unggah: Pengguna mengunggah PDF ke penyimpanan (misalnya, AWS S3).
2. Trigger: Unggahan file memicu sebuah event (misalnya, melalui S3 Event Notifications).
3. Antrean (Queue): Event tersebut dimasukkan ke dalam antrean pesan (seperti AWS SQS atau RabbitMQ).
4. Worker: Sebuah layanan worker (microservice khusus) mengambil tugas dari antrean.
5. Ekstraksi: Worker melakukan parsing PDF secara mendalam dan mengekstrak data ke dalam skema yang ditentukan.
6. Penyimpanan: Hasil ekstraksi yang sudah terstruktur disimpan ke dalam database (misalnya, PostgreSQL atau MongoDB).
7. Konsumsi: Saat UI membutuhkan data, ia hanya perlu melakukan query ke database untuk mengambil JSON yang sudah jadi. Proses ini sangat cepat.

Perbandingan Arsitektur

Fitur	Parsing pada Waktu Render	Ekstraksi Terpisah (Decoupled)
Kecepatan UI	Lambat (menunggu parsing)	Sangat Cepat (hanya ambil JSON)
Skalabilitas	Sulit (beban pada server web)	Mudah (tambah worker jika perlu)
Ketahanan	Rendah (kegagalan merusak render)	Tinggi (bisa dicoba ulang/retry)
Penggunaan Sumber Daya	Tidak terprediksi	Terkendali dan terisolasi

Keuntungan Utama

Skalabilitas yang Lebih Baik

Dengan memisahkan proses parsing ke dalam worker, Anda dapat menskalakan proses ekstraksi secara independen dari server web Anda. Jika ada lonjakan unggahan dokumen, Anda cukup menambah jumlah worker tanpa memengaruhi kemampuan aplikasi untuk melayani permintaan pengguna lainnya.

Pengalaman Pengguna yang Lebih Mulus

Pengguna tidak perlu menunggu proses parsing yang berat selesai untuk melihat hasil awal. Anda dapat memberikan umpan balik seperti "Sedang memproses dokumen..." dan memperbarui UI secara asinkron menggunakan WebSocket atau polling saat data sudah siap.

Keandalan dan Kemampuan Retry

Jika proses parsing gagal karena file yang rusak, sistem antrean memungkinkan Anda untuk mencoba kembali (retry) secara otomatis atau menandai dokumen tersebut untuk ditinjau secara manual tanpa mengganggu aliran kerja utama aplikasi.

Kesimpulan

Jangan biarkan kompleksitas PDF memperlambat aplikasi Anda. Dengan memindahkan beban kerja parsing dari waktu render ke proses latar belakang yang terstruktur, Anda menciptakan sistem yang lebih cepat, lebih skalabel, dan jauh lebih tangguh.

Simpan data dalam bentuk yang Anda butuhkan, bukan dalam bentuk yang diberikan oleh file sumber.