BookTranslator
BookTranslator

OCR di testo verticale in giapponese: preservare l'ordine delle colonne e gestire il furigana

Estrai testo verticale in giapponese con le giuste impostazioni di layout, separa il furigana dal testo principale e confronta i risultati OCR reali con campioni scaricabili.

BookTranslator

BookTranslator Team

14 min read

Per l'OCR di testo verticale in giapponese, controlla la direzione di scrittura prima di modificare i filtri dell'immagine. Utilizza un modello giapponese e un'impostazione di segmentazione in grado di gestire il testo verticale, verifica le colonne nell'ordine previsto e decidi se hai bisogno solo del testo principale o anche del furigana. Una pagina piena di caratteri riconoscibili può comunque essere una trascrizione inutilizzabile se la loro sequenza è errata.

Abbiamo eseguito un piccolo esperimento locale e riproducibile per rendere concrete queste decisioni. Una configurazione orizzontale ha scombinato le nostre tre colonne verticali. Una configurazione verticale ha recuperato il testo principale in chiaro, ma l'aggiunta del furigana ha modificato due segni di punteggiatura e il ritaglio del ruby non ha eliminato gli errori di punteggiatura.

Questi sono i risultati di un campione sintetico volutamente piccolo, non una dichiarazione di accuratezza su tutti i libri giapponesi. La lezione utile è più specifica: valuta separatamente il riconoscimento dei caratteri, l'ordine di lettura e la gestione delle annotazioni. Non inviare il risultato alla traduzione solo perché sembra giapponese.

Per prima cosa identifica il testo che desideri effettivamente

Nella composizione verticale giapponese convenzionale, i caratteri procedono verso il basso lungo una linea e le linee procedono da destra a sinistra. Il ruby è il testo più piccolo associato ai caratteri di base; il furigana fornisce comunemente la loro pronuncia. I Requisiti per il layout del testo giapponese del W3C descrivono queste direzioni di scrittura e le relazioni con il ruby.

Prima dell'OCR, etichetta le regioni significative della pagina:

  • colonne verticali principali;
  • piccolo ruby accanto al corpo del testo;
  • intestazioni orizzontali, didascalie o tabelle;
  • numeri di pagina e testatine correnti;
  • note marginali o pagine adiacenti non correlate.

Non trattare ogni striscia verticale come un paragrafo indipendente. Una striscia di piccoli kana accanto a 図書館 potrebbe essere la sua lettura, としょかん, non la frase successiva.

Scegli la politica di output prima di giudicare l'OCR:

Compito del lettoreRisultato desideratoCosa costituisce un problema
Cerca o traduci il testo principaleTesto principale in ordine; letture utili salvate separatamenteRuby inseriti nella prosa, testo del corpo omesso, colonne riordinate
Studio della pronunciaTesto principale più letture correttamente associateRuby mancanti o lettura associata alla parola sbagliata
Produci una trascrizione fedeleTesto principale, relazioni delle annotazioni e decisioni editoriali preservateEliminazione silenziosa o normalizzazione del materiale che intendevi conservare

Lo stesso output può superare un'attività e fallire un'altra. Il nostro esperimento usa trascrizione del solo corpo come obiettivo di confronto. Non considera accettabile la mancanza di furigana per un'edizione di studio della pronuncia.

Un vero esperimento di OCR a tre frasi

Il campione utilizza queste frasi scritte autonomamente:

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

Describono la lettura in biblioteca, la visione di un fiume su una vecchia mappa e l'incontro con un amico in stazione. Ci sono 34 punti di codice Unicode del testo principale quando le interruzioni di riga vengono rimosse, inclusi i tre punti fermi giapponesi.

Abbiamo reso lo stesso corpo in tre forme:

  1. Testo orizzontale.
  2. Tre colonne verticali, lette da destra a sinistra.
  3. Le stesse colonne verticali con furigana accanto a 図書館, 地図, 友人, e 駅.

Campione OCR giapponese sintetico con tre colonne verticali lette da destra a sinistra e furigana più piccoli alla destra delle parole selezionate.

Queste sono immagini didattiche pulite, non pagine scansionate da un libro. Il motore di rendering utilizza Noto Sans CJK JP, caratteri del corpo a 64 pixel, ruby a 24 pixel e posizionamento verticale semplificato glifo per glifo. Disegna punti fermi verticali come piccoli cerchi contornati in posizioni scelte manualmente anziché utilizzare il corretto posizionamento dei glifi verticali del carattere; i risultati della puncutazione quindi non stabiliscono le prestazioni dell'OCR su un libro impaginato correttamente. Non riproduce ogni regola di impaginazione giapponese. Nel test non sono presenti sfocature, distorsioni, texture della carta, scrittura a mano, caratteri storici o pagine a direzione mista.

Motore, modelli e impostazioni

L'esperimento è stato eseguito il 7 settembre 2026, utilizzando Tesseract.js 7.0.0 con Tesseract.js-core 7.0.0 localmente su macOS ARM64. Tutte le chiamate riuscite hanno utilizzato i modelli ufficiali tessdata_fast al commit 87416418657359cb625c412a48b6e1d6d41c29bd, con OEM 1, la modalità motore basata solo su LSTM.

Il repository di modelli ufficiale di Tesseract fornisce file jpn e jpn_vert separati. La sua documentazione descrive PSM 5 come un blocco uniformemente allineato in verticale e PSM 6 come un blocco di testo uniforme; scegli un'ipotesi di segmentazione adatta alla regione da riconoscere. Vedi la pagina della documentazione sulla segmentazione della pagina.

I nostri casi registrati hanno utilizzato jpn con PSM 6 per il testo orizzontale, jpn_vert con PSM 5 per il testo verticale e un controllo verticale deliberatamente non corrispondente jpn/PSM 6. Sia il modello che la segmentazione cambiano tra le due configurazioni verticali, quindi si tratta di un confronto tra flussi di lavoro, non di un esperimento che isola l'effetto di una singola impostazione.

Un tentativo iniziale con tessdata_best si è interrotto nel core WebAssembly disponibile prima di produrre testo OCR. Siamo passati ai modelli ufficiali interi tessdata_fast per motivi di compatibilità e abbiamo registrato tale errore. Nessuna conclusione sull'accuratezza di una famiglia di modelli deriva da tale passaggio.

Cosa è tornato effettivamente

Il confronto rimuove gli spazi bianchi e applica la normalizzazione Unicode NFC. non sostituisce la punteggiatura, corregge i kanji o riorganizza il testo. Gli output grezzi completi e gli hash di versione/modello, il CSV di confronto del corpo, e le annotazioni degli errori sono scaricabili.

Input e configurazioneRisultato osservato rispetto all'obiettivo limitato al corpo
Orizzontale, jpn, PSM 6Tutti i 34 punti di codice hanno corrisposto dopo la rimozione degli spazi bianchi
Verticale, jpn, controllo PSM 6L'output si è esteso su più colonne e ha incluso sostituzioni di caratteri; prosa non utilizzabile
Verticale, jpn_vert, PSM 5Tutti i 34 punti di codice hanno corrisposto dopo la rimozione degli spazi bianchi; l'ordine delle colonne era corretto
Verticale con furigana, jpn_vert, PSM 5Il testo principale è rimasto in ordine, ma due 。 segni sono diventati ASCII .; i ruby non sono stati restituiti come letture separate
Tre ritagli di colonne del corpo dall'immagine con furigana, jpn_vert, PSM 5La prima colonna è terminata con ., la seconda con ,, la terza con 。; il ritaglio non ha rimosso tutti i difetti di punteggiatura

Ad esempio, il caso con furigana ha restituito questa prima riga:

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

Gli spazi vengono ignorati dalla nostra regola di confronto dichiarata, mentre la punteggiatura finale no. Un flusso di lavoro basato solo sulla ricerca potrebbe tollerare questa differenza, ma una trascrizione fedele dovrebbe registrarla e correggerla.

Il controllo verticale non corrispondente è iniziato con 明 古 昌, saltando tra i caratteri superiori delle colonne anziché seguire la prima frase prevista. Il suo output illustra perché il riconoscimento di singoli simboli non equivale alla ricostruzione di una sequenza di lettura.

Ci sono state sette chiamate OCR completate: quattro casi di intera immagine e tre ritagli. Abbiamo conservato ogni output. Un agente ha confrontato i risultati con la verità fondamentale autoriale e ha ispezionato visivamente le immagini; non c'è stata alcuna revisione umana in cieco o un ampio corpus di benchmark. L'esperimento non stabilisce un motore universalmente migliore, un tasso di accuratezza a livello di libro o le prestazioni sulla tua scansione.

Usa un flusso di lavoro basato prima sulle regioni sulla tua pagina

1. Conserva la fonte e scegli una pagina difficile

Mantieni l'immagine originale o il PDF inalterati. Lavora su una copia e annota il numero di pagina. Scegli una pagina che contenga il problema che stai cercando di risolvere: ruby densi, un margine stretto, un'intestazione orizzontale sopra il testo verticale o caratteri insolitamente piccoli.

Una pagina del titolo pulita non è un test di accettazione utile per un libro le cui pagine del corpo hanno un layout diverso. Se la fonte è un PDF, estrai o rendi la pagina selezionata usando uno strumento di cui ti fidi prima di eseguire un flusso di lavoro OCR solo per immagini. Gli script di questo articolo accettano file PNG; non elaborano PDF né creano livelli PDF ricercabili.

Per l'intero processo di preparazione e traduzione di documenti scansionati, usa il più ampio flusso di lavoro per PDF scansionati. Questa guida si concentra sulla direzione del giapponese, sulla segmentazione, sui ruby e sulle decisioni di trascrizione.

2. Correggi i difetti di cattura senza distruggere i piccoli caratteri

Ispeziona i caratteri reali a un livello di zoom utile. Raddrizza l'inclinazione non intenzionale, rimuovi i bordi di pagina non correlati e conserva abbastanza contrasto per distinguere piccoli kana e punteggiatura. Evita di trattare una soglia aggressiva o la nitidezza come un miglioramento automatico: confronta l'immagine risultante con l'originale prima di fidarti dell'OCR.

La guida sulla qualità delle immagini di Tesseract copre risoluzione, rumore, inclinazione e bordi. Questi aspetti sono separati dalla direzione di scrittura. Correggere l'inclinazione di una pagina fotografata ad angolo non è la stessa operazione di ruotare lateralmente il testo verticale giapponese orientato correttamente.

I file di esempio contengono metadati a 300 dpi, ma quel numero non crea dettagli mancanti. La loro dimensione reale dei glifi del corpo è di 64 pixel. Una foto a bassa risoluzione etichettata come "300 dpi" rimane comunque la stessa foto a bassa risoluzione.

3. Separa le regioni quando la pagina viola un presupposto di layout

Prova prima il blocco verticale principale da solo, prima di chiedere a una singola chiamata OCR di gestire un titolo orizzontale, prosa verticale, un'illustrazione e un numero di pagina. Mantieni un registro semplice delle regioni, come "pagina 12, corpo, colonna 1 da destra". Questo registro rende verificabile l'assemblaggio successivo.

Per materiale a direzione mista, riconosci la regione orizzontale con l'impostazione orizzontale appropriata e la regione verticale con un'impostazione verticale, quindi assemblale nell'ordine previsto dal documento. Questo è un flusso di lavoro consigliato da testare sul tuo file, non una capacità di layout misto misurata dalle nostre tre immagini di esempio.

Il nostro esperimento di ritaglio ha utilizzato coordinate esatte note per escludere la striscia di ruby accanto a ciascuna colonna sintetica, mantenendo al contempo il testo del corpo e un margine bianco. Si è trattato di una dimostrazione di selezione manuale delle regioni, non di un algoritmo automatico di rimozione dei ruby. Non applicare le sue coordinate alla pagina di un libro reale.

4. Controlla le colonne prima di correggere i singoli caratteri

Confronta il primo e l'ultimo carattere del corpo di ciascuna colonna, procedendo nella direzione prevista. Conferma che nessuna colonna sia mancante, duplicata, invertita o confusa con quella vicina. Quindi ispeziona le frasi ai confini delle colonne.

Solo dopo potrete correggere singoli kanji, kana, punteggiatura, numeri e nomi. In caso contrario, potreste perdere tempo a rifinire frammenti assemblati nel paragrafo sbagliato.

Una utile revisione in tre passate consiste in:

  1. Regioni e ordine: ogni regione di testo prevista è presente una sola volta e in sequenza.
  2. Caratteri: confrontate l'immagine effettiva con il testo, inclusi la piccola punteggiatura e i segni kana.
  3. Annotazioni: decidete se ogni elemento ruby, nota o etichetta marginale debba essere preservato, separato o deliberatamente escluso.

Il valore di confidenza di un motore non sostituisce questi controlli. Il nostro controllo scombinato restituiva comunque un valore di confidenza segnalato dal motore; ciò non rendeva accettabile il suo ordine di lettura.

Non rimuovete il furigana finché non sapete perché

Per un'estrazione incentrata solo sul corpo del testo, i caratteri ruby non dovrebbero trasformarsi accidentalmente in un secondo livello di prosa. Tuttavia, eliminare ogni piccola stringa di kana non è una regola generale sicura. Una lettura può aiutare a disambiguare un nome, preservare la pronuncia scelta da un autore o supportare il compito di studio del lettore.

Nella nostra immagine con furigana, l'output OCR conteneva i kanji principali ma non restituiva le quattro letture come un set di annotazioni separato. Ciò potrebbe essere sufficiente dopo la correzione della punteggiatura per un'attività di ricerca basata solo sul testo principale. Non è sufficiente se il risultato promesso include informazioni sulla pronuncia.

Memorizzate le letture importanti separatamente e associatele alla corretta occorrenza. Per esempio:

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

La trascrizione ruby separata del campione rende tale criterio esplicito. Si tratta di una verità di riferimento creata insieme all'immagine, non di una dichiarazione di successo dell'OCR.

Se l'OCR mescola i kana in una parola o ne perde l'associazione, confrontate con l'immagine e riparate la trascrizione. Non chiedete a un modello linguistico di indovinare la fonte e di presentare l'intuizione come testo recuperato. Segnate invece una lettura incerta per la revisione.

I risultati del ritaglio argomentano inoltre contro una regola semplicistica del tipo "rimuovi il ruby e tutto migliora": sono rimaste due differenze di punteggiatura e le conclusioni delle frasi interessate sono cambiate. Tale osservazione appartiene a questo specifico campione pulito. Ci dice di verificare il risultato dopo la segmentazione, non che il ritaglio aiuti o danneggi generalmente l'OCR.

Riproducete il test o mantenete un registro di revisione

Scaricare il README dell'esperimento per le fonti di modelli e font bloccate, le versioni delle dipendenze, le descrizioni dei file e i comandi. Il generatore di campioni, esecutore OCR, e script di confronto separano la creazione delle immagini, il riconoscimento e la valutazione.

Lo script di esecuzione utilizza la documentata API worker di Tesseract.js. Per una regione verticale, le sue impostazioni essenziali sono:

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 deve contenere il file scaricato e decompresso jpn_vert.traineddata. Questo è un estratto, non il programma completo; lo script fornito salva anche i risultati grezzi e termina i worker.

Se utilizzi un'altra applicazione OCR, mantieni le stesse evidenze anche quando i nomi delle impostazioni differiscono: regione di origine, file originale, versione del modello o dello strumento, direzione, scelta di segmentazione, output effettivo, testo corretto e caratteri irrisolti. Il modello di registro di revisione è vuoto in modo da non sottintendere che le tue pagine abbiano già superato il controllo.

Non convertire il nostro piccolo risultato di corrispondenza esatta in una percentuale promessa per un intero romanzo. Font diversi, colonne affollate, forme storiche, scansioni di bassa qualità e nuvole di dialogo dei manga richiedono test rappresentativi propri. Il layout dei manga e il riconoscimento della scrittura manoscritta esulano da questo esperimento.

Traduci solo quando la fonte recuperata è affidabile

Se il tuo obiettivo è la ricerca, la copia di citazioni o la consultazione del dizionario, il testo giapponese verificato potrebbe essere il risultato finale. Non è necessario tradurre un intero documento semplicemente perché è stato coinvolto l'OCR.

Se una barriera linguistica impedisce ancora la lettura e disponi di un file utilizzabile che puoi caricare, procedi con il flusso di traduzione PDF. Conserva la scansione originale e la trascrizione verificata in modo da poter distinguere gli errori di riconoscimento dagli errori di traduzione. Il runner di esempio produce file di testo e TSV, non un PDF pronto per il caricamento automatico; prepara il formato di input effettivo richiesto dal tuo strumento successivo.

La modalità OCR di BookTranslator ricostruisce il contenuto tradotto anziché garantire il layout verticale originale. Non dare per scontato che preserverà ogni associazione ruby o che riparerà errori di riconoscimento non verificati. Esamina l'ordine di lettura e la formattazione del documento finale utilizzando la guida alla conservazione del formato PDF e la checklist finale di controllo qualità PDF.

Il passaggio di consegne affidabile non è "OCR completato". È "il testo giapponese previsto è presente, la sua sequenza è stata controllata e il trattamento delle annotazioni è documentato".

Post Correlati