Feature: Vertical writing mode (tategaki) for Japanese / Traditional Chinese EPUBs

Scope Self-Check (required)

• I have read SCOPE.md and ROADMAP.md.
• This is not a new theme or theming change (themes are temporarily closed pending the move to SD-loaded themes).
• This is not a new external network connector (sync engine, cloud storage, remote file access, or any new "talk to a server" feature). Improvements to the existing OPDS support are in scope and do not count as a new connector.
• This is not an interactive app (game, calculator, notepad), writing/authoring tool, RSS/news/browser feature, media playback feature, or PDF rendering.
• The stock firmware does not already handle this well.
• No other popular CrossPoint fork already handles this well (or, if one does, I explain below why CrossPoint still needs it).

Problem this solves

Japanese and Traditional Chinese books are conventionally typeset vertically (縦書き / tategaki): characters top-to-bottom, columns flowing right-to-left, pages progressing right-to-left. This is the default layout for most Japanese fiction and very common for Traditional Chinese books in Taiwan and Hong Kong.

CrossPoint currently renders all text horizontally. Readers of Japanese and Traditional Chinese EPUBs get a layout that contradicts the publisher's intended typesetting (many vertical-first EPUBs declare writing-mode: vertical-rl and page-progression-direction: rtl, which are silently ignored). For fiction with ruby annotations the horizontal fallback is readable but noticeably wrong for its audience — comparable to forcing left-aligned text on an RTL Arabic book, a gap CrossPoint already chose to close.

Why the stock firmware (and other forks) do not already solve this

• Stock Xteink firmware: no vertical writing support.
• Community forks checked (CrossInk, papyrix-reader, inx, Witch(hunt) Reader): none advertise or implement vertical layout. papyrix focuses on Arabic/RTL horizontal scripts; the others focus on UI/UX, formats, and CSS fidelity — all horizontal.
• SCOPE.md §5 explicitly asks for reports on "Languages with poor stock and fork coverage: Especially those that need shaping, complex layout, or non-Latin font work that nobody is handling well today." Vertical CJK is exactly this class of gap, and it falls under the in-scope areas "EPUB Rendering & Optimization" and "Typography & Legibility".

Proposed change

Add a vertical writing mode to the reader engine, delivered in stages (Stage 1 first, as a focused PR against develop):

1. Stage 1 — readable tategaki: a vertical layout path (columns broken against viewport height, placed right-to-left), section-cache extension with SECTION_FILE_VERSION bump, and a manual per-book setting. Upright CJK glyphs; Latin runs rotated via the existing drawTextRotated90CW renderer path.
2. Stage 2 — daily-driver quality: vertical punctuation forms (Unicode Vertical Forms U+FE10–FE19, reusing the codepoint-remapping approach already proven by the Arabic shaper in lib/MiniBidi), vertical ruby placement, RTL page progression.
3. Stage 3 — polish: auto-detection from CSS writing-mode / OPF page-progression-direction, tate-chū-yoko, fuller kinsoku table.

Much of the groundwork already exists: per-character CJK segmentation and basic kinsoku (lib/Epub/Epub/ParsedText.cpp), ruby parsing/rendering, SD-card CJK fonts, and a compile-time rotated-glyph render path (lib/GfxRenderer/GfxRenderer.cpp).

Memory / flash / complexity cost

• DRAM: no expected runtime increase. Layout is computed once at section-build time and cached to section.bin on SD; vertical layout is the same class of work as horizontal with axes swapped. CJK glyphs already stream from SD via the existing ring buffer.
• Flash: moderate — a parallel layout path in ParsedText / ChapterHtmlSlimParser plus render-side handling in TextBlock. Stage 2's punctuation remapping is a small lookup table. Estimate: low single-digit KB per stage; I'll report exact numbers per PR.
• Complexity: the main cost. Touches the section cache format (version-gated, existing invalidation handles migration) and adds a second layout axis to the reader core. Mitigated by staging and by keeping the horizontal path untouched as the default.
• Performance: page turns unaffected (cache-served); section builds do comparable work to today. Targets both C3 and S3.

Additional context

• Full feasibility analysis and open design questions: Discussion #3474
• Design note: the column-direction is kept parameterized (right-to-left for CJK) so vertical scripts with left-to-right columns (traditional Mongolian) are not ruled out later — though Mongolian additionally needs contextual glyph shaping and is explicitly out of scope here.
• I can supply sample EPUBs (Japanese fiction with ruby, Traditional Chinese vertical layout) and test on real hardware (X4 / ESP32-C3).
• I am willing to implement this and submit a PR — Stage 1 as a focused PR against develop, following the contributing workflow (fork, ./bin/clang-format-fix, pio check, pio run, hardware verification), with AI-usage transparency per the PR template.