Japaanse verticale tekst OCR: Kolomvolgorde behouden en furigana verwerken

Voor OCR van Japanse verticale tekst controleert u de schrijfrichting voordat u afbeeldingsfilters wijzigt. Gebruik een Japans model en segmentatie-instelling die verticale tekst aankan, verifieer de kolommen in de beoogde volgorde en bepaal of u alleen de hoofdtekst of ook de furigana nodig hebt. Een pagina vol herkenbare tekens kan nog steeds een onbruikbare transcriptie zijn als de volgorde verkeerd is.

We hebben een klein, reproduceerbaar lokaal experiment uitgevoerd om die beslissingen concreet te maken. Een horizontale configuratie haalde onze drie verticale kolommen door elkaar. Een verticale configuratie herstelde de platte hoofdtekst, maar het toevoegen van furigana veranderde twee leestekens en het wegsnijden van de ruby elimineerde de leestekenfouten niet.

Dat zijn resultaten van een bewust klein synthetisch voorbeeld, geen nauwkeurigheidsclaim over alle Japanse boeken. De nuttige les is specifieker: evalueer tekenherkenning, leesvolgorde en de verwerking van annotaties afzonderlijk. Stuur het resultaat niet door naar de vertaling alleen omdat het er Japans uitziet.

Identificeer eerst de tekst die u daadwerkelijk wilt

In conventionele Japanse verticale compositie gaan tekens naar beneden langs een regel en gaan regels van rechts naar links. Ruby is de kleinere tekst die is gekoppeld aan basistekens; furigana levert meestal de uitspraak daarvan. W3C's Requirements for Japanese Text Layout beschrijft deze schrijfrichtingen en ruby-relaties.

Label vóór de OCR de zinvolle regio's van de pagina:

• belangrijkste verticale kolommen;
• kleine ruby naast de hoofdtekst;
• horizontale koppen, bijschriften of tabellen;
• paginanummers en kopteksten;
• kanttekeningen of ongerelateerde aangrenzende pagina's.

Behandel niet elke verticale strook als een onafhankelijke paragraaf. Een strook kleine kana naast 図書館 kan de lezing ervan zijn, としょかん, niet de volgende zin.

Kies het uitvoerbeleid voordat u de OCR beoordeelt:

Dezelfde uitvoer kan voor de ene taak slagen en voor de andere falen. Ons experiment gebruikt transcriptie van alleen de hoofdtekst als vergelijkingsdoel. Het beschouwt ontbrekende furigana niet als acceptabel voor een uitspraakstudie-editie.

Een echt OCR-experiment met drie zinnen

Het voorbeeld gebruikt deze zelfgeschreven zinnen:

朝の図書館で本を読む。
古い地図には川が見える。
明日は友人と駅で会う。

Ze beschrijven het lezen in een bibliotheek, het zien van een rivier op een oude kaart en het ontmoeten van een vriend op een station. Er zijn 34 Unicode-tekens in de hoofdtekst wanneer de regelovergangen worden verwijderd, inclusief de drie Japanse punten.

We hebben dezelfde hoofdtekst in drie vormen weergegeven:

1. Horizontale tekst.
2. Drie verticale kolommen, van rechts naar links gelezen.
3. Dezelfde verticale kolommen met furigana naast 図書館, 地図, 友人, en 駅.

Dit zijn schone lesafbeeldingen, geen gescande pagina's uit een boek. De renderer gebruikt Noto Sans CJK JP, hoofdteksttekens van 64 pixels, ruby van 24 pixels en een vereenvoudigde glyph-voor-glyph verticale plaatsing. Het tekent verticale punten als kleine omijnde cirkels op handmatig gekozen posities in plaats van de juiste verticale glyph-positionering van het lettertype te gebruiken; de resultaten van de punctuatie tonen daarom niet hoe OCR presteert op een correct opgemaakt boek. Het reproduceert niet elke Japanse opmaakregel. Er is geen vervaging, schuinte, papierstructuur, handschrift, historisch type of pagina met gemengde richtingen in de test.

Engine, modellen en instellingen

Het experiment werd uitgevoerd op 7 september 2026, met Tesseract.js 7.0.0 en Tesseract.js-core 7.0.0 lokaal op macOS ARM64. Alle succesvolle aanroepen maakten gebruik van de officiële tessdata_fast modellen op commit 87416418657359cb625c412a48b6e1d6d41c29bd, met OEM 1, de LSTM-only enginemodus.

Tesseract's officiële modellenrepository levert aparte jpn en jpn_vert bestanden. De documentatie beschrijft PSM 5 als een uniform verticaal uitgelijnd blok en PSM 6 als een uniform tekstblok; kies een segmentatie-aanname die past bij het te herkennen gebied. Zie de paginasegmentatiedocumentatie.

Onze geregistreerde gevallen gebruikten jpn met PSM 6 voor horizontale tekst, jpn_vert met PSM 5 voor verticale tekst, en een bewust niet-overeenkomende jpn/PSM 6 verticale controlegroep. Zowel het model als de segmentatie veranderen tussen de twee verticale configuraties, dus dit is een workflow-vergelijking, geen experiment dat het effect van een van beide instellingen afzonderlijk isoleert.

Een eerste poging met tessdata_best werd afgebroken in de beschikbare WebAssembly-kern voordat er OCR-tekst werd geproduceerd. We zijn overgeschakeld op de officiële integer tessdata_fast modellen voor compatibiliteit en hebben die fout geregistreerd. Uit die overstap kan geen conclusie worden getrokken over de nauwkeurigheid van een bepaalde modelfamilie.

Wat er daadwerkelijk terugkwam

De vergelijking verwijdert witruimte en past Unicode NFC-normalisatie toe. Het vervangt geen leestekens, corrigeert geen kanji of rangschikt tekst opnieuw. De volledige ruwe uitvoer en versie-/modelhashes, body-vergelijking CSV, en foutannotaties kunnen worden gedownload.

Het furigana-geval retourneerde bijvoorbeeld deze eerste regel:

Expected: 朝の図書館で本を読む。
Observed: 朝 の 図書 館 で 本 を 読む .

De spaties worden genegeerd door onze vermelde vergelijkingsregel. De uiteindelijke leestekens niet. Een workflow die alleen op zoeken is gericht zou dat verschil kunnen tolereren, maar een getrouwe transcriptie moet dit vastleggen en corrigeren.

De niet-overeenkomende verticale besturing begon met 明 古 昌, waarbij over de bovenste tekens van de kolommen werd gesprongen in plaats van de bedoelde eerste zin te volgen. De uitvoer hiervan illustreert waarom het herkennen van individuele symbolen niet hetzelfde is als het reconstrueren van een leesvolgorde.

Er waren zeven voltooiende OCR-aanroepen: vier gevallen met volledige afbeeldingen en drie bijsnijdingen. We hebben elke uitvoer behouden. Eén agent vergeleek de resultaten met de geschreven grondwaarheid en inspecteerde de afbeeldingen visueel; er was geen verblind menselijk overzicht of breed benchmarkcorpus. Het experiment stelt geen universeel beste engine vast, noch een nauwkeurigheidspercentage op boekniveau of prestaties op uw scan.

Gebruik een regio-eerste workflow op uw eigen pagina

1. Bewaar de bron en kies één moeilijke pagina

Laat de originele afbeelding of pdf ongewijzigd. Werk aan een kopie en noteer het paginanummer. Kies een pagina die het probleem bevat dat u probeert op te lossen: dichte ruby, een smalle marge, een horizontale kop boven verticale tekst of ongewoon kleine typografie.

Een schone titelpagina is geen nuttige acceptatietest voor een boek waarvan de tekstpagina's een andere indeling hebben. Als de bron een pdf is, extraheer of render dan de geselecteerde pagina met een hulpmiddel dat u vertrouwt voordat u een workflow uitvoert die alleen uit afbeeldingen bestaat. De scripts van dit artikel accepteren png-bestanden; ze verwerken geen pdf's en bouwen geen doorzoekbare pdf-lagen op.

Voor het volledige proces van voorbereiding en vertaling van gescande documenten gebruikt u de bredere workflow voor gescande pdf's. Deze gids richt zich op Japanse richting, segmentatie, ruby en transcriptiebeslissingen.

2. Corrigeer opnamefouten zonder kleine tekst te vernietigen

Inspecteer de daadwerkelijke tekens op een bruikbaar zoomniveau. Trek onbedoelde scheefstand recht, verwijder niet-gerelateerde paginaranden en behoud voldoende contrast om kleine kana en leestekens te onderscheiden. Vermijd het behandelen van agressieve drempelwaarden of verscherping als een automatische verbetering: vergelijk de resulterende afbeelding met het origineel voordat u de OCR vertrouwt.

Tesseract's richtlijnen voor afbeeldingskwaliteit behandelen resolutie, ruis, scheefstand en randen. Deze staan los van de schrijfrichting. Het rechtzetten van een pagina die onder een hoek is gefotografeerd is niet dezelfde bewerking als het zijwaarts roteren van rechtopstaande verticale Japanse tekst.

De voorbeeldweergaven bevatten metadata van 300 dpi, maar dat getal creëert geen ontbrekende details. Hun daadwerkelijke hoofdlettergrootte is 64 pixels. Een foto met een lage resolutie die is hernoemd naar '300 dpi' blijft dezelfde foto met een lage resolutie.

3. Scheid regio's wanneer de pagina in strijd is met één indelingsaanname

Probeer het hoofdverticale blok op zichzelf voordat u één OCR-aanroep vraagt om een horizontale titel, verticale proza, een illustratie en een paginanummer te verwerken. Houd een eenvoudig regionaal overzicht bij, zoals 'pagina 12, hoofdtekst, kolom 1 vanaf rechts'. Dat overzicht maakt latere samenstelling controleerbaar.

Voor materiaal met gemengde richtingen herkent u de horizontale regio met de juiste horizontale instelling en de verticale regio met een verticale instelling, om ze vervolgens samen te voegen in de volgorde die het document bedoelt. Dit is een aanbevolen workflow om te testen op uw bestand, geen vermogen met gemengde indeling dat wordt gemeten aan de hand van onze drie voorbeeldafbeeldingen.

Ons bijsnijdexperiment gebruikte exacte bekende coördinaten om de rubystrook naast elke synthetische kolom uit te sluiten, terwijl de hoofdtekst en een witte marge behouden bleven. Het was een demonstratie van handmatige regioselectie, geen automatisch furigana-verwijderingsalgoritme. Pas de coördinaten niet toe op een echte boekpagina.

4. Controleer kolommen voordat u individuele tekens proefleest

Vergelijk de eerste en laatste hoofdtekens van elke kolom en werk daarbij in de beoogde richting. Bevestig dat er geen kolom ontbreekt, gedupliceerd is, is omgedraaid of vermengd is met de buurman. Inspecteer vervolgens zinnen aan de kolomgrenzen.

Pas daarna moet u individuele kanji, kana, leestekens, cijfers en namen corrigeren. Anders besteedt u tijd aan het polijsten van fragmenten die in de verkeerde paragraaf worden geassembleerd.

Een nuttige beoordeling in drie stappen is:

1. Regio's en volgorde: elk beoogd lichaamsgebied is eenmaal en in volgorde aanwezig.
2. Tekens: vergelijk het daadwerkelijke beeld met de tekst, inclusief kleine leestekens en kanatekens.
3. Annotaties: beslis of elk ruby-item, elke notitie of randlabel wordt bewaard, gescheiden of bewust uitgesloten.

De betrouwbaarheidswaarde van een engine is geen vervanging voor deze controles. Onze door elkaar gehusselde besturing gaf nog steeds een door de engine gerapporteerd betrouwbaarheidsnummer terug; dat maakte de leesvolgorde nog niet acceptabel.

Verwijder furigana niet voordat u weet waarom

Voor extractie van alleen de hoofdtekst mag ruby niet per ongeluk een tweede proza-laag worden. Maar het verwijderen van elke kleine kana-string is geen veilige algemene regel. Een lezing kan helpen om een naam te verduidelijken, de door de auteur gekozen uitspraak te behouden of de studiotaak van de lezer te ondersteunen.

In onze furigana-afbeelding bevatte de OCR-uitvoer de hoofdkanji, maar werden de vier lezingen niet geretourneerd als een aparte annotatieset. Dat kan voldoende zijn na leestekencorrectie voor een zoektaak die zich alleen op de hoofdtekst richt. Het is onvoldoende als het te leveren product uitspraakinformatie belooft.

Sla belangrijke lezingen apart op en koppel ze aan de juiste instantie. Bijvoorbeeld:

Page: sample 1
Column: 1 from the right
Base text: 図書館
Reading shown: としょかん
Decision: retain body text; save reading in the annotation record

De afzonderlijke ruby-transcriptie van het voorbeeld maakt dat beleid expliciet. Het is grondwaarheid die samen met de afbeelding is gemaakt, geen bewering van een OCR-succes.

Als de OCR kana in een woord mengt of de associatie verliest, vergelijk dit dan met de afbeelding en herstel de transcriptie. Vraag een taalmodel niet om de bron te raden en de gok te presenteren als herstelde tekst. Markeer een onzekere lezing in plaats daarvan ter beoordeling.

De resultaten van het uitsnijden pleiten ook tegen een simplistische regel van "verwijder ruby en alles verbetert": er bleven twee leestekenverschillen over en de getroffen zinuiteinden veranderden. Die observatie hoort bij dit specifieke schone testobject. Het vertelt ons dat we het resultaat na segmentatie moeten verifiëren, niet dat uitsnijden over het algemeen helpt of schaadt bij OCR.

Reproduceer de test of houd een beoordelingslogboek bij

Download de experiment-README voor vastgelegde model- en lettertypebronnen, afhankelijkheidsversies, bestandsbeschrijvingen en commando's. De voorbeeldgenerator, OCR-loper, en vergelijkingsscript scheidt het maken, herkennen en evalueren van afbeeldingen.

De runner maakt gebruik van de gedocumenteerde Tesseract.js worker-API. Voor een verticale regio zijn de essentiële instellingen:

const worker = await createWorker("jpn_vert", 1, {
  langPath: modelDirectory,
  gzip: false,
  cacheMethod: "none",
});
await worker.setParameters({
  tessedit_pageseg_mode: "5",
  user_defined_dpi: "300",
});

modelDirectory moet het gedownloade, uitgepakte jpn_vert.traineddata bestand bevatten. Dit is een fragment en niet het volledige programma; de meegeleverde runner slaat ook de ruwe resultaten op en beëindigt de workers.

Als u een andere OCR-toepassing gebruikt, behoudt u dezelfde bewijzen, zelfs wanneer de instellingsnamen verschillen: bronregio, originele bestand, model- of toolversie, richting, segmentatiekeuze, daadwerkelijke uitvoer, gecorrigeerde tekst en onopgeloste tekens. Het beoordelingslogboek-sjabloon is leeg zodat het niet suggereert dat uw pagina's al zijn goedgekeurd.

Converteer ons kleine resultaat met exacte overeenkomsten niet naar een beloofd percentage voor een hele roman. Verschillende lettertypen, drukke kolommen, historische vormen, scans van lage kwaliteit en mangaspraakbellen vereisen hun eigen representatieve tests. Mangalayout en herkenning van handgeschreven tekst vallen buiten dit experiment.

Vertaal alleen wanneer de herstelde bron betrouwbaar is

Als uw doel zoeken, het kopiëren van citaten of het raadplegen van een woordenboek is, kan geverifieerde Japanse tekst het eindresultaat zijn. U hoeft een hele document niet te vertalen enkel omdat er OCR bij betrokken was.

Als een taalbarrière het lezen nog steeds verhindert en u over een bruikbaar bestand beschikt dat u kunt uploaden, ga dan verder met de PDF-vertalingsworkflow. Bewaar de originele scan en de gecontroleerde transcriptie zodat u herkenningsfouten kunt onderscheiden van vertaalfouten. De voorbeeldrunner produceert tekst- en TSV-bestanden, en geen PDF die klaar is voor automatische upload; bereid de daadwerkelijke invoernatie vereist door uw volgende tool voor.

De OCR-modus van BookTranslator reconstruëert vertaalde inhoud in plaats van te garanderen dat de oorspronkelijke verticale layout behouden blijft. Ga er niet vanuit dat het elke ruby-associatie zal behouden of niet-gecontroleerde herkenningsfouten zal herstellen. Controleer de leesvolgorde en opmaak van het uiteindelijke document met behulp van de gids voor PDF-opmaakbehoud en de definitieve PDF QA-checklist.

De betrouwbare overdracht is niet “OCR voltooid.” Het is “de beoogde Japanse tekst is aanwezig, de volgorde ervan is gecontroleerd en de behandeling van annotaties is gedocumenteerd.”