Bagaimana OCR membaca PDF hasil pindai, dan mengapa alat ini mengembalikan Markdown

PDF hasil pindai menyimpan halaman sebagai gambar raster, yaitu foto teks, bukan karakter yang bisa dipilih. OCR (optical character recognition) menatap piksel itu, menebak bentuk mana yang merupakan karakter, lalu mengeluarkan teks sungguhan. Di PDF123, proses itu berjalan sebagai alat browser gratis dan sebagai POST /api/v1/misc/ocr-pdf; responsnya berupa Markdown, bukan PDF yang ditulis ulang.

Hasil pindai tetap sebuah gambar

OCR tidak membersihkan, mempertajam, atau menggantikan bitmap. Hasil pindai yang tajam tetapi salah dibaca OCR tetap terlihat tajam. Gambarnya tidak pernah menjadi penghambat mutu; pengenalan itulah yang jadi penghambat: ganti mesin pengenalan pada batch hasil pindai yang sama, dan akurasinya bisa berubah drastis, padahal pikselnya sama sekali tidak disentuh.

OCR PDF klasik menulis lapisan teks kedua yang tak terlihat, disejajarkan di bawah gambar, agar fungsi pilih dan cari mendarat pada kata yang benar. Itulah yang digambarkan diagram, dan begitulah cara kerja banyak alat desktop sampai sekarang.

Apa yang sebenarnya dikembalikan titik akhir ini

Rute OCR memanggil /api/v1/misc/ocr-pdf, yang berjalan di atas crate Rust mandiri bernama pdf-inspector (dibangun dengan fitur ocr-nya). Ia tidak menyerahkan seluruh PDF ke model pengenalan. pdf-inspector lebih dulu mengklasifikasikan tiap halaman: sudah punya teks asli yang bisa diekstrak, atau hanya berupa gambar. Halaman dengan teks asli mempertahankan teks itu apa adanya dan tidak pernah menyentuh model pengenalan; halaman yang hanya gambar justru melewati alur pengenalan—PDFium (perenderan sumber terbuka yang sama yang dipakai Chrome secara internal) merasterisasi halaman itu, lalu ONNX Runtime menjalankan model PP-OCRv6 Small untuk membacanya. Kedua jenis halaman digabungkan berurutan menjadi satu dokumen Markdown, itulah sebabnya responsnya text/markdown dan berkas unduhan berakhiran .md.

Kontrak itu baru ada sejak penulisan ulang ini. Backend Java/Spring Boot lama yang dulu dijalankan proyek ini memanggil OCRmyPDF, pendekatan klasik "gambar plus lapisan teks tersembunyi", dan mengembalikan PDF. Penulisan ulang dengan Rust menggantikan seluruh jalur itu dengan OCR selektif milik pdf-inspector, dan keluarannya pun berpindah dari PDF ke Markdown bersamaan dengan itu. Backend Java lama sejak itu sudah dihapus sepenuhnya dari repositori; ini bukan sakelar yang bisa Anda nyalakan kembali.

Jika Anda membutuhkan PDF yang bisa dicari (gambar plus lapisan teks), keluaran ini bukan yang Anda cari. Jika Anda membutuhkan teks yang bisa dibaca agen atau pipeline, justru Markdown itulah tujuannya.

Auto versus Force OCR

Formulir menyediakan field ocrType:

• Normal (apa pun selain force-ocr) dipetakan ke Auto: pakai teks yang sudah ada bila berkas memilikinya, dan jalankan OCR pada halaman yang hanya berisi gambar. Pada PDF born-digital yang bersih, Auto tidak memuat runtime OCR.
• Force OCR (ocrType=force-ocr) menjalankan ulang pengenalan pada setiap halaman, termasuk halaman yang sudah punya lapisan teks. Pada halaman yang memang hanya berisi gambar, Anda membayar waktu tanpa tambahan akurasi; yang Anda dapatkan adalah pembacaan ulang yang mengabaikan lapisan lama yang rusak atau tidak lengkap.

Default portal adalah Force OCR. Tidak ada pengaturan bahasa: kode tessdata sisa dari jalur Java lama diabaikan.

Pemisahan Auto/Force terjadi di dalam request itu sendiri, dan baik portal maupun capability probe API tidak memeriksanya untuk Anda lebih dulu. GET /api/v1/settings/get-endpoints-status selalu melaporkan ocr-pdf sebagai "enabled", tanpa benar-benar memverifikasi apakah PDFium, ONNX Runtime, atau model PP-OCRv6 sudah terpasang. Pemeriksaan sesungguhnya baru terjadi saat sebuah request memicu pengenalan: jika salah satunya hilang, endpoint mengembalikan 503, bukan Markdown yang diam-diam merosot ke teks asli saja. Model PP-OCRv6 Small sendiri berukuran sekitar 31 MB; kecuali sudah ditanam ke cache lokal saat deploy, model itu akan diunduh lewat jaringan pada saat pertama kali sebuah halaman benar-benar membutuhkan pengenalan. Mesin yang offline tanpa model yang sudah ditanam kemungkinan besar akan gagal tepat pada request Force pertamanya, bukan sekadar berjalan lambat.

Pengenalan bersifat probabilistik

Mesin OCR mencocokkan pola piksel dengan model huruf dan kata. Hasilnya baik pada cetakan bersih, berkontras tinggi, dan berfont standar, serta memburuk pada:

• Hasil pindai beresolusi rendah atau berkontras rendah (kualitas faks dibanding asli 300 DPI)
• Tulisan tangan, font dekoratif, tata letak tidak lazim (tabel banyak kolom, teks diputar, formulir padat)
• Halaman miring yang memelintir bentuk glif secukupnya sehingga membingungkan pencocokan

Faks yang buram tidak akan dikenali OCR seperti hasil pindai yang bersih, terlepas dari pilihan Auto atau Force. Itu adalah batas dari model itu sendiri, bukan sesuatu yang bisa diperbaiki dengan parameter.

Apa yang tidak dilakukan OCR

OCR memberi Anda teks. Ia tidak membangun ulang paragraf, judul, tabel, atau dokumen Word yang bisa mengalir ulang. Tata letak yang dapat disunting adalah persoalan konversi di atas galat pengenalan, bukan pekerjaan yang sama dengan membaca hasil pindai.

OCR a PDF berjalan di sisi server tanpa akun. Unduhannya berupa Markdown. Jika lapisan teks yang ada terlihat keliru, gunakan Force OCR agar Auto tidak memercayai lapisan tersebut; untuk memeriksa apakah suatu mesin benar-benar sudah memasang PDFium dan modelnya, menjalankan request sungguhan lebih bisa diandalkan daripada membaca capability probe, karena probe itu hanya memastikan endpoint-nya ada, bukan bahwa runtime-nya sudah siap. Untuk key otomasi dan OpenAPI, lihat Developers.