Origami Text EPUB provides a single XHTML content document with semantic elements (<h1>–<h6>, <p>, <blockquote>, <figure>, <img>, <section>) which is the absolute baseline of what any EPUB reader is built to render. No reader gets this wrong. Inline images inside <figure>elements in document flow are the simplest image case. The data- attributes on citation entries are valid HTML and silently ignored by every reader. The visual-meta.json file in the package just needs to be declared in package.opf and readers that don’t recognise it will skip it.
A few technical points
The <script type="application/json"> block for the inline Visual-Meta — this is the one element I’d want to test carefully. EPUB 3 allows <script> in the content document, but some readers may flag it or handle it unexpectedly even though application/json isn’t executable. EPUBCheck should pass it, but it’s worth verifying that no reader renders the JSON as visible text.
An alternative would be to embed it in a <div hidden> or as a comment, though both of those are less clean semantically. If <script type="application/json"> passes EPUBCheck and is invisible across the five readers we listed, it’s the right choice.
Limitations
The single-file approach could cause performance issues in some readers for very long documents — if paper.html is a 200-page monograph with dozens of figures, some readers (particularly Moon+ on lower-end Android devices) may struggle. For typical academic papers of 20–40 pages this won’t matter, but it’s worth noting the boundary.
EPUB 3 requires XHTML5, not HTML5 — so paper.html technically needs to be well-formed XML (self-closing tags, quoted attributes, proper namespace declaration). This is a detail Author’s export already handles, but it’s the kind of thing that could silently break if someone else implements an Origami Text exporter without realising.
The core argument
We are not asking readers to support anything new. You’re asking them to do less than they normally have to — no multi-file navigation, no complex CSS cascade, no font embedding, no fixed layout, no scripting. The compatibility problem exists precisely because EPUB gives authors too many options and readers implement those options inconsistently. Origami Text works by choosing only the options that every reader agrees on. That’s a genuinely different strategy from trying to get readers to converge on the hard cases.
A basic Origami Text profile should render and behave properly in any EPUB reader, and the additional metadata (Visual-Meta JSON, data- attributes, spatial coordinates) rides along invisibly without affecting that base experience. The layered architecture means you’re not asking for permission from the reader ecosystem — you’re just putting structured knowledge in places that ignorant readers harmlessly ignore and aware readers can exploit.