OCR de texte vertical en japonais : préserver l'ordre des colonnes et gérer les furigana

Pour l'OCR de texte vertical en japonais, vérifiez le sens d'écriture avant de modifier les filtres d'image. Utilisez un modèle japonais et un paramètre de segmentation capable de gérer le texte vertical, vérifiez les colonnes dans leur ordre prévu et décidez si vous avez besoin du texte principal seul ou également des furigana. Une page remplie de caractères reconnaissables peut toujours constituer une transcription inutilisable si leur séquence est erronée.

Nous avons mené une petite expérience locale reproductible pour concrétiser ces décisions. Une configuration horizontale a mélangé nos trois colonnes verticales. Une configuration verticale a récupéré le texte brut, mais l'ajout de furigana a modifié deux signes de ponctuation, et le rognage des caractères ruby n'a pas éliminé les erreurs de ponctuation.

Ce sont les résultats d'un échantillon synthétique délibérément petit, et non une revendication de précision pour tous les livres japonais. La leçon utile est plus précise : évaluez séparément la reconnaissance des caractères, l'ordre de lecture et le traitement des annotations. N'envoyez pas le résultat à la traduction simplement parce qu'il ressemble à du japonais.

Identifiez d'abord le texte que vous souhaitez réellement

Dans la composition verticale japonaise conventionnelle, les caractères progressent vers le bas d'une ligne et les lignes vont de droite à gauche. Le ruby est le texte plus petit associé aux caractères de base ; les furigana fournissent généralement leur prononciation. Les Requirements for Japanese Text Layout du W3C décrivent ces sens d'écriture et ces relations ruby.

Avant l'OCR, étiquetez les zones significatives de la page :

• principales colonnes verticales ;
• petits caractères ruby le long du corps de texte ;
• titres, légendes ou tableaux horizontaux ;
• numéros de page et en-têtes courants ;
• notes marginales ou pages adjacentes non pertinentes.

Ne traitez pas chaque bande verticale comme un paragraphe indépendant. Une bande de petits kana à côté de 図書館 peut être sa lecture, としょかん, et non la phrase suivante.

Choisissez la politique de sortie avant de juger l'OCR :

Le même résultat peut réussir une tâche et en échouer une autre. Notre expérience utilise transcription du corps uniquement comme cible de comparaison. Elle ne considère pas l'absence de furiganas comme acceptable pour une édition dédiée à l'étude de la prononciation.

Une véritable expérience OCR à trois phrases

L'échantillon utilise ces phrases rédigées par nos soins :

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

Elles décrivent la lecture dans une bibliothèque, la vue d'une rivière sur une vieille carte et la rencontre d'un ami à une gare. Il y a 34 points de code Unicode dans le texte du corps une fois les sauts de ligne supprimés, y compris les trois points finaux japonais.

Nous avons rendu le même corps sous trois formes :

1. Texte horizontal.
2. Trois colonnes verticales, lues de droite à gauche.
3. Les mêmes colonnes verticales avec des furiganas à côté de 図書館, 地図, 友人, et 駅.

Ce sont des images pédagogiques propres, et non des pages scannées d'un livre. Le moteur de rendu utilise Noto Sans CJK JP, des caractères de corps de 64 pixels, des rubis de 24 pixels et un placement vertical simplifié glyphe par glyphe. Il dessine les points finaux verticaux sous forme de petits cercles contourés à des positions choisies manuellement plutôt que d'utiliser le positionnement vertical des glyphes propre à la police ; les résultats de ponctuation n'établissent donc pas la performance de l'OCR sur un livre correctement mis en page. Il ne reproduit pas toutes les règles de composition typographique japonaise. Il n'y a ni flou, ni inclinaison, ni texture de papier, ni écriture manuscrite, ni typographie historique, ni page à direction mixte dans le test.

Moteur, modèles et paramètres

L'expérience a été exécutée le 7 septembre 2026, à l'aide de Tesseract.js 7.0.0 avec Tesseract.js-core 7.0.0 en local sur macOS ARM64. Tous les appels réussis ont utilisé l'officiel tessdata_fast modèles au commit 87416418657359cb625c412a48b6e1d6d41c29bd, avec OEM 1, le mode de moteur LSTM uniquement.

Le dépôt de modèles officiel de Tesseract fournit des jpn et jpn_vert fichiers séparés. Sa documentation décrit PSM 5 comme un bloc aligné verticalement de manière uniforme et PSM 6 comme un bloc de texte uniforme ; choisissez une hypothèse de segmentation qui correspond à la région reconnue. Voir la documentation sur la segmentation des pages.

Nos cas enregistrés ont utilisé jpn avec PSM 6 pour le texte horizontal, jpn_vert avec PSM 5 pour le texte vertical, et un contrôle vertical jpn/PSM 6 délibérément incorrect. Le modèle et la segmentation changent tous deux entre les deux configurations verticales, il s'agit donc d'une comparaison de flux de travail, et non d'une expérience isolant l'effet de l'un ou l'autre paramètre.

Une tentative initiale avec tessdata_best a été interrompue dans le noyau WebAssembly disponible avant de produire du texte OCR. Nous sommes passés aux entiers officiels tessdata_fast modèles par souci de compatibilité et avons enregistré cet échec. Aucune conclusion sur la précision d'une famille de modèles ne découle de ce changement.

Ce qui est réellement revenu

La comparaison supprime les espaces et applique la normalisation Unicode NFC. Elle ne remplace pas la ponctuation, ne corrige pas les kanjis et ne réorganise pas le texte. Les sorties brutes et les hachages de version/modèle complets, comparaison de corps CSV, et annotations d'erreur sont téléchargeables.

Par exemple, le cas des furigana a renvoyé cette première ligne :

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

Les espaces sont ignorés par notre règle de comparaison énoncée. Ce n'est pas le cas de la ponctuation finale. Un flux de travail basé uniquement sur la recherche pourrait tolérer cette différence, mais une transcription fidèle doit l'enregistrer et la corriger.

Le contrôle vertical erroné a commencé avec 明 古 昌, sautant par-dessus les caractères supérieurs des colonnes au lieu de suivre la première phrase prévue. Son résultat illustre pourquoi la reconnaissance de symboles individuels ne revient pas à reconstituer une séquence de lecture.

Il y a eu sept appels OCR achevés : quatre cas d'images entières et trois recadrages. Nous avons conservé chaque résultat. Un agent a comparé les résultats avec la vérité terrain de référence et a inspecté visuellement les images ; il n'y a pas eu de double lecture en aveugle ni de vaste corpus de référence. L'expérience n'établit pas un moteur universellement meilleur, un taux de précision au niveau du livre ou des performances sur votre scan.

Utiliser un flux de travail privilégiant les régions sur votre propre page

1. Préserver la source et choisir une page difficile

Conservez l'image originale ou le PDF sans modification. Travaillez sur une copie et notez le numéro de page. Choisissez une page qui contient le problème que vous essayez de résoudre : des furigana denses, une gouttière étroite, un titre horizontal au-dessus d'un texte vertical, ou des caractères inhabituellement petits.

Une page de titre propre n'est pas un test d'acceptation utile pour un livre dont les pages de corps ont une disposition différente. Si la source est un PDF, extrayez ou rendez la page sélectionnée à l'aide d'un outil en qui vous avez confiance avant d'exécuter un flux de travail OCR purement basé sur l'image. Les scripts de cet article acceptent les fichiers PNG ; ils ne traitent pas les PDF et ne génèrent pas de couches PDF interrogeables.

Pour l'ensemble du processus de préparation et de traduction de documents numérisés, utilisez le flux de travail pour PDF numérisés plus large. Ce guide se concentre sur la direction du japonais, la segmentation, les furigana et les décisions de transcription.

2. Corriger les défauts de capture sans détruire les petits caractères

Inspectez les caractères réels à un niveau de zoom utile. Redressez les inclinaisons non désirées, supprimez les bordures de page sans rapport et préservez un contraste suffisant pour distinguer les petits kana et la ponctuation. Évitez de considérer un seuillage ou un nettoiement agressif comme une amélioration automatique : comparez l'image résultante avec l'originale avant de faire confiance à l'OCR.

Les conseils de Tesseract sur la qualité des images couvrent la résolution, le bruit, l'inclinaison et les bordures. Ceux-ci sont distincts du sens d'écriture. Redresser une page photographiée en biais n'est pas la même opération que faire pivoter latéralement du texte japonais vertical orienté vers le haut.

Les fichiers d'exemple comportent des métadonnées de 300 ppp, mais ce chiffre ne recrée pas les détails manquants. La taille réelle de leurs glyphes de corps est de 64 pixels. Une photo à basse résolution réétiquetée « 300 ppp » reste la même photo à basse résolution.

3. Séparer les régions lorsque la page enfreint une hypothèse de mise en page

Essayez d'abord le bloc vertical principal de manière isolée avant de demander à un seul appel OCR de traiter un titre horizontal, de la prose verticale, une illustration et un numéro de page. Conservez un enregistrement simple des régions, tel que « page 12, corps, 1re colonne en partant de la droite ». Cet enregistrement permet de rendre l'assemblage ultérieur auditable.

Pour les documents à directions multiples, reconnaissez la région horizontale avec le paramètre horizontal approprié et la région verticale avec un paramètre vertical, puis assemblez-les dans l'ordre voulu par le document. Il s'agit d'un flux de travail recommandé à tester sur votre fichier, et non d'une capacité de mise en page mixte mesurée par nos trois images d'exemple.

Notre expérience de recadrage a utilisé des coordonnées exactes connues pour exclure la bande de furigana adjacente à chaque colonne synthétique tout en conservant son texte de corps et une marge blanche. Il s'agissait d'une démonstration de sélection manuelle de régions, et non d'un algorithme de suppression automatique de furigana. N'appliquez pas ses coordonnées à la page d'un vrai livre.

4. Vérifier les colonnes avant de relire les caractères individuels

Comparez le premier et le dernier caractère de corps de chaque colonne, en procédant dans la direction prévue. Confirmez qu'aucune colonne ne manque, n'est dupliquée, inversée ou confondue avec sa voisine. Inspectez ensuite les phrases aux frontières des colonnes.

Ce n'est qu'après cela qu'il faut corriger les kanjis individuels, les kannas, la ponctuation, les chiffres et les noms. Sinon, vous risquez de passer du temps à peaufiner des fragments assemblés dans le mauvais paragraphe.

Une révision utile en trois étapes consiste à :

1. Régions et ordre : chaque région de corps voulue est présente une seule fois et dans l'ordre.
2. Caractères : comparer l'image réelle avec le texte, y compris la petite ponctuation et les signes kana.
3. Annotations : décider si chaque élément ruby, note ou étiquette marginale est préservé, séparé ou délibérément exclu.

La valeur de confiance d'un moteur ne remplace pas ces vérifications. Notre contrôle mélangé a tout de même renvoyé un chiffre de confiance rapporté par le moteur ; cela n'a pas rendu son ordre de lecture acceptable.

Ne supprimez pas le furigana sans savoir pourquoi

Pour une extraction réservée au corps du texte, le ruby ne doit pas devenir accidentellement une deuxième couche de prose. Mais supprimer chaque petite chaîne kana n'est pas une règle générale sûre. Une lecture peut aider à désambiguïser un nom, préserver la prononciation choisie par un auteur ou soutenir la tâche d'étude du lecteur.

Dans notre image de furigana, la sortie OCR contenait les kanjis principaux mais ne renvoyait pas les quatre lectures sous forme d'ensemble d'annotations distinct. Cela pourrait suffire après correction de la ponctuation pour une tâche de recherche textuelle. C'est insuffisant si le livrable promet des informations de prononciation.

Stockez les lectures importantes séparément et associez-les à la bonne occurrence. Par exemple :

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

La transcription ruby séparée de l'exemple rend cette politique explicite. C'est une vérité terrain conçue avec l'image, et non une revendication de succès de l'OCR.

Si l'OCR mélange les kana dans un mot ou perd son association, comparez avec l'image et réparez la transcription. Ne demandez pas à un modèle de langue de deviner la source et de présenter cette supposition comme du texte récupéré. Marquez plutôt une lecture incertaine pour révision.

Les résultats du recadrage plaident également contre une règle simpliste selon laquelle « supprimer le ruby et tout s'améliore » : deux différences de ponctuation sont restées, et les fins de phrase concernées ont changé. Cette observation appartient à cet élément propre particulier. Elle nous indique de vérifier le résultat après segmentation, et non que le recadrage aide ou nuit généralement à l'OCR.

Reproduisez le test ou tenez un journal de révision

Téléchargez le fichier README de l'expérience pour connaître les sources de modèles et de polices épinglées, les versions de dépendances, les descriptions de fichiers et les commandes. Le générateur d'exemples, exécuteur d'OCR, et un script de comparaison sépare la création d'images, la reconnaissance et l'évaluation.

Le lanceur utilise l'API documentée du worker Tesseract.js. Pour une région verticale, ses paramètres essentiels sont les suivants :

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 doit contenir le fichier jpn_vert.traineddata téléchargé et décompressé. Il s'agit d'un extrait, et non du programme complet ; le lanceur fourni enregistre également les résultats bruts et met fin aux workers.

Si vous utilisez une autre application d'OCR, conservez les mêmes éléments de preuve même si les noms des paramètres diffèrent : région source, fichier original, version du modèle ou de l'outil, orientation, choix de segmentation, sortie réelle, texte corrigé et caractères non résolus. Le modèle de journal de révision est vide afin de ne pas laisser entendre que vos pages ont déjà été validées.

Ne transformez pas notre résultat infime de correspondance exacte en un pourcentage promis pour un roman entier. Les différentes polices, les colonnes denses, les formes historiques, les numérisations de faible qualité et les bulles de texte de manga nécessitent leurs propres tests représentatifs. La mise en page des mangas et la reconnaissance de l'écriture manuscrite ne font pas partie de cette expérience.

Ne traduisez que lorsque la source récupérée est digne de confiance

Si votre objectif est la recherche, la copie de citations ou la consultation d'un dictionnaire, le texte japonais vérifié peut constituer le résultat final. Vous n'avez pas besoin de traduire un document entier simplement parce qu'un OCR a été utilisé.

Si la barrière de la langue empêche toujours la lecture et que vous disposez d'un fichier utilisable que vous pouvez importer, poursuivez avec le flux de traduction PDF. Conservez la numérisation originale et la transcription vérifiée afin de pouvoir distinguer les erreurs de reconnaissance des erreurs de traduction. Le lanceur d'exemple produit des fichiers texte et TSV, et non un PDF prêt pour un import automatique ; préparez le format d'entrée réel requis par votre prochain outil.

Le mode OCR de BookTranslator reconstitue le contenu traduit plutôt que de garantir la disposition verticale d'origine. Ne présumez pas qu'il préservera chaque association de furigana ni qu'il corrigera les erreurs de reconnaissance non vérifiées. Examinez l'ordre de lecture et la mise en forme du document final à l'aide du guide de préservation du format PDF et de la liste de contrôle finale d'assurance qualité des PDF.

Le transfert fiable n'est pas « OCR terminé. » C'est « le texte japonais souhaité est présent, sa séquence a été vérifiée et le traitement des annotations est documenté. »