OCR de Texto Vertical em Japonês: Preserve a Ordem das Colunas e Lide com o Furigana

Para o OCR de texto vertical em japonês, verifique a direção da escrita antes de alterar os filtros de imagem. Utilize um modelo japonês e uma definição de segmentação capazes de lidar com texto vertical, verifique as colunas na ordem pretendida e decida se precisa apenas do texto principal ou também do furigana. Uma página repleta de carateres reconhecíveis pode continuar a ser uma transcrição inutilizável se a respetiva sequência estiver errada.

Realizámos uma experiência local pequena e reprodutível para tornar essas decisões concretas. Uma configuração horizontal baralhou as nossas três colunas verticais. Uma configuração vertical recuperou o texto principal simples, mas a adição de furigana alterou dois sinais de pontuação e o corte do ruby não eliminou os erros de pontuação.

Estes são resultados de uma amostra sintética deliberadamente pequena e não uma afirmação de precisão sobre todos os livros japoneses. A lição útil é mais restrita: avalie o reconhecimento de carateres, a ordem de leitura e o tratamento de anotações separadamente. Não envie o resultado para tradução apenas porque se parece com japonês.

Primeiro, identifique o texto que realmente pretende

Na composição vertical japonesa convencional, os carateres progridem para baixo numa linha e as linhas avançam da direita para a esquerda. O ruby é o texto mais pequeno associado aos carateres de base; o furigana fornece habitualmente a respetiva pronúncia. O documento Requirements for Japanese Text Layout da W3C descreve estas direções de escrita e relações ruby.

Antes do OCR, identifique as regiões úteis da página:

• colunas verticais principais;
• ruby pequeno ao lado do corpo de texto;
• cabeçalhos horizontais, legendas ou tabelas;
• números de página e cabeçalhos correntes;
• notas marginais ou páginas adjacentes não relacionadas.

Não trate todas as tiras verticais como parágrafos independentes. Uma tira de kana pequeno ao lado de 図書館 pode ser a respetiva leitura, としょかん, e não a frase seguinte.

Escolha a política de saída antes de avaliar o OCR:

O mesmo resultado pode passar numa tarefa e falhar noutra. A nossa experiência utiliza transcrição apenas do corpo como alvo de comparação. Não considera aceitável a falta de furigana para uma edição de estudo da pronúncia.

Uma experiência real de OCR de três frases

A amostra utiliza estas frases de autoria própria:

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

Descrevem a leitura numa biblioteca, a visualização de um rio num mapa antigo e o encontro com um amigo numa estação. Existem 34 pontos de código Unicode de texto do corpo quando as quebras de linha são removidas, incluindo os três pontos finais japoneses.

Apresentámos o mesmo corpo sob três formas:

1. Texto horizontal.
2. Três colunas verticais, lidas da direita para a esquerda.
3. As mesmas colunas verticais com furigana ao lado de 図書館, 地図, 友人, e 駅.

Tratam-se de imagens de ensino limpas, não de páginas digitalizadas de um livro. O renderizador utiliza Noto Sans CJK JP, caracteres de corpo de 64 pixéis, ruby de 24 pixéis e posicionamento vertical glifo a glifo simplificado. Desenha pontos finais verticais como pequenos círculos contornados em posições escolhidas manualmente em vez de utilizar o posicionamento adequado de glifos verticais da fonte; por conseguinte, os resultados da pontuação não determinam o desempenho do OCR num livro devidamente composo. Não reproduz todas as regras de composição tipográfica japonesa. Não existe desfocagem, inclinação, textura de papel, escrita à mão, tipografia histórica ou página de direção mista no teste.

Motor, modelos e definições

A experiência foi executada a 7 de setembro de 2026, utilizando o Tesseract.js 7.0.0 com o Tesseract.js-core 7.0.0 localmente em macOS ARM64. Todas as chamadas bem-sucedidas utilizaram o oficial tessdata_fast modelos no commit 87416418657359cb625c412a48b6e1d6d41c29bd, com OEM 1, o modo de motor exclusivo LSTM.

O repositório oficial de modelos do Tesseract fornece separadamente jpn e jpn_vert ficheiros. A sua documentação descreve o PSM 5 como um bloco alinhado verticalmente uniforme e o PSM 6 como um bloco de texto uniforme; escolha um pressuposto de segmentação que se adapte à região a ser reconhecida. Consulte a documentação de segmentação de páginas.

Os nossos casos registados utilizaram jpn com o PSM 6 para texto horizontal, jpn_vert com o PSM 5 para texto vertical, e um deliberadamente desfasado jpn/PSM 6 controlo vertical. Tanto o modelo como a segmentação mudam entre as duas configurações verticais, pelo que se trata de uma comparação de fluxos de trabalho e não de uma experiência que isole o efeito de qualquer uma das definições isoladamente.

Uma tentativa inicial com tessdata_best foi abortada no núcleo WebAssembly disponível antes de produzir texto OCR. Mudámos para o inteiro oficial tessdata_fast modelos para compatibilidade e registámos essa falha. Nenhuma conclusão sobre a precisão de uma família de modelos decorre dessa mudança.

O que realmente foi devolvido

A comparação remove os espaços em branco e aplica a normalização Unicode NFC. Isto não substitui a pontuação, corrige kanji ou reorganiza o texto. O completo resultados em bruto e hashes de versão/modelo, CSV de comparação de corpo, e anotações de erro podem ser descarregados.

Por exemplo, o caso com furigana devolveu esta primeira linha:

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

Os espaços são ignorados pela nossa regra de comparação estipulada. A pontuação final não é. Um fluxo de trabalho baseado apenas em pesquisa pode tolerar essa diferença, mas uma transcrição fiel deve registrá-la e corrigi-la.

O controlo vertical desfasado começou com 明 古 昌, saltando pelos caracteres superiores das colunas em vez de seguir a primeira frase pretendida. O seu resultado ilustra porque razão reconhecer símbolos individuais não é o mesmo que reconstruir uma sequência de leitura.

Houve sete chamadas de OCR concluídas: quatro casos de imagem inteira e três recortes. Retivemos cada resultado. Um agente comparou os resultados com a verdade básica autoral e inspecionou visualmente as imagens; não houve revisão humana cega nem um corpus de referência alargado. O experiemento não estabelece um motor universalmente melhor, uma taxa de precisão ao nível do livro ou o desempenho na sua digitalização.

Utilize um fluxo de trabalho centrado em regiões na sua própria página

1. Preserve a origem e escolha uma página difícil

Mantenha a imagem original ou o PDF inalterados. Trabalhe numa cópia e registe o número da página. Escolha uma página que contenha o problema que está a tentar resolver: 'ruby' denso, uma medianil horizontal acima de texto vertical, ou tipo de letra unusually pequeno.

Uma página de rosto limpa não é um teste de aceitação útil para um livro cujas páginas de corpo têm um layout diferente. Se a origem for um PDF, extraia ou processe a página selecionada utilizando uma ferramenta em que confie antes de executar um fluxo de trabalho de OCR apenas de imagem. Os scripts deste artigo aceitam ficheiros PNG; não processam PDFs nem criam camadas de PDF pesquisáveis.

Para todo o processo de preparação e tradução de documentos digitalizados, utilize o mais abrangente fluxo de trabalho de PDF digitalizado. Este guia foca-se nas decisões de direção do japonês, segmentação, 'ruby' e transcrição.

2. Corrija defeitos de captura sem destruir texto pequeno

Inspecione os caracteres reais a um nível de zoom útil. Endireite a inclinação não intencional, remova margens de página não relacionadas e preserve contraste suficiente para distinguir kana pequeno e pontuação. Evite tratar a binarização agressiva ou a nitidez como uma melhoria automática: compare a imagem resultante com a original antes de confiar no OCR.

As orientações de qualidade de imagem do Tesseract cobrem resolução, ruído, inclinação e margens. Estas são independentes da direção da escrita. Desinclinar uma página que foi fotografada num ângulo não é a mesma operação que rodar texto japonês vertical de pé para a horizontal.

Os ficheiros de amostra transportam metadados de 300 dpi, mas esse número não cria detalhes em falta. O tamanho real dos glifos do corpo é de 64 pixéis. Uma fotografia de baixa resolução com a etiqueta "300 dpi" continua a ser a mesma fotografia de baixa resolução.

3. Separe regiões quando a página viola um pressuposto de layout

Experimente o bloco vertical principal por si só antes de pedir a uma chamada de OCR para processar um título horizontal, prosa vertical, uma ilustração e um número de página. Mantenha um registo de região simples, como "página 12, corpo, coluna 1 a contar da direita". Esse registo torna a montagem posterior auditável.

Para material de direção mista, reconheça a região horizontal com a definição horizontal adequada e a região vertical com uma definição vertical, e depois monte-as na ordem pretendida pelo documento. Este é um fluxo de trabalho recomendado para testar no seu ficheiro, e não uma capacidade de layout misto medida pelas nossas três imagens de amostra.

A nossa experiência de recorte utilizou coordenadas exatas conhecidas para excluir a faixa de 'ruby' ao lado de cada coluna sintética, mantendo o seu texto de corpo e uma margem branca. Tratou-se de uma demonstração manual de seleção de regiões, e não de um algoritmo automático de remoção de furigana. Não aplique as suas coordenadas a uma página de livro real.

4. Verifique as colunas antes de rever caracteres individuais

Compare o primeiro e o último caracteres do corpo de cada coluna, trabalhando na direção pretendida. Confirme que nenhuma coluna está em falta, duplicada, invertida ou misturada com a vizinha. Em seguida, inspecione as frases nas fronteiras das colunas.

Só depois disso é que deve corrigir kanji individuais, kana, pontuação, números e nomes. Caso contrário, pode perder tempo a polir fragmentos que são montados no parágrafo errado.

Uma revisão útil em três passes é:

1. Regiões e ordem: cada região de corpo pretendida está presente uma vez e em sequência.
2. Caracteres: comparar a imagem real com o texto, incluindo pequena pontuação e marcas de kana.
3. Anotações: decidir se cada item ruby, nota ou rótulo marginal é preservado, separado ou deliberadamente excluído.

O valor de confiança de um motor não substitui estas verificações. O nosso controlo baralhado continuou a devolver um número de confiança relatado pelo motor; isso não tornou a sua ordem de leitura aceitável.

Não remova o furigana até saber porquê

Para extração exclusiva do corpo, o ruby não se deve transformar acidentalmente numa segunda camada de prosa. Mas eliminar cada pequena string de kana não é uma regra geral segura. Uma leitura pode ajudar a desambiguar um nome, preservar a pronúncia escolhida por um autor ou apoiar a tarefa de estudo do leitor.

Na nossa imagem de furigana, a saída de OCR continha os kanji principais, mas não devolveu as quatro leituras como um conjunto de anotações separado. Isso pode ser suficiente após a correção de pontuação para uma tarefa de pesquisa apenas no corpo. É insuficiente se o resultado prometer informação de pronúncia.

Guarde as leituras importantes separadamente e associe-as à ocorrência correta. Por exemplo:

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

A transcrição ruby separada do exemplo torna essa política explícita. É verdade básica (ground truth) criada com a imagem, e não uma alegação de sucesso de OCR.

Se o OCR misturar kana numa palavra ou perder a sua associação, compare com a imagem e repare a transcrição. Não peça a um modelo de linguagem para adivinhar a origem e apresentar o palpite como texto recuperado. Em vez disso, marque uma leitura incerta para revisão.

Os resultados do corte também contrariam uma regra simplista de “remover o ruby e tudo melhora”: duas diferenças de pontuação permaneceram e as terminações de frase afetadas mudaram. Essa observação pertence a este elemento de teste limpo em particular. Diz-nos para verificar o resultado após a segmentação, e não que o corte ajuda ou prejudica o OCR em geral.

Reproduza o teste ou mantenha um registo de revisão

Transfira o README da experiência para obter fontes de modelos e tipos de letra fixas, versões de dependências, descrições de ficheiros e comandos. O gerador de exemplos, executor de OCR, e script de comparação separa a criação de imagens, o reconhecimento e a avaliação.

O executor utiliza a API de worker do Tesseract.js documentada. Para uma região vertical, as definições essenciais são as seguintes:

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 conter o ficheiro jpn_vert.traineddata descarregado e descomprimido. Este excerto não constitui o programa completo; o executor fornecido também guarda os resultados em bruto e termina os workers.

Se utilizar outra aplicação de OCR, mantenha os mesmos dados de evidência mesmo que os nomes das definições diferiram: região de origem, ficheiro original, versão do modelo ou ferramenta, direção, escolha de segmentação, saída real, texto corrigido e caracteres não resolvidos. O modelo de registo de revisão está em branco para não dar a entender que as suas páginas já foram aprovadas.

Não converta o nosso pequeno resultado de correspondência exata numa percentagem garantida para um romance inteiro. Diferentes tipos de letra, colunas densas, formas históricas, digitalizações de baixa qualidade e balões de fala de mangas exigem testes representativos próprios. A disposição de mangas e o reconhecimento de escrita à mão estão fora deste experimento.

Traduza apenas quando a fonte recuperada for fiável

Se o seu objetivo é pesquisar, copiar citações ou consultar um dicionário, o texto japonês verificado poderá ser o resultado final. Não precisa de traduzir um documento inteiro apenas porque o OCR esteve envolvido.

Se uma barreira linguística ainda impedir a leitura e tiver um ficheiro utilizável que possa carregar, prossiga com o fluxo de trabalho de tradução de PDF. Preserve a digitalização original e a transcrição verificada para poder distinguir erros de reconhecimento de erros de tradução. O executor de exemplo produz ficheiros de texto e TSV, e não um PDF pronto para carregamento automático; prepare o formato de entrada exato que a sua ferramenta seguinte exige.

O modo OCR do BookTranslator reconstrói o conteúdo traduzido em vez de garantir o layout vertical original. Não assuma que irá preservar todas as associações de ruby ou reparar erros de reconhecimento não verificados. Reveja a ordem de leitura e a formatação do documento final utilizando o guia de preservação de formato de PDF e a lista de verificação final de CQ de PDF.

A transição fiável não é “OCR concluído.” É “o texto japonês pretendido está presente, a respetiva sequência foi verificada e o tratamento das anotações está documentado.”