Japanese Vertical Text OCR: Preserve Column Order and Handle Furigana

For Japanese vertical text OCR, check the writing direction before changing image filters. Use a Japanese model and segmentation setting that can handle vertical text, verify the columns in their intended order, and decide whether you need the main text alone or the furigana as well. A page full of recognizable characters can still be an unusable transcription if their sequence is wrong.

We ran a small, reproducible local experiment to make those decisions concrete. A horizontal configuration scrambled our three vertical columns. A vertical configuration recovered the plain body text, but adding furigana changed two punctuation marks, and cropping out the ruby did not eliminate punctuation errors.

Those are results from a deliberately small synthetic sample, not an accuracy claim about all Japanese books. The useful lesson is narrower: evaluate character recognition, reading order, and annotation handling separately. Do not send the result to translation just because it looks like Japanese.

First identify the text you actually want

In conventional Japanese vertical composition, characters progress down a line and lines proceed from right to left. Ruby is the smaller text associated with base characters; furigana commonly supplies their pronunciation. W3C's Requirements for Japanese Text Layout describes these writing directions and ruby relationships.

Before OCR, label the meaningful regions of the page:

• main vertical columns;
• small ruby alongside the body;
• horizontal headings, captions, or tables;
• page numbers and running heads;
• marginal notes or unrelated adjacent pages.

Do not treat every vertical strip as an independent paragraph. A strip of small kana beside 図書館 may be its reading, としょかん, not the next sentence.

Choose the output policy before judging the OCR:

The same output can pass one task and fail another. Our experiment uses body-only transcription as its comparison target. It does not treat missing furigana as acceptable for a pronunciation-study edition.

A real three-sentence OCR experiment

The sample uses these self-authored sentences:

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

They describe reading at a library, seeing a river on an old map, and meeting a friend at a station. There are 34 body-text Unicode code points when the line breaks are removed, including the three Japanese full stops.

We rendered the same body in three forms:

1. Horizontal text.
2. Three vertical columns, read right to left.
3. The same vertical columns with furigana beside 図書館, 地図, 友人, and 駅.

These are clean teaching images, not scanned pages from a book. The renderer uses Noto Sans CJK JP, 64-pixel body characters, 24-pixel ruby, and simplified glyph-by-glyph vertical placement. It draws vertical full stops as small outlined circles at manually chosen positions rather than using the font's proper vertical glyph positioning; the punctuation results therefore do not establish how OCR performs on a properly typeset book. It does not reproduce every Japanese typesetting rule. There is no blur, skew, paper texture, handwriting, historical type, or mixed-direction page in the test.

Engine, models, and settings

The experiment ran on September 7, 2026, using Tesseract.js 7.0.0 with Tesseract.js-core 7.0.0 locally on macOS ARM64. All successful calls used the official tessdata_fast models at commit 87416418657359cb625c412a48b6e1d6d41c29bd, with OEM 1, the LSTM-only engine mode.

Tesseract's official model repository supplies separate jpn and jpn_vert files. Its documentation describes PSM 5 as a uniform vertically aligned block and PSM 6 as a uniform text block; choose a segmentation assumption that fits the region being recognized. See the page segmentation documentation.

Our recorded cases used jpn with PSM 6 for horizontal text, jpn_vert with PSM 5 for vertical text, and a deliberately mismatched jpn/PSM 6 vertical control. Both model and segmentation change between the two vertical configurations, so this is a workflow comparison, not an experiment isolating the effect of either setting alone.

An initial attempt with tessdata_best aborted in the available WebAssembly core before producing OCR text. We switched to the official integer tessdata_fast models for compatibility and recorded that failure. No conclusion about one model family's accuracy follows from that switch.

What actually came back

The comparison removes whitespace and applies Unicode NFC normalization. It does not replace punctuation, correct kanji, or rearrange text. The complete raw outputs and version/model hashes, body comparison CSV, and error annotations are downloadable.

For example, the furigana case returned this first line:

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

The spaces are ignored by our stated comparison rule. The final punctuation is not. A search-only workflow might tolerate that difference, but a faithful transcription should record and correct it.

The mismatched vertical control began with 明 古 昌, jumping across the top characters of the columns rather than following the intended first sentence. Its output illustrates why recognizing individual symbols is not the same as reconstructing a reading sequence.

There were seven completed OCR calls: four whole-image cases and three crops. We retained every output. One agent compared the results against the authored ground truth and visually inspected the images; there was no blinded human review or broad benchmark corpus. The experiment does not establish a universally best engine, a book-level accuracy rate, or performance on your scan.

Use a region-first workflow on your own page

1. Preserve the source and choose one difficult page

Keep the original image or PDF unchanged. Work on a copy, and record the page number. Choose a page that contains the problem you are trying to solve: dense ruby, a narrow gutter, a horizontal heading above vertical text, or unusually small type.

A clean title page is not a useful acceptance test for a book whose body pages have a different layout. If the source is a PDF, extract or render the selected page using a tool you trust before running an image-only OCR workflow. This article's scripts accept PNG files; they do not process PDFs or build searchable PDF layers.

For the full scanned-document preparation and translation process, use the broader scanned PDF workflow. This guide focuses on Japanese direction, segmentation, ruby, and transcription decisions.

2. Correct capture defects without destroying small text

Inspect the actual characters at a useful zoom level. Straighten unintended skew, remove unrelated page borders, and preserve enough contrast to distinguish small kana and punctuation. Avoid treating aggressive thresholding or sharpening as an automatic improvement: compare the resulting image with the original before trusting the OCR.

Tesseract's image-quality guidance covers resolution, noise, skew, and borders. Those are separate from writing direction. Deskewing a page that was photographed at an angle is not the same operation as rotating upright vertical Japanese text sideways.

The sample files carry 300 dpi metadata, but that number does not create missing detail. Their actual body glyph size is 64 pixels. A low-resolution photo relabeled “300 dpi” is still the same low-resolution photo.

3. Separate regions when the page violates one layout assumption

Try the main vertical block on its own before asking one OCR call to handle a horizontal title, vertical prose, an illustration, and a page number. Keep a simple region record such as “page 12, body, column 1 from the right.” That record makes later assembly auditable.

For mixed-direction material, recognize the horizontal region with the appropriate horizontal setting and the vertical region with a vertical setting, then assemble them in the order the document intends. This is a recommended workflow to test on your file, not a mixed-layout capability measured by our three sample images.

Our crop experiment used exact known coordinates to exclude the ruby strip beside each synthetic column while keeping its body text and a white margin. It was a manual region-selection demonstration, not an automatic furigana-removal algorithm. Do not apply its coordinates to a real book page.

4. Check columns before proofreading individual characters

Compare the first and last body characters of each column, working in the intended direction. Confirm that no column is missing, duplicated, reversed, or blended with its neighbor. Then inspect sentences at the column boundaries.

Only after that should you correct individual kanji, kana, punctuation, numbers, and names. Otherwise, you can spend time polishing fragments that are assembled into the wrong paragraph.

A useful three-pass review is:

1. Regions and order: every intended body region is present once and in sequence.
2. Characters: compare the actual image with the text, including small punctuation and kana marks.
3. Annotations: decide whether each ruby item, note, or marginal label is preserved, separated, or deliberately excluded.

An engine's confidence value is not a substitute for these checks. Our scrambled control still returned an engine-reported confidence number; that did not make its reading order acceptable.

Do not remove furigana until you know why

For body-only extraction, ruby should not accidentally become a second layer of prose. But deleting every small kana string is not a safe general rule. A reading can help disambiguate a name, preserve an author's chosen pronunciation, or support the reader's study task.

In our furigana image, the OCR output contained the main kanji but did not return the four readings as a separate annotation set. That could be sufficient after punctuation correction for a body-only search task. It is insufficient if the deliverable promises pronunciation information.

Store important readings separately and associate them with the right occurrence. For example:

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

The sample's separate ruby transcription makes that policy explicit. It is ground truth authored with the image, not an OCR success claim.

If the OCR mixes kana into a word or loses its association, compare against the image and repair the transcription. Do not ask a language model to guess the source and present the guess as recovered text. Mark an uncertain reading for review instead.

The crop results also argue against a simplistic “remove ruby and everything improves” rule: two punctuation differences remained, and the affected sentence endings changed. That observation belongs to this particular clean fixture. It tells us to verify the result after segmentation, not that cropping generally helps or harms OCR.

Reproduce the test or keep a review log

Download the experiment README for pinned model and font sources, dependency versions, file descriptions, and commands. The sample generator, OCR runner, and comparison script separate image creation, recognition, and evaluation.

The runner uses the documented Tesseract.js worker API. For a vertical region, its essential settings are:

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 must contain the downloaded, uncompressed jpn_vert.traineddata file. This is an excerpt, not the complete program; the supplied runner also saves the raw results and terminates workers.

If you use another OCR application, keep the same evidence even when the setting names differ: source region, original file, model or tool version, direction, segmentation choice, actual output, corrected text, and unresolved characters. The review-log template is blank so it does not imply your pages have already passed.

Do not convert our tiny exact-match result into a promised percentage for an entire novel. Different fonts, crowded columns, historical forms, low-quality scans, and manga speech bubbles require their own representative tests. Manga layout and handwriting recognition are outside this experiment.

Translate only when the recovered source is trustworthy

If your goal is searching, copying quotations, or dictionary lookup, verified Japanese text may be the finished result. You do not need to translate a whole document merely because OCR was involved.

If a language barrier still prevents reading and you have a usable file you can upload, continue with the PDF translation workflow. Preserve the original scan and checked transcription so you can distinguish recognition errors from translation errors. The sample runner produces text and TSV files, not a PDF ready for automatic upload; prepare the actual input format your next tool requires.

BookTranslator's OCR mode reconstructs translated content rather than guaranteeing the original vertical layout. Do not assume it will preserve every ruby association or repair unverified recognition mistakes. Review the final document's reading order and formatting using the PDF format-preservation guide and final PDF QA checklist.

The reliable handoff is not “OCR completed.” It is “the intended Japanese text is present, its sequence has been checked, and the treatment of annotations is documented.”