Com llegeix l'OCR un PDF escanejat, i per què aquesta eina retorna Markdown

Un PDF escanejat desa les pàgines com a imatges de mapa de bits: fotografies de text, no caràcters seleccionables. L'OCR (reconeixement òptic de caràcters) mira aquests píxels, endevina quines formes són caràcters i emet text real. A PDF123 s'executa com a eina gratuïta al navegador i com a POST /api/v1/misc/ocr-pdf; la resposta és Markdown, no un PDF reescrit.

L'escaneig continua sent una imatge

L'OCR no neteja, no enfoca ni substitueix el mapa de bits. Un escaneig nítid que l'OCR llegeix malament encara sembla nítid. La imatge no era el coll d'ampolla de la qualitat: ho era el reconeixement. Canvieu el motor de reconeixement sobre el mateix lot d'escaneigs i la precisió pot variar molt, encara que els píxels no s'hagin tocat gens.

L'OCR clàssic sobre PDF hi escriu una segona capa de text invisible, alineada sota la imatge, perquè la selecció i la cerca caiguin sobre les paraules correctes. Això és el que mostra el diagrama, i és com continuen funcionant moltes eines d'escriptori.

Què retorna realment aquest punt de destinació

La ruta OCR crida /api/v1/misc/ocr-pdf, que s'executa sobre un crate de Rust independent, pdf-inspector (compilat amb la seva funció ocr). No passa tot el PDF a un model de reconeixement. Primer, pdf-inspector classifica cada pàgina segons si ja té text natiu extraïble o si és només imatge. Les pàgines amb text natiu conserven aquest text tal qual i mai passen pel model de reconeixement; les pàgines que només són imatge, en canvi, passen pel circuit de reconeixement: PDFium (el mateix motor de renderització de codi obert que fa servir Chrome internament) rasteritza la pàgina, i ONNX Runtime executa el model PP-OCRv6 Small per llegir-la. Els dos tipus de pàgina s'enllacen en ordre en un únic document Markdown, per això la resposta és text/markdown i la baixada acaba en .md.

Aquest contracte és nou d'aquesta reescriptura. El backend en Java/Spring Boot que el projecte feia servir abans cridava OCRmyPDF, l'enfocament clàssic d'«imatge més capa de text oculta», i retornava un PDF. La reescriptura en Rust va substituir del tot aquest camí per l'OCR selectiu de pdf-inspector, i la sortida va passar de PDF a Markdown alhora. El backend antic en Java s'ha eliminat completament del repositori des de llavors; no és un interruptor que es pugui tornar a activar.

Si necessiteu un PDF cercable (imatge més capa de text), aquesta ruta no us el pot donar. Us dona text que un agent o un flux de dades pot consumir directament.

Auto o Force OCR

El formulari té un camp ocrType:

• Normal (qualsevol valor que no sigui force-ocr) es correspon amb Auto: aprofita el text existent allà on el fitxer ja en té i executa l'OCR a les pàgines que només són imatge. En un PDF natiu digital net, Auto no carrega l'entorn d'execució de l'OCR.
• Force OCR (ocrType=force-ocr) torna a executar el reconeixement a cada pàgina, incloses les que ja tenen una capa de text. En pàgines que realment només són imatge, pagueu temps i no pas més precisió; obteniu una passada que ignora una capa existent trencada o parcial.

El valor per defecte del portal és Force OCR. No hi ha cap control d'idioma: els codis tessdata residuals del camí Java antic s'ignoren.

La divisió entre Auto i Force passa dins de la mateixa petició, i ni el portal ni el sondeig de capacitats de l'API ho comproven per endavant. GET /api/v1/settings/get-endpoints-status sempre informa que ocr-pdf està habilitat, sense verificar realment si PDFium, ONNX Runtime o el model PP-OCRv6 estan instal·lats. La comprovació real només passa en el moment en què una petició desencadena el reconeixement: si en falta algun, la ruta retorna 503, no un Markdown degradat que caigui silenciosament a text natiu tot sol. El model PP-OCRv6 Small en si pesa uns 31 MB; llevat que s'hagi precarregat a la memòria cau local en el moment del desplegament, es baixa per xarxa la primera vegada que una pàgina necessita reconeixement de debò. Una màquina sense connexió i sense el model precarregat molt probablement fallarà just en la primera petició amb Force, en lloc de simplement anar més lenta.

El reconeixement és probabilístic

Els motors fan coincidir patrons de píxels amb models de lletres i paraules. Van bé amb impressió neta, d'alt contrast i de tipus estàndard, i pitjor amb:

• Escaneigs de baixa resolució o de poc contrast (qualitat de fax davant d'un original a 300 DPI)
• Escriptura a mà, tipus decoratius i disposicions estranyes (taules a diverses columnes, text girat, formularis densos)
• Pàgines inclinades que deformen els glifs just prou per confondre la coincidència de patrons

Un fax borrós no donarà el mateix resultat d'OCR que un escaneig net, tant si feu servir Auto com Force. Això és una limitació del mateix model, no res que es pugui arreglar amb un paràmetre.

Què no fa l'OCR

L'OCR us dona text. No reconstrueix paràgrafs, encapçalaments, taules ni un document de Word refluïble. Una disposició editable és un problema de conversió que se suma a l'error de reconeixement, no la mateixa feina que llegir un escaneig.

Fes OCR a un PDF s'executa al servidor i no demana compte. La descàrrega és Markdown. Si una capa de text existent sembla incorrecta, feu servir Force OCR perquè Auto no es refiï d'aquella capa; per comprovar si una màquina determinada té realment PDFium i el model instal·lats, és més fiable executar una petició real que confiar en l'estat del sondeig de capacitats, ja que aquest només confirma que la ruta existeix, no que el seu entorn d'execució estigui a punt. Per a les claus d'automatització i l'OpenAPI, vegeu Desenvolupadors.