## Summary For a page holding vertical Japanese text — columns read top-to-bottom, columns ordered **right-to-left** — `extract_text` preserves the correct character order, but `extract_pages_markdown` reconstructs the page as a GFM table (there are no rules, borders, or table semantics on the page) with columns emitted **left-to-right**, the reverse of the reading order. Linearized, the text is unreadable. The materials encode the vertical layout as individually positioned glyphs (simple TrueType, per-glyph positioning, no vertical CMap / WMode 1). The tested LibreOffice export of a Word-compatible `w:textDirection="tbRl"` document produced the same representation, so at least one mainstream producer emits this shape. I have not tested Type0 vertical-CMap PDFs. - **Version:** pdf-inspector 1.17.0 (installed from PyPI, Python binding), Python 3.12.10, macOS arm64 - The same table comes out of anydoc 0.2.4 `to_markdown` (which bundles the pdf-inspector crate) — the markdown strings are identical to the 1.17.0 Python output here, so the behavior is not new in 1.17. ## Reproduction Expected reading order: `いつもおせわに` (right column) then `なっております` (left column) → `いつもおせわになっております`. **A. Minimal (reportlab):** ```python # pip install pdf-inspector reportlab # JP_FONT: any TTF with kana coverage; verified with IPAexGothic # (IPA Font License, https://moji.or.jp/ipafont/) import os from reportlab.pdfgen import canvas from reportlab.lib.pagesizes import A4 from reportlab.pdfbase import pdfmetrics from reportlab.pdfbase.ttfonts import TTFont import pdf_inspector pdfmetrics.registerFont(TTFont("JP", os.environ["JP_FONT"])) c = canvas.Canvas("vertical.pdf", pagesize=A4) c.setFont("JP", 20) for i, col in enumerate(["いつもおせわに", "なっております"]): # right column first = reading order x, y = 500 - i * 40, 750 for ch in col: c.drawString(x, y, ch) y -= 26 c.save() print(pdf_inspector.extract_text("vertical.pdf")) print(pdf_inspector.extract_pages_markdown("vertical.pdf").pages[0].markdown) ``` **B. LibreOffice-exported tategaki** (same normalized character order and identical markdown output as A): ```python # pip install python-docx; needs LibreOffice (soffice) on PATH import subprocess from docx import Document from docx.oxml import OxmlElement from docx.oxml.ns import qn doc = Document() doc.add_paragraph("いつもおせわに") doc.add_paragraph("なっております") td = OxmlElement("w:textDirection"); td.set(qn("w:val"), "tbRl") doc.sections[0]._sectPr.append(td) doc.save("tategaki.docx") subprocess.run(["soffice", "--headless", "--convert-to", "pdf", "tategaki.docx"], check=True) ``` ## Observed The raw `extract_text` strings differ in line breaks between A and B; after removing whitespace, the character order is identical, and the markdown output is identical byte-for-byte. ``` extract_text (whitespace removed) : いつもおせわになっております <- correct order extract_pages_markdown : |な|い| |---|---| |っ|つ| |て|も| |お|お| |り|せ| |ま|わ| |す|に| ``` The left column becomes table column 1 and rows interleave the two phrases; linearized reading is `ないっつてもおおりせまわすに`. `classify_pdf` reports `text_based, confidence=1.00`; the result lists the page under `pages_with_tables`, not `pages_with_columns`. ## Expected Non-tabular output that preserves the character order `extract_text` already produces — or, if tabular output is ever intended, right-to-left column order for vertical CJK. ## Notes - This looks like the same table/reading-order family as #219; the tested pages have fewer than 15 lines, so they may be taking the short-page path that PR #268 improves. That change looks right for horizontal prose — I'm filing the vertical case separately so it doesn't get lost next to it: tategaki columns run right-to-left, so a sequential left-to-right emission that is correct for horizontal text still comes out reversed here. Ideally the two cases could share a solution keyed on column direction. - Sibling reports for horizontal RTL scripts: #212 / #327 (Arabic returned in visual rather than logical order). #217 asks to expose the reading-direction signal the detector computes; for vertical CJK that signal would also need to carry column direction. - The two APIs disagree on the same files: `extract_text` preserves the character order while the markdown reconstruction does not — so the correct order is computable from what the file contains. - Impact: for vertical-layout files like these, treating the positioned columns as a table prevents the markdown from preserving the intended reading order. Vertical writing is common in Japanese-language documents.