YomiToku: a Japanese-first document analysis engine with four trained models

What YomiToku is for, and the gap it targets

General-purpose OCR engines treat Japanese as one script among many. That works until the page stops being horizontal. Japanese documents mix horizontal and vertical text, put ruby (furigana) above base characters, and use table layouts where cell boundaries carry meaning. YomiToku is built around the assumption that these are the normal case, not edge cases. The README states that the models are trained on Japanese document images and support recognition of more than 7,000 Japanese characters, including handwriting and vertical writing, with English also supported. The package targets developers who need to turn scanned or photographed Japanese documents into structured data: OCR text, reading order, table cells, and extracted figures. If your input is a Japanese form, a white paper, or a scanned report, that is the intended workload. If your input is a photo of a shop sign, the README says plainly that YomiToku is optimised for document OCR and not for scene OCR.

Four models, four jobs, one pipeline

YomiToku ships four models, each trained by the project: character position detection, string recognition, layout analysis, and table structure recognition. They run in sequence over a document image. Detection finds character regions. Recognition turns those regions into strings. Layout analysis assigns semantic regions (figures, table areas, table cells, paragraphs and text groups) and estimates reading order. Table structure recognition recovers the cell grid, including rowspan and colspan. The visualisation output makes this legible: the README documents red boxes for figures and images, green for whole table regions, pink for cell structure with cell text shown as [row, column] plus rowspan and colspan, blue for paragraphs and text groups, and red arrows for the estimated reading order. That is a meaningful design decision. Reading order and cell structure are computed during analysis rather than reconstructed afterwards from a flat text stream, so a markdown or HTML export can preserve the document's semantic structure. The four models are separate artefacts, which also means the pipeline is only as good as its weakest stage: a misdetected cell boundary propagates into the table output.

Getting it running: install, CLI and the lite path

Installation is a single command: pip install yomitoku. PyTorch is not pinned for you. The README notes that the default install pulls a build for CUDA 12.4 or later, that PyTorch 2.5 or later is supported, and that CUDA 11.8 or later is required as a consequence. If your driver cannot match that, the repository includes a Dockerfile as the fallback. The standard inference call is yomitoku ${path_data} -f md -o results -v --figure, where -f selects the output format (json, csv, html, md, or pdf for searchable PDF), -o sets the output directory, -v writes visualisation images, and --figure exports detected figures and images. For CPU work there is a lite path: yomitoku ${path_data} -f md --lite -d cpu -o results -v --figure. The same mode is reachable from Python by setting the text recogniser to parseq-tiny-dynw-v4 and enabling dynamic_width and batch_bucketing, with infer_onnx on the detector for additional CPU speed. One warning in the README is easy to miss: parseq-tiny-dynw-v4 was trained for dynamic-width batched inference, so it should be paired with dynamic_width=True and batch_bucketing=True, and because ONNX inference fixes the input size, dynamic_width is disabled automatically when infer_onnx is on.

Output formats and the flags that change the text

The export layer is where YomiToku separates itself from a plain OCR library. Supported formats are json, csv, html, md and pdf, the last producing a searchable PDF. Several flags alter the text rather than the container. --ignore_line_break joins sentences within a paragraph instead of reproducing the image's line breaks. --ignore_meta drops header and footer text. --ignore_ruby removes furigana, with --ruby_threshold setting the confidence threshold for that judgement (default 0.5). --figure_letter exports text found inside detected figures. --encoding accepts utf-8, utf-8-sig, shift-jis, enc-jp and cp932, and the README notes that characters not representable in the chosen encoding are dropped. That last point deserves attention: if you export to shift-jis to match a downstream system, you are silently losing characters, and the tool will not tell you which. --combine merges multi-page PDF predictions into a single output file. The table semantic parser is a separate command, yomitoku_table ${path_data} -o results -v, which emits page-level structured JSON with Key-Value and grid representations, embedding source cell IDs and coordinates by default, or text only with --simple.

Where the design costs you: resolution, model choice and licence

Three constraints are documented and worth taking literally. First, input resolution. The README states that recognition accuracy depends on it and recommends a short edge of at least 720px. Feed it a low-resolution scan and accuracy degrades; there is no upscaling step described that rescues this. Second, the device trade-off. The normal model is recommended on GPU and, per the README, is not optimised for CPU inference, where processing time becomes long. The lite model runs fast on CPU but the documentation acknowledges a possible drop in accuracy, and the release notes for 15 July 2026 record that the lite model gained handwriting support and a maximum string length of 100 characters per line. So the practical choice is between a GPU-bound accurate path and a CPU-friendly approximate one, and the project does not publish a comparison table to help you pick. Third, licensing. The repository material supplied here does not state a licence identifier. For a package that bundles trained model weights, the licence on the weights matters as much as the licence on the code, and neither is confirmed by the material available. That is a question to settle with the project before any commercial deployment, not an assumption to make.

How it differs from Tesseract and PaddleOCR

Tesseract is the long-standing open source baseline. Its approach is a general recogniser with per-language trained data, and its output is fundamentally a text stream with word boxes; layout structure and reading order are not first-class outputs, and vertical Japanese and ruby require workarounds. YomiToku instead treats layout analysis and table structure recognition as trained models in the same pipeline, which is why it can emit reading-order arrows and rowspan/colspan cell metadata directly. PaddleOCR is the closer comparison: it also offers detection, recognition, layout analysis and table recognition as a pipeline, and it is explicitly multilingual. The difference in approach is scope. PaddleOCR spreads its training across many scripts; YomiToku concentrates on Japanese, which is why the README can claim support for over 7,000 Japanese characters and specific handling of vertical writing and handwriting. If your corpus is monolingual Japanese, that concentration is the reason to pick it. If your corpus mixes Japanese with Korean, Chinese and English pages in the same batch, a multilingual pipeline avoids running two systems.

Maintenance and upgrade cost

The release cadence visible in the material is regular: v0.13.0 in May 2026, v0.13.1 in July, v0.14.0 at the end of July, with the last repository push in August 2026. That is a project under active change, and the release notes show the kind of change that can affect output. v0.14.0 introduced the Table Semantic Parser and the yomitoku_table command as a new surface. v0.13.1 changed lite model behaviour, adding handwriting support and raising the per-line character limit to 100. Anyone pinning an older lite model and comparing outputs across that boundary will see different results on the same input. The upgrade cost is therefore not just dependency churn but output drift, and the honest mitigation is to keep a small set of your own document images and re-run them after each version bump, comparing the exported json or md. The PyTorch floor is the other recurring cost: because the default install targets CUDA 12.4 or later and PyTorch 2.5 or later, environments on older CUDA must either upgrade or fall back to the repository Dockerfile. The browser demo at YomiToku Studio runs inference in WebAssembly or WebGPU and, per the README, does not send images anywhere, which makes it a reasonable way to sanity-check accuracy on a sample page before installing anything.

Editorial conclusion

Adopt YomiToku if your input is Japanese business documents and you need layout and table structure, not just a text dump. Do not adopt it for scene OCR such as signage, or for non-Japanese corpora where a multilingual engine is a better fit. Before committing, verify three things: the licence terms, since the repository material does not state one; recognition accuracy on your own scans at 720px or more on the short edge; and whether the normal model or the lite model meets your latency budget on your hardware, because the documentation states the normal model is not optimised for CPU.

Official sources

1. Issues
2. kotaro-kinoshita/yomitoku on GitHub
3. Project website
4. README
5. Releases