Standard OCR engines are built on a fundamental assumption: text runs horizontally from left to right across the page. This assumption works for English, Spanish, French, German, and most European languages. It fails completely for Japanese text set vertically in traditional columns, for Chinese signs where characters stack top to bottom, and for Arabic and Hebrew documents where text flows right to left. Running standard OCR on these documents produces output where characters are recognized individually but assembled in the wrong order, rendering the result useless.
The capability of OCR PDF engines to handle non-standard text directions has improved significantly with the latest generation of AI-powered recognition systems. These engines detect text orientation before attempting recognition, identify the reading direction, and reconstruct the logical reading order regardless of the visual layout. For documents with mixed text directions, such as a Japanese article that includes horizontal English quotations, the engine switches modes mid-page.
How OCR Engines Detect and Handle Text Direction
Modern OCR engines begin with a layout analysis step that identifies text regions, determines their orientation, and classifies them by reading direction. For horizontal text, the engine detects the baseline and groups characters along it. For vertical text, the engine detects the vertical axis and groups characters in columns. For right-to-left text, the engine identifies the dominant character set and reverses the default left-to-right word ordering.
Text direction detection relies on several signals. The presence of specific Unicode character ranges indicates likely languages and their typical text directions. The spatial arrangement of detected characters, whether they form horizontal lines or vertical columns, provides layout evidence. The aspect ratio of character bounding boxes provides a third signal: Latin characters are typically wider than they are tall, while CJK characters are roughly square, and Arabic characters connect horizontally in ways that reveal reading direction.
The most reliable OCR engines combine all three signal types. A document containing both Arabic script, which implies right-to-left reading, and Latin script, which implies left-to-right, requires the engine to analyze each text region independently. A correctly configured Extract PDF Data pipeline for multilingual documents includes per-region direction detection rather than applying a single direction to the entire page.
Each writing system demands a fundamentally different OCR configuration.
OCR Settings for Vertical Text in Japanese, Chinese, and Korean
Japanese vertical text, called tategaki, is the most common vertical writing system in modern use. It appears in novels, newspapers, traditional documents, and formal correspondence. In vertical Japanese, characters are read from top to bottom, with columns progressing from right to left across the page. Numbers and Latin-script words embedded in vertical Japanese text may be rotated or set horizontally within the vertical flow.
To OCR vertical Japanese text, select a recognition engine that explicitly supports tategaki. General-purpose OCR engines may detect the characters correctly but output them in left-to-right horizontal order, producing garbage. Japanese-specific OCR engines understand the column-based reading order and output text that can be read naturally. Tesseract, the open-source OCR engine, added improved vertical Japanese support in version 5, and several commercial engines now offer it.
For Chinese vertical text, which appears in traditional publications, calligraphy, and some formal documents, the recognition challenge is similar but the character set is larger. Simplified Chinese uses approximately 7,000 characters in common use, while traditional Chinese uses over 13,000. The OCR engine must not only detect the vertical layout but also distinguish between visually similar characters that differ only in stroke detail.
Korean vertical text is rare in modern documents but appears in historical texts and some traditional publications. The Korean alphabet, Hangul, assembles individual letters into syllable blocks, and in vertical writing these blocks are stacked top to bottom. OCR engines that handle Korean vertical text must recognize the syllable block structure as well as the individual letter components within each block.
OCR Settings for Right-to-Left Text in Arabic, Hebrew, and Persian
Arabic OCR presents unique challenges beyond text direction. Arabic is a cursive script where most letters connect to their neighbors, and the letter shape changes depending on its position in the word: initial, medial, final, or isolated. The OCR engine must recognize these contextual forms and map them to the correct abstract character. Missed connections or false connections between letters produce recognition errors that are specific to cursive scripts.
When selecting Hebrew OCR, the script is not cursive but includes vowel points, called niqqud, that appear as dots and dashes above, below, or inside letters. These vowel marks are small, typically 2 to 4 pixels in a scanned image, and are easily lost during binarization. An OCR engine that does not explicitly handle niqqud will recognize the consonants correctly but drop the vowel marks, producing text that a human reader can understand but that is technically incomplete.
Persian and Urdu use extended versions of the Arabic script with additional characters. An OCR engine trained only on Arabic will miss these additional characters or misrecognize them as similar Arabic letters. When selecting an OCR engine for these languages, verify that it specifically lists support for the exact language and script variant your document uses, not just Arabic script in general.
Handling Mixed-Direction Documents
Many real-world documents mix multiple text directions on the same page. A Japanese technical paper may have vertical Japanese body text, horizontal English figure captions, and mathematical equations that follow their own layout rules. An Arabic business letter may include an English company name and address block in left-to-right format above right-to-left body text.
For mixed-direction documents, the OCR preprocessing step is critical. The document must be segmented into text regions, and each region must be classified independently for text direction before recognition begins. Manual region selection often produces better results than automatic segmentation for complex layouts. Draw bounding boxes around each text region and assign the correct language and direction to each box.
After OCR, verify the output by checking text that crosses direction boundaries. A common error in mixed-direction OCR is getting the boundary between two text regions wrong, so that the last word of a left-to-right region gets appended to the beginning of a right-to-left region, or vice versa. Spot-checking these boundary areas catches layout segmentation errors that would otherwise produce confusing output.
Post-OCR Processing for Non-Standard Text Directions
After OCR completes, the recognized text may need reordering to produce natural reading order. Some OCR engines output vertical Japanese text in the order it was recognized, top to bottom within each column, column by column from left to right. This order does not match the original reading order, which is column by column from right to left. A post-processing step that reorders the columns produces the correct reading sequence.
For documents with Scanned PDF content that includes bidirectional text, Arabic with embedded English terms, the Unicode Bidirectional Algorithm specifies how to determine display order. OCR output should include Unicode bidirectional control characters or follow the algorithm so that text displays correctly when pasted into applications that support bidirectional text.
WukongPDF provides OCR processing through the browser for scanned PDFs, with language selection options that include support for major right-to-left and vertical writing systems. Testing the OCR on a sample page before processing the full document lets you verify that the text direction is being handled correctly.
For documents that contain both vertical and horizontal text on the same page, such as a Japanese magazine layout where the main article is vertical but captions and sidebars are horizontal, manual zoning produces the most accurate OCR results. Draw separate recognition zones for the vertical and horizontal regions, assign the correct text direction to each, and run OCR on the zoned document. The extra time spent on zoning pays back in recognition accuracy.
When processing historical documents with non-standard text layouts, be prepared for OCR accuracy to be lower than for modern printed documents. Historical fonts, uneven printing, aged paper with discoloration, and non-standard character variants all reduce recognition confidence. For scholarly or archival work, treat the OCR output as a starting point for manual transcription rather than a finished product.
Some OCR engines support a training mode where you provide examples of the specific font or handwriting style used in your document. Training the engine on a few representative pages improves recognition accuracy across the entire document. This approach is particularly useful for documents printed in unusual typefaces or for collections of documents from the same publisher where the typography is consistent across multiple volumes.
After OCR completes on a right-to-left document, verify that the text direction is correct by copying a few sentences from the output and pasting them into an application that supports bidirectional text, such as Microsoft Word or Google Docs. If the text appears in reverse order, the OCR engine did not correctly apply the right-to-left direction, and the output needs to be reprocessed with corrected direction settings.
The time invested in setting up correct OCR parameters for non-standard text directions pays back immediately in recognition accuracy. A document that requires 30 minutes of manual correction after poor OCR may need only 5 minutes of cleanup after properly configured OCR.
| Writing System | Direction | OCR Engine Requirement | Key Challenge |
|---|---|---|---|
| Japanese (tategaki) | Top-to-bottom, right-to-left columns | Engine with explicit tategaki support | Mixed horizontal English in vertical flow |
| Chinese (traditional) | Vertical columns, right-to-left | Large character set (13,000+) | Visually similar characters |
| Arabic | Right-to-left, cursive connection | Arabic script engine with positional forms | Contextual letter shapes; diacritics |
| Hebrew | Right-to-left, with niqqud | Hebrew script engine with vowel support | Small vowel marks lost in binarization |
| Persian / Urdu | Right-to-left, extended Arabic | Language-specific engine | Additional characters beyond Arabic set |