Bagaimana OCR Membaca PDF Imbasan, dan Mengapa Alat Ini Memulangkan Markdown

PDF imbasan menyimpan halaman sebagai imej raster: gambar teks, bukan aksara yang boleh dipilih. OCR (optical character recognition) meneliti piksel tersebut, meneka bentuk mana yang merupakan aksara, lalu mengeluarkan teks sebenar. Di PDF123, proses itu berjalan sebagai alat pelayar percuma dan sebagai POST /api/v1/misc/ocr-pdf; responsnya ialah Markdown, bukan PDF yang ditulis semula.

Imbasan tetap sebuah gambar

OCR tidak membersihkan, mempertajam, atau menggantikan bitmap. Imbasan yang tajam tetapi salah dibaca oleh OCR masih kelihatan tajam. Imejnya tidak pernah menjadi halangan kualiti; pengenalannya yang bermasalah: tukar enjin pengenalan pada kumpulan imbasan yang sama, dan ketepatan boleh berubah dengan ketara, walaupun piksel itu sendiri tidak disentuh.

OCR PDF klasik menulis lapisan teks kedua yang tidak kelihatan, diselaraskan di bawah imej supaya pemilihan dan carian menemui perkataan yang betul. Itulah yang ditunjukkan oleh rajah, dan begitulah cara banyak alat desktop masih berfungsi.

Apa yang sebenarnya dipulangkan oleh laluan ini

Laluan OCR memanggil /api/v1/misc/ocr-pdf, yang berjalan atas crate Rust berdiri sendiri bernama pdf-inspector (dibina dengan ciri ocr-nya). Ia tidak menyerahkan keseluruhan PDF kepada model pengenalan. pdf-inspector mula-mula mengklasifikasikan setiap halaman: sama ada sudah mempunyai teks asal yang boleh diekstrak, atau hanya imej sahaja. Halaman dengan teks asal mengekalkan teks itu seadanya dan tidak pernah menyentuh model pengenalan; halaman imej sahaja pula melalui saluran paip pengenalan—PDFium (perender sumber terbuka yang sama yang digunakan Chrome secara dalaman) merasterkan halaman itu, kemudian ONNX Runtime menjalankan model PP-OCRv6 Small untuk membacanya. Kedua-dua jenis halaman digabungkan mengikut turutan menjadi satu dokumen Markdown, itulah sebabnya respons ialah text/markdown dan muat turun berakhir dengan .md.

Kontrak itu baharu untuk penulisan semula ini. Backend Java/Spring Boot lama yang pernah dijalankan projek ini memanggil OCRmyPDF, pendekatan klasik "imej ditambah lapisan teks tersembunyi", dan memulangkan PDF. Penulisan semula dengan Rust menggantikan keseluruhan laluan itu dengan OCR terpilih milik pdf-inspector, dan output turut berpindah daripada PDF kepada Markdown. Backend Java lama sejak itu telah dibuang sepenuhnya daripada repositori; ia bukan suis yang boleh anda hidupkan semula.

Jika anda memerlukan PDF yang boleh dicari (imej berserta lapisan teks), keluaran ini bukan yang anda mahukan. Jika anda memerlukan teks yang boleh dibaca oleh ejen atau pipeline, Markdown itulah tujuannya.

Auto berbanding Force OCR

Borang ini mempunyai medan ocrType:

• Normal (apa-apa selain force-ocr) dipetakan kepada Auto: gunakan teks sedia ada pada tempat fail sudah mempunyainya, dan jalankan OCR pada halaman imej sahaja. Pada PDF digital yang bersih, Auto tidak memuatkan masa jalan OCR.
• Force OCR (ocrType=force-ocr) menjalankan semula pengenalan pada setiap halaman, termasuk halaman yang sudah mempunyai lapisan teks. Pada halaman imej tulen, anda membayar dengan masa, bukan ketepatan tambahan; apa yang anda dapat ialah laluan yang mengabaikan lapisan sedia ada yang rosak atau tidak lengkap.

Lalai portal ialah Force OCR. Tiada kawalan bahasa: kod tessdata yang tertinggal daripada laluan Java lama diabaikan.

Pemisahan Auto/Force berlaku di dalam permintaan itu sendiri, dan baik portal mahupun capability probe API tidak memeriksanya lebih awal untuk anda. GET /api/v1/settings/get-endpoints-status sentiasa melaporkan ocr-pdf sebagai "enabled", tanpa benar-benar mengesahkan sama ada PDFium, ONNX Runtime, atau model PP-OCRv6 telah dipasang. Pemeriksaan sebenar hanya berlaku sebaik sahaja satu permintaan mencetuskan pengenalan: jika mana-mana daripadanya hilang, endpoint memulangkan 503, bukan Markdown yang merosot secara senyap kembali kepada teks asal sahaja. Model PP-OCRv6 Small itu sendiri bersaiz kira-kira 31 MB; melainkan ia telah disemai lebih awal ke dalam cache tempatan semasa deploy, ia akan dimuat turun melalui rangkaian pada kali pertama sesuatu halaman benar-benar memerlukan pengenalan. Mesin luar talian tanpa model yang disemai lebih awal berkemungkinan besar akan gagal terus pada permintaan Force pertamanya, bukan sekadar berjalan perlahan.

Pengenalan bersifat kebarangkalian

Enjin memadankan corak piksel dengan model huruf dan perkataan. Ia berprestasi baik pada cetakan yang bersih, kontras tinggi, dan berfon piawai, tetapi lebih teruk pada:

• Imbasan resolusi rendah atau kontras rendah (kualiti faks berbanding asal 300 DPI)
• Tulisan tangan, fon hiasan, dan susun atur yang ganjil (jadual berbilang lajur, teks diputar, borang padat)
• Halaman yang condong sehingga bentuk glif berubah cukup untuk mengelirukan padanan

Faks yang kabur tidak akan di-OCR seperti imbasan yang bersih, tanpa mengira Auto atau Force. Itu adalah had model itu sendiri, bukan sesuatu yang boleh diperbetulkan oleh parameter.

Apa yang tidak dilakukan oleh OCR

OCR memberikan anda teks. Ia tidak membina semula perenggan, tajuk, jadual, atau dokumen Word yang boleh dialirkan semula. Susun atur yang boleh disunting ialah masalah penukaran yang bertindih dengan ralat pengenalan, bukan tugas yang sama seperti membaca imbasan.

OCR berjalan di sisi pelayan tanpa akaun. Muat turunnya ialah Markdown. Jika lapisan teks sedia ada kelihatan salah, gunakan Force OCR supaya Auto tidak mempercayai lapisan tersebut; untuk menyemak sama ada sesebuah mesin benar-benar mempunyai PDFium dan model itu dipasang, menjalankan permintaan sebenar lebih boleh dipercayai daripada membaca capability probe, kerana probe itu hanya mengesahkan endpoint wujud, bukan runtimenya sudah sedia. Untuk kunci automasi dan OpenAPI, lihat Pembangun.