Hur OCR läser en skannad PDF – och varför verktyget returnerar Markdown

En skannad PDF lagrar sidorna som rasterbilder: fotografier av text, inte markerbara tecken. OCR (optisk teckenigenkänning) tittar på pixlarna, gissar vilka former som är tecken och producerar riktig text. På PDF123 körs det dels som ett gratis verktyg i webbläsaren, dels som POST /api/v1/misc/ocr-pdf. Svaret är Markdown, inte en omskriven PDF.

Skanningen är fortfarande en bild

OCR varken rengör, skärper eller ersätter bitmappen. En skarp skanning som OCR läser fel ser fortfarande skarp ut. Det var aldrig bilden som var kvalitetsflaskhalsen, utan igenkänningen: byt igenkänningsmotor på samma omgång skanningar och träffsäkerheten kan skifta kraftigt, trots att pixlarna är helt oförändrade.

Klassisk PDF-OCR skriver ett andra, osynligt textlager i linje under bilden, så att markering och sökning landar på rätt ord. Det är vad diagrammet visar, och så arbetar fortfarande många program för skrivbordet.

Vad slutpunkten faktiskt returnerar

Rutten OCR anropar /api/v1/misc/ocr-pdf, som körs på en fristående Rust-modul, pdf-inspector (byggd med dess ocr-funktion). Den skickar inte hela PDF:en till en igenkänningsmodell. pdf-inspector klassificerar först varje sida som antingen redan har extraherbar, inbyggd text eller att den bara är en bild. Sidor med inbyggd text behåller den texten precis som den är och rör aldrig igenkänningsmodellen; sidor som bara är bilder går i stället igenom igenkänningspipelinen – PDFium (samma öppna renderare som Chrome använder internt) rastrerar sidan, och ONNX Runtime kör modellen PP-OCRv6 Small för att läsa den. Båda typerna av sidor fogas samman i ordning till ett enda Markdown-dokument, vilket är anledningen till att svaret är text/markdown och nedladdningen slutar på .md.

Det kontraktet är nytt med den här omskrivningen. Backend:en i Java/Spring Boot som projektet tidigare körde anropade OCRmyPDF, den klassiska metoden med bild plus dolt textlager, och returnerade en PDF. Rust-omskrivningen ersatte den vägen helt med pdf-inspectors selektiva OCR, och samtidigt flyttade utdatan från PDF till Markdown. Den gamla Java-backend:en har sedan dess tagits bort helt ur repot; det är ingen inställning man kan slå tillbaka till.

Om du behöver en sökbar PDF (bild plus textlager) kan den här slutpunkten inte ge dig det. Den ger dig text som en agent eller en datapipeline kan använda direkt.

Auto mot Force OCR

Formuläret har ett fält som heter ocrType:

• Normal (allt annat än force-ocr) motsvarar Auto: använd befintlig text där filen redan har den och kör OCR på de sidor som bara är bilder. I en ren, digitalt skapad PDF laddar Auto inte OCR-motorn.
• Force OCR (ocrType=force-ocr) kör igenkänningen igen på varje sida, även sidor som redan har ett textlager. På sidor som verkligen bara är bilder betalar du med tid, inte med bättre träffsäkerhet; i gengäld får du en genomkörning som bortser från ett trasigt eller ofullständigt befintligt lager.

Standard i portalen är Force OCR. Det finns ingen språkinställning: kvarvarande tessdata-koder från den gamla Java-vägen ignoreras.

Uppdelningen mellan Auto och Force sker inne i själva anropet, och varken portalen eller API:ets kapacitetskontroll kontrollerar det åt dig i förväg. GET /api/v1/settings/get-endpoints-status rapporterar alltid ocr-pdf som aktiverad, utan att faktiskt verifiera att PDFium, ONNX Runtime eller PP-OCRv6-modellen är installerade. Den verkliga kontrollen sker först i det ögonblick ett anrop utlöser igenkänning: saknas något av detta returnerar slutpunkten 503, inte en nedgraderad Markdown som tyst faller tillbaka till enbart inbyggd text. Själva PP-OCRv6 Small-modellen är omkring 31 MB; om den inte har förladdats i den lokala cachen vid driftsättning laddas den ner över nätverket första gången en sida verkligen behöver igenkänning. En maskin som är offline utan förladdad modell kommer med största sannolikhet att misslyckas direkt på sitt första Force-anrop, i stället för att bara gå långsammare.

Igenkänningen är sannolikhetsbaserad

Motorerna matchar pixelmönster mot modeller av bokstäver och ord. De är bra på ren, högkontrastig tryckt text i standardteckensnitt och sämre på:

• Lågupplösta eller lågkontrastiga skanningar (faxkvalitet mot ett original på 300 DPI)
• Handskrift, dekorativa teckensnitt och udda layouter (tabeller i flera kolumner, roterad text, täta formulär)
• Sneda sidor där glyfformerna förvrängs precis tillräckligt för att matchningen ska gå fel

Ett suddigt fax blir inte lika bra igenkänt som en ren skanning, oavsett Auto eller Force. Det är en begränsning i själva modellen, inte något en parameter kan fixa.

Vad OCR inte gör

OCR ger dig text. Den bygger inte upp stycken, rubriker, tabeller eller ett omflödande Word-dokument. Redigerbar layout är ett konverteringsproblem ovanpå igenkänningsfelet, inte samma uppgift som att läsa en skanning.

OCR en PDF körs på servern och kräver inget konto. Nedladdningen är Markdown. Om ett befintligt textlager ser fel ut använder du Force OCR, så att Auto inte litar på lagret; för att kontrollera om en given maskin faktiskt har PDFium och modellen installerade är det säkrare att köra ett riktigt anrop än att lita på kapacitetskontrollens status, eftersom den bara bekräftar att slutpunkten finns, inte att dess körmiljö är redo. För automatiseringsnycklar och OpenAPI, se Utvecklare.