Standaard OCR-engines zijn gebaseerd op een fundamentele veronderstelling: tekst loopt horizontaal van links naar rechts over de pagina. Deze aanname geldt voor Engels, Spaans, Frans, Duits en de meeste Europese talen. Het faalt volledig voor Japanse tekst die verticaal in traditionele kolommen is geplaatst, voor Chinese tekens waarbij de tekens van boven naar beneden worden gestapeld, en voor Arabische en Hebreeuwse documenten waar de tekst van rechts naar links doorloopt. Het uitvoeren van standaard OCR op deze documenten levert uitvoer op waarbij tekens afzonderlijk worden herkend, maar in de verkeerde volgorde worden samengevoegd, waardoor het resultaat onbruikbaar wordt.
Het vermogen van OCR PDF-engines om niet-standaard tekstaanwijzingen te verwerken is aanzienlijk verbeterd met de nieuwste generatie AI-aangedreven herkenningssystemen. Deze motoren detecteren de tekstoriëntatie voordat ze tot herkenning overgaan, identificeren de leesrichting en reconstrueren de logische leesvolgorde, ongeacht de visuele lay-out. Voor documenten met gemengde tekstrichtingen, zoals een Japans artikel dat horizontale Engelse citaten bevat, schakelt de engine halverwege de pagina over naar een andere modus.
Hoe OCR-engines de tekstrichting detecteren en verwerken
Moderne OCR-engines beginnen met een lay-outanalysestap die tekstgebieden identificeert, hun oriëntatie bepaalt en deze classificeert op basis van leesrichting. Voor horizontale tekst detecteert de engine de basislijn en groepeert tekens daarlangs. Voor verticale tekst detecteert de engine de verticale as en groepeert tekens in kolommen. Voor tekst die van rechts naar links wordt geschreven, identificeert de engine de dominante tekenset en keert de standaardwoordvolgorde van links naar rechts om.
Detectie van tekstrichting is afhankelijk van verschillende signalen. De aanwezigheid van specifieke Unicode-tekenreeksen geeft waarschijnlijke talen en hun typische tekstrichtingen aan. De ruimtelijke rangschikking van gedetecteerde karakters, of ze nu horizontale lijnen of verticale kolommen vormen, levert lay-outbewijs op. De beeldverhouding van tekenkaders biedt een derde signaal: Latijnse tekens zijn doorgaans breder dan hoog, terwijl CJK-tekens ruwweg vierkant zijn en Arabische tekens horizontaal op elkaar aansluiten op een manier die de leesrichting onthult.
De meest betrouwbare OCR-engines combineren alle drie de signaaltypen. Een document dat zowel het Arabische schrift, wat van rechts naar links lezen impliceert, als het Latijnse schrift, wat van links naar rechts impliceert, bevat, vereist dat de engine elk tekstgebied afzonderlijk analyseert. Een correct geconfigureerde pijplijn Extract PDF Data voor meertalige documenten omvat richtingsdetectie per regio in plaats van één enkele richting op de hele pagina toe te passen.
Elk schrijfsysteem vereist een fundamenteel andere OCR-configuratie.
OCR-instellingen voor verticale tekst in het Japans, Chinees en Koreaans
Japanse verticale tekst, tategaki genoemd, is het meest voorkomende verticale schrijfsysteem in modern gebruik. Het verschijnt in romans, kranten, traditionele documenten en formele correspondentie. In verticaal Japans worden tekens van boven naar beneden gelezen, waarbij de kolommen van rechts naar links over de pagina lopen. Getallen en woorden in Latijns schrift die in verticale Japanse tekst zijn ingebed, kunnen binnen de verticale stroom worden geroteerd of horizontaal worden geplaatst.
Om verticale Japanse tekst te OCR selecteren, selecteert u een herkenningsengine die expliciet tategaki ondersteunt. Algemene OCR-engines detecteren de tekens mogelijk correct, maar voeren ze in horizontale volgorde van links naar rechts uit, wat rommel produceert. Japans-specifieke OCR-engines begrijpen de op kolommen gebaseerde leesvolgorde en voeren tekst uit die op natuurlijke wijze kan worden gelezen. Tesseract, de open-source OCR-engine, heeft verbeterde verticale Japanse ondersteuning toegevoegd in versie 5, en verschillende commerciële zoekmachines bieden deze nu aan.
Voor Chinese verticale tekst, die voorkomt in traditionele publicaties, kalligrafie en sommige formele documenten, is de herkenningsuitdaging vergelijkbaar, maar is de tekenset groter. Vereenvoudigd Chinees gebruikt bij algemeen gebruik ongeveer 7.000 tekens, terwijl traditioneel Chinees er meer dan 13.000 gebruikt. De OCR-engine moet niet alleen de verticale lay-out detecteren, maar ook onderscheid maken tussen visueel vergelijkbare karakters die alleen verschillen in lijndetails.
Koreaanse verticale tekst is zeldzaam in moderne documenten, maar komt voor in historische teksten en enkele traditionele publicaties. Het Koreaanse alfabet, Hangul, verzamelt individuele letters in lettergreepblokken, en bij verticaal schrijven worden deze blokken van boven naar beneden gestapeld. OCR-engines die Koreaanse verticale tekst verwerken, moeten de lettergreepblokstructuur herkennen, evenals de afzonderlijke lettercomponenten binnen elk blok.
OCR-instellingen voor tekst van rechts naar links in het Arabisch, Hebreeuws en Perzisch
Arabische OCR biedt unieke uitdagingen die verder gaan dan tekstrichting. Arabisch is een cursief schrift waarbij de meeste letters verbinding maken met hun buren, en de lettervorm verandert afhankelijk van de positie in het woord: initieel, mediaal, definitief of geïsoleerd. De OCR-engine moet deze contextuele vormen herkennen en deze aan het juiste abstracte karakter toewijzen. Gemiste verbindingen of valse verbindingen tussen letters veroorzaken herkenningsfouten die specifiek zijn voor cursieve scripts.
Wanneer u Hebreeuwse OCR selecteert, is het script niet cursief, maar bevat het klinkerpunten, niqqud genaamd, die verschijnen als punten en streepjes boven, onder of binnen letters. Deze klinkertekens zijn klein, doorgaans 2 tot 4 pixels in een gescande afbeelding, en gaan gemakkelijk verloren tijdens binarisatie. Een OCR-engine die niet expliciet met niqqud omgaat, herkent de medeklinkers correct, maar laat de klinkertekens achterwege, waardoor tekst ontstaat die een menselijke lezer kan begrijpen, maar die technisch onvolledig is.
Perzisch en Urdu gebruiken uitgebreide versies van het Arabische schrift met extra karakters. Een OCR-engine die alleen in het Arabisch is getraind, zal deze extra tekens missen of ze ten onrechte als soortgelijke Arabische letters herkennen. Wanneer u een OCR-engine voor deze talen selecteert, controleer dan of deze specifiek ondersteuning biedt voor de exacte taal en scriptvariant die uw document gebruikt, en niet alleen voor het Arabische schrift in het algemeen.
Omgaan met documenten in gemengde richting
Veel echte documenten combineren meerdere tekstrichtingen op dezelfde pagina. Een Japans technisch artikel kan verticale Japanse hoofdtekst, horizontale Engelse bijschriften van figuren en wiskundige vergelijkingen bevatten die hun eigen lay-outregels volgen. Een Arabische zakelijke brief kan een Engels bedrijfsnaam en adresblok bevatten in de indeling van links naar rechts, boven de hoofdtekst van rechts naar links.
Voor documenten in gemengde richting is de OCR-voorverwerkingsstap van cruciaal belang. Het document moet worden gesegmenteerd in tekstgebieden en elk gebied moet onafhankelijk worden geclassificeerd voor de tekstrichting voordat de herkenning begint. Handmatige regioselectie levert vaak betere resultaten op dan automatische segmentatie voor complexe lay-outs. Teken kaders rond elk tekstgebied en wijs aan elk kader de juiste taal en richting toe.
Na OCR verifieert u de uitvoer door tekst te controleren die richtingsgrenzen overschrijdt. Een veel voorkomende fout bij OCR in gemengde richtingen is dat de grens tussen twee tekstgebieden verkeerd wordt weergegeven, zodat het laatste woord van een gebied van links naar rechts wordt toegevoegd aan het begin van een gebied van rechts naar links, of omgekeerd. Door deze grensgebieden steekproefsgewijs te controleren, worden lay-outsegmentatiefouten opgespoord die anders verwarrende uitvoer zouden opleveren.
Post-OCR-verwerking voor niet-standaard tekstrichtingen
Nadat de OCR is voltooid, moet de herkende tekst mogelijk opnieuw worden gerangschikt om een natuurlijke leesvolgorde te verkrijgen. Sommige OCR-engines voeren verticale Japanse tekst uit in de volgorde waarin deze werd herkend, van boven naar beneden in elke kolom, kolom voor kolom, van links naar rechts. Deze volgorde komt niet overeen met de oorspronkelijke leesvolgorde, namelijk kolom voor kolom van rechts naar links. Een nabewerkingsstap die de kolommen opnieuw ordent, zorgt voor de juiste leesvolgorde.
Voor documenten met Gescande PDF-inhoud die bidirectionele tekst en Arabisch met ingesloten Engelse termen bevat, specificeert het Unicode Bidirectionele Algoritme hoe de weergavevolgorde moet worden bepaald. OCR-uitvoer moet bidirectionele Unicode-stuurtekens bevatten of het algoritme volgen, zodat tekst correct wordt weergegeven wanneer deze wordt geplakt in toepassingen die bidirectionele tekst ondersteunen.
WukongPDF biedt OCR-verwerking via de browser voor gescande PDF's, met taalselectieopties die ondersteuning bieden voor de belangrijkste rechts-naar-links- en verticale schrijfsystemen. Door de OCR op een voorbeeldpagina te testen voordat u het volledige document verwerkt, kunt u controleren of de tekstrichting correct wordt verwerkt.
Voor documenten die zowel verticale als horizontale tekst op dezelfde pagina bevatten, zoals een Japanse tijdschriftindeling waarbij het hoofdartikel verticaal is maar de bijschriften en zijbalken horizontaal zijn, levert handmatige zonering de meest nauwkeurige OCR-resultaten op. Teken afzonderlijke herkenningszones voor de verticale en horizontale gebieden, wijs aan elk de juiste tekstrichting toe en voer OCR uit op het gezoneerde document. De extra tijd die aan zonering wordt besteed, betaalt zich terug in de nauwkeurigheid van de herkenning.
Houd er bij het verwerken van historische documenten met niet-standaard tekstlay-outs rekening mee dat de OCR-nauwkeurigheid lager is dan bij moderne gedrukte documenten. Historische lettertypen, onregelmatige afdrukken, verouderd papier met verkleuring en niet-standaard tekenvarianten verminderen allemaal het vertrouwen in herkenning. Voor wetenschappelijk of archiefwerk dient u de OCR-uitvoer te beschouwen als een startpunt voor handmatige transcriptie in plaats van als een eindproduct.
Sommige OCR-engines ondersteunen een trainingsmodus waarin u voorbeelden geeft van het specifieke lettertype of de handschriftstijl die in uw document wordt gebruikt. Door de engine op een paar representatieve pagina's te trainen, wordt de herkenningsnauwkeurigheid in het hele document verbeterd. Deze aanpak is vooral handig voor documenten die in ongebruikelijke lettertypen zijn gedrukt of voor verzamelingen documenten van dezelfde uitgever waarbij de typografie consistent is over meerdere volumes.
Nadat de OCR is voltooid op een rechts-naar-links-document, controleert u of de tekstrichting correct is door een paar zinnen uit de uitvoer te kopiëren en deze in een toepassing te plakken die bidirectionele tekst ondersteunt, zoals Microsoft Word of Google Docs. Als de tekst in omgekeerde volgorde wordt weergegeven, heeft de OCR-engine de richting van rechts naar links niet correct toegepast en moet de uitvoer opnieuw worden verwerkt met gecorrigeerde richtingsinstellingen.
De tijd die wordt geïnvesteerd in het instellen van de juiste OCR-parameters voor niet-standaard tekstrichtingen betaalt zich onmiddellijk terug in de nauwkeurigheid van de herkenning. Een document dat 30 minuten handmatige correctie nodig heeft na slechte OCR, heeft mogelijk slechts 5 minuten opschoning nodig na correct geconfigureerde OCR.
| Schrijfsysteem | Richting | OCR-enginevereisten | Belangrijke uitdaging |
|---|---|---|---|
| Japans (tategaki) | Kolommen van boven naar beneden en van rechts naar links | Motor met expliciete Tategaki-ondersteuning | Gemengd horizontaal Engels in verticale stroom |
| Chinees (traditioneel) | Verticale kolommen, van rechts naar links | Grote tekenset (13.000+) | Visueel vergelijkbare karakters |
| Arabisch | Van rechts naar links, cursieve verbinding | Arabische scriptengine met positionele vormen | Contextuele lettervormen; diakritische tekens |
| Hebreeuws | Van rechts naar links, met niqqud | Hebreeuwse scriptengine met klinkerondersteuning | Kleine klinkertekens gaan verloren bij binarisering |
| Perzisch / Urdu | Van rechts naar links, uitgebreid Arabisch | Taalspecifieke engine | Extra tekens buiten de Arabische set |