NOVUS EXAMPLES - EPUB CONFORMANCE MATRIX (wave p7) ========================================================================== Every fixture in this wave, the feature it isolates, and how it should behave. Validity: valid | recoverable | invalid | reference. VALIDITY SUBCATEGORY FILE -------------------------------------------------------------------------- valid fixed-layout pre-paginated.epub valid fixed-layout reflowable-twin.epub valid fixed-layout spread-landscape.epub valid fixed-layout orientation-portrait.epub invalid fixed-layout no-viewport-meta.epub valid media-overlay smil-single-track.epub valid media-overlay smil-multi-track.epub recoverable media-overlay smil-no-duration.epub invalid media-overlay smil-broken-textref.epub valid embedded-fonts plain-embedded-font.epub valid embedded-fonts idpf-obfuscated-font.epub valid embedded-fonts adobe-obfuscated-font.epub invalid embedded-fonts obfuscated-no-encryption-xml.epub valid navigation nav-document-only.epub invalid navigation ncx-only-no-nav.epub valid navigation nav-and-ncx-dual.epub recoverable navigation nav-ncx-mismatch.epub valid navigation page-list-navigation.epub valid writing-modes rtl-arabic.epub valid writing-modes rtl-hebrew.epub valid writing-modes vertical-japanese.epub valid writing-modes mixed-bidi.epub reference writing-modes ltr-control.epub valid mathml mathml-declared.epub invalid mathml mathml-undeclared.epub valid mathml mathml-altimg-fallback.epub valid svg-content svg-content-document.epub valid svg-content inline-svg-in-xhtml.epub valid svg-content svg-cover-page.epub valid toc-depth nested-nav-four-levels.epub valid toc-depth nested-ncx-four-levels.epub reference toc-depth flat-toc-twin.epub valid spine linear-no-back-matter.epub recoverable spine all-items-linear-no.epub invalid spine duplicate-itemref.epub invalid broken-package unresolved-spine-idref.epub invalid broken-package manifest-missing-file.epub invalid broken-package wrong-media-type.epub invalid broken-package duplicate-manifest-id.epub invalid broken-package container-no-rootfile.epub valid metadata-encoding utf8-diacritics.epub valid metadata-encoding numeric-character-references.epub recoverable metadata-encoding utf16-package-document.epub valid metadata-encoding astral-plane-characters.epub recoverable metadata-encoding bom-on-every-xml-part.epub valid metadata-encoding meta-refines-chain.epub valid converter-twins same-book-epub2.epub valid converter-twins same-book-epub3.epub valid converter-twins same-book.fb2 valid epub2 ncx-page-list.epub valid epub2 meta-cover-no-guide.epub valid fb2 binary-cover.fb2 valid fb2 nested-sections-and-notes.fb2 valid fb2 windows-1251-encoded.fb2 -------------------------------------------------------------------------- 54 fixtures listed. This file is generated from the same entry list that builds the catalogue, so it cannot drift from what actually shipped. EXPECTED RESULTS -------------------------------------------------------------------------- pre-paginated.epub scenario: Open the book in a reader and resize the viewport or change the font size. expected: Page geometry is preserved and scaled as a unit; text does not reflow and the declared 600x800 canvas ratio is maintained. reflowable-twin.epub scenario: Open the book and change the viewport width or the reader's font size. expected: Text rewraps to the new measure and pagination changes; no fixed canvas is imposed. spread-landscape.epub scenario: Open in landscape orientation on a reader that supports synthetic spreads. expected: Two pages are shown side by side, with page 1 on the left and page 2 on the right as the spine properties request. orientation-portrait.epub scenario: Open the book on a device held in landscape. expected: The reader either locks presentation to portrait or documents that it cannot; pages are never shown two-up, because rendition:spread is none. no-viewport-meta.epub scenario: Validate the package, then open it in a reader. expected: A validator reports the missing viewport declaration on both content documents; a reader falls back to a default canvas or reflows, and does not crash. smil-single-track.epub scenario: Start read-aloud playback and follow the highlight through the chapter. expected: Playback advances par by par, each of the three paragraphs is highlighted in turn via the declared active class, and the reader reports the same total length as media:duration. smil-multi-track.epub scenario: Begin playback in chapter one and let it run past the end of that document. expected: Playback continues into the next chapter without user action, and the total time reported equals the sum of the three per-overlay media:duration values. smil-no-duration.epub scenario: Open the book and start read-aloud playback with no duration metadata present. expected: A validator flags the missing media:duration; the reader still plays the overlay, deriving its length from the MP3 rather than refusing to start. smil-broken-textref.epub scenario: Start playback and let it reach the second par, whose text src resolves to nothing. expected: A validator reports the unresolved fragment; a reader plays that clip without a highlight, or skips to par 3, and never aborts the whole overlay. plain-embedded-font.epub scenario: Unzip the book and open OEBPS/fonts/NovusSansSample.ttf in a font tool. expected: The extracted file is a valid, directly usable TrueType font, and the chapter renders in that face rather than a substitute. idpf-obfuscated-font.epub scenario: De-obfuscate the font using the dc:identifier from the package document and compare with the plain twin. expected: XORing the first 1040 bytes with SHA-1 of the identifier reproduces the plain twin's font byte for byte, and the chapter renders in the embedded face. adobe-obfuscated-font.epub scenario: Read META-INF/encryption.xml, pick the de-obfuscation routine it names, and load the font. expected: The Adobe algorithm URI is recognised, the first 1024 bytes are recovered with the UUID key, and the face renders; applying the IDPF routine instead produces an unusable font. obfuscated-no-encryption-xml.epub scenario: Open the book in a reader and inspect which face the chapter is set in. expected: The font fails to load because it is not a valid TTF as stored; the reader substitutes a default face without an error, and a validator reports the undeclared obfuscation. nav-document-only.epub scenario: Open the table of contents in an EPUB 3 reader. expected: All three chapters are listed from nav.xhtml and each link resolves; no NCX is required or consulted. ncx-only-no-nav.epub scenario: Open the book in an EPUB 3 reader and request the table of contents. expected: A validator reports the missing nav document; a tolerant reader builds the contents from toc.ncx instead, and a strict one reports the package as non-conforming rather than showing an empty contents list. nav-and-ncx-dual.epub scenario: Open the contents in an EPUB 3 reader, then in an EPUB 2 reader. expected: Both surfaces show the same three chapter titles in the same order, and every link resolves in both. nav-ncx-mismatch.epub scenario: Open the contents in a reader that consults the NCX, then follow the third NCX entry. expected: An EPUB 3 reader prefers nav.xhtml and shows the correct three chapters; a reader that follows the NCX reports the missing chapter9.xhtml as an unresolved link instead of failing to open the book. page-list-navigation.epub scenario: Use the reader's go-to-page control to jump to print page 2. expected: The reader lands on the pb2 marker inside chapter two and reports the current page as 2; the page-list nav itself stays hidden from the reading order. rtl-arabic.epub scenario: Open the book and swipe or press the next-page control. expected: Pages advance right to left, text is right-aligned and shaped as connected Arabic, and the contents list reads in the same direction. rtl-hebrew.epub scenario: Open the book and compare rendering and page-turn direction with the Arabic fixture. expected: Text runs right to left with no attempt at cursive joining, and pages advance in the same direction as the Arabic book. vertical-japanese.epub scenario: Open the book in a reader that claims vertical writing support. expected: Lines run top to bottom and stack right to left, page turns advance leftwards, and the prefixed properties are honoured if the unprefixed one is not. mixed-bidi.epub scenario: Render the chapter and read the invoice number and the Arabic run in place. expected: Each isolated run keeps its own direction, the invoice number reads INV-2026-0043 left to right, and neither run reorders the text around it. ltr-control.epub scenario: Diff this package against the Arabic fixture and compare reader behaviour. expected: Pages advance left to right and text is left-aligned; the only package differences are dc:language and page-progression-direction. mathml-declared.epub scenario: Open the chapter in a reader and inspect the equation. expected: The fraction, radical and superscript are laid out as mathematics, and the manifest property lets a reader decide up front whether it can render the document. mathml-undeclared.epub scenario: Validate the package, then render the chapter. expected: A validator reports the undeclared mathml property; most readers still render the equation, which is exactly why the mistake survives into production. mathml-altimg-fallback.epub scenario: Render the chapter in a reader with no MathML layout engine, then with a screen reader. expected: The 96x24 altimg is shown in place of the markup, and assistive technology announces the alttext reading instead of spelling out the element names. svg-content-document.epub scenario: Page through the book from the beginning. expected: The SVG page renders as the first page of the reading order with its title and three labelled blocks; it is not skipped, downloaded, or shown as raw markup. inline-svg-in-xhtml.epub scenario: Render the chapter and inspect the chart and its accessible name. expected: Three bars are drawn inline at the declared viewBox ratio, and assistive technology reports the aria-label rather than reading the markup. svg-cover-page.epub scenario: Ask a tool for the book's cover image, then open the book at page one. expected: The cover renders with both the vector frame and the embedded raster; a cover-extraction tool resolves cover-image to cover.png rather than failing on the SVG spine item. nested-nav-four-levels.epub scenario: Open the table of contents and expand it to its deepest level. expected: All four levels are shown as a hierarchy with the deepest entries reachable, and every anchor scrolls to its heading inside the part document. nested-ncx-four-levels.epub scenario: Open the contents in a reader that consumes the NCX and compare with the nav document. expected: Both surfaces expose the same four-level hierarchy in the same order, and playOrder increments depth-first from 1 to the total navPoint count. flat-toc-twin.epub scenario: Open the contents and compare the shape with the nested twin. expected: A single flat list of the same entries appears, in the same order as the nested twin's depth-first traversal, with no indentation levels. linear-no-back-matter.epub scenario: Page forward from chapter one to the end of the book, then follow the Endnotes link. expected: Paging stops after chapter three and never lands on the notes or colophon; following the link opens the endnotes, and the reader returns to the sequence afterwards. all-items-linear-no.epub scenario: Open the book with no prior reading position. expected: The reader opens the first document anyway or shows the contents rather than a blank pane, and does not treat the empty reading order as a load failure. duplicate-itemref.epub scenario: Page through the book and watch the reading-progress indicator. expected: A validator reports the duplicated itemref; the reader shows chapter one twice or de-duplicates it, and progress never exceeds one hundred per cent or runs backwards. unresolved-spine-idref.epub scenario: Open the book and page through to the end of the reading order. expected: A validator reports the unresolved idref; the reader shows the three real chapters and either skips or reports the fourth position rather than failing to open the book. manifest-missing-file.epub scenario: Page forward past chapter two, and follow the third entry in the contents. expected: A validator reports the missing resource; the reader surfaces a per-document error for chapter three and keeps chapters one and two readable. wrong-media-type.epub scenario: Validate the package, then page from chapter one into chapter two. expected: A validator reports the non-core media type in the spine; a reader either renders the document anyway by sniffing the bytes or reports the type mismatch, rather than showing a blank page. duplicate-manifest-id.epub scenario: Parse the package document and resolve each spine idref to a manifest item. expected: An XML validator reports the duplicate ID; a reader resolves each idref to the first matching item, so chapter two appears twice and chapter three never enters the reading order. container-no-rootfile.epub scenario: Open the book, then unzip it and confirm the package document is present. expected: A validator reports the missing rootfile; a reader either reports an unreadable container with a clear message or recovers by locating OEBPS/content.opf itself, and never opens to a blank book with no error. utf8-diacritics.epub scenario: Import the book into a library and sort, search, and derive a filename from the title. expected: The title round-trips unchanged, the combining sequence is not split or dropped, and search matches whether the query is typed precomposed or decomposed. numeric-character-references.epub scenario: Read dc:title and dc:subject and display them in a library listing. expected: An XML parser yields the decoded Han and Cyrillic text; anything that shows the raw &#x.... sequences is reading the file as text rather than as XML. utf16-package-document.epub scenario: Parse the package document and read the title and manifest. expected: The XML declaration and BOM are honoured, the metadata and manifest parse correctly, and the mixed encodings across files in one container are handled per file rather than per book. astral-plane-characters.epub scenario: Display the title in a library, truncate it for a card, and use it to build a filename. expected: Both astral characters survive display and truncation intact; no lone surrogate, replacement character, or mojibake appears at any truncation point. bom-on-every-xml-part.epub scenario: Parse each XML part in the container with a strict XML parser. expected: The BOM is consumed as an encoding signature rather than as document content; no part reports a stray character before the XML declaration, and the title reads correctly. meta-refines-chain.epub scenario: Extract the display title, the sort name, and the series position for a library listing. expected: The main title and subtitle are distinguished by their title-type refines rather than by order, the author sorts under Brandt-Nakamura, and the book reports as position 4 of The Conformance Shelf. same-book-epub2.epub scenario: Convert this file to EPUB 3 and diff the result against the shipped EPUB 3 twin. expected: Both chapters, the cover and the reading order survive; the guide's cover reference becomes a cover-image manifest property and no chapter text changes. same-book-epub3.epub scenario: Convert to EPUB 2 and to FB2, then diff against the two shipped twins. expected: Chapter text is byte-identical after conversion, the cover survives in each format's own convention, and the two-entry table of contents is preserved. same-book.fb2 scenario: Convert the FB2 to EPUB 3 and compare with the shipped EPUB 3 twin. expected: Both sections become chapters in the same order with identical text, and the FB2 description block maps onto dc:title, dc:creator and dc:language rather than being dropped. ncx-page-list.epub scenario: Open the book in a reader that supports print-page navigation, then convert it to EPUB 3. expected: Go-to-page reaches each of the three anchors; conversion to EPUB 3 produces an equivalent page-list nav with the same three page numbers rather than discarding them. meta-cover-no-guide.epub scenario: Ask a library tool or converter for this book's cover image. expected: The tool follows meta name="cover" to the my-cover-image manifest item and returns cover.png, rather than reporting no cover because there is no cover page or guide reference. binary-cover.fb2 scenario: Extract the cover image and convert the book to EPUB. expected: The binary element decodes to a valid 150x200 PNG, and conversion writes it out as a real image file referenced from the EPUB manifest rather than dropping the cover. nested-sections-and-notes.fb2 scenario: Generate a table of contents from the file and convert it to EPUB 3. expected: All three heading levels appear in the contents, the outer section's own prose is not lost, and the notes body converts to an endnotes document reached by the footnote link rather than appearing in the main reading order. windows-1251-encoded.fb2 scenario: Parse the file with an XML parser and read the book title and chapter headings. expected: The declared windows-1251 encoding is honoured and the Cyrillic text decodes correctly; reading the bytes as UTF-8 instead produces decode errors rather than silently-wrong text.