Possible replacement for EPUBCHECK

[KevinH]

You misunderstand. dc:language is for the book. xml:lang is for the contents of the opf (metadata, etc).

[JSWolf]

Originally Posted by KevinH

You misunderstand. dc:language is for the book. xml:lang is for the contents of the opf (metadata, etc).

Thanks for the clarification.

[Kayadelenium]

Thank you all — four reports since 0.11.0, four issues, and all four are things we miss rather than things we wrongly report, which is the direction I much prefer them to arrive in.

Doitsu, enc:EncryptedData with no enc:CipherData — #88 (https://github.com/veripublica/epubveri/issues/88). Our encryption.xml check validates the root element's children and never looks inside them. Worth flagging what I found while writing it up: the requirement inverts between versions. EPUB 3 requires CipherData and makes EncryptionMethod optional; OPF 2.0.1's schema does exactly the opposite. So this needs a version check rather than one rule, or it becomes a false positive on EPUB 2.

JSWolf, empty <tours> — #87 (https://github.com/veripublica/epubveri/issues/87). The grammar knows the element exists and never got its content model. <guide> sits three lines above it in the same file with the right shape already, so the fix is small.

JSWolf, RSC-004 on the encrypted font — #89 (https://github.com/veripublica/epubveri/issues/89). You are right: epubcheck names the font, we name the file that mentions it. The finding is a fact about the font, so epubcheck's location is the correct one. Location only — the message, severity and everything machine-readable stay as they are.

JSWolf, xml:lang on an EPUB 2 <package> — #90 (https://github.com/veripublica/epubveri/issues/90). Wider than the one attribute: epubcheck's EPUB 2 <package> takes only version, unique-identifier and id, and ours takes anything at all. I checked all 312 EPUB 2 books on my test shelf — 310 carry nothing extra, two carry prefix (an EPUB 3 attribute in a 2.0 package, which epubcheck also rejects). So closing this costs nothing and gains two correct findings. Not one book of the 312 has xml:lang on <package>, which is a useful reminder that my shelf can only tell me about constructs it has actually seen.

KevinH — your reading is right, and your last post puts the part that matters better than I would have: dc:language is about the book, xml:lang is about the OPF's own contents, and they are not the same fact. That is exactly why an OPF-specific schema should not have overridden something XML makes available on every element.

It does not change what I will do, though. epubcheck owns the verdict here. A book that fails epubcheck has to fail epubveri too — otherwise someone whose retailer gates on epubcheck has no way to tell my judgement from my bug, and that is the one thing I cannot afford to be ambiguous about. Disagreeing with a rule is a reason to take it upstream, not a reason to stay quiet about it. So I will implement it, and if that argument does go to w3c/epubcheck it should go as yours rather than second-hand from me.

JSWolf — "changing an ePub3 to ePub2 without changing the rest of the code is actually pretty good at finding errors in epubveri" is a fair description of where my weakest surface is, and I am going to steal it. Doing that deliberately across my shelf is a great deal cheaper than waiting for the next one to surface.

All four are queued for the next release.

[JSWolf]

I really appreciate your quick responses and new versions with the fixes. You are doing very well. Thank you.

[Kayadelenium]

epubveri 0.12.0 is out — crates.io, npm and the eight pre-built binaries. This is the release I said the four reports were queued for, so all of them are in it: release notes (https://github.com/veripublica/epubv...es/tag/v0.12.0).

Why 0.12.0 and not 0.11.1, since a third minor bump in three days invites the wrong conclusion. One public Rust function changed shape, which for a pre-1.0 crate forces a minor bump — that is the whole reason. Nothing moves for the CLI, the JSON output or the browser build, with one deliberate exception noted below. And unlike 0.10.0 and 0.11.0, this one is actually about the validator: four real gaps close.

Empty <tours> is now an error (JSWolf, #234). OPF 2.0.1 makes the <tour> child mandatory. I had added <tours> to my grammar in July for the opposite reason — I was wrongly rejecting a legacy book that used it — and what I added was the element's existence, with a permissive placeholder standing in for its content model. Its <guide> neighbour, three lines above in the same file, had required a child all along.

RSC-004 now names the encrypted font, not META-INF/encryption.xml (JSWolf, #235). You were right: the finding is a fact about the font, and epubcheck locates it that way. It carries no position now either, for the same reason epubcheck prints -1,-1 — there is nothing inside a binary to point at. Doitsu, this one is visible in the JSON: the location value changes; code, severity, rule and params do not.

encryption.xml's encrypted items are checked now (Doitsu, #233) — and the part I did not expect is that the requirement inverts between the two versions:

inside <enc:EncryptedData> EPUB 2 EPUB 3
nothing missing EncryptionMethod missing CipherData
EncryptionMethod only accepted missing CipherData
CipherData only method must come first accepted
empty CipherData needs Reference/Value same

Every cell was measured against epubcheck 5.3.0 with one book per shape rather than read off the two schemas, and all eight now agree. That was worth the trouble: my first attempt filed the ordering rule as EPUB 2-only, on the reasonable-sounding grounds that only OPF 2.0.1's grammar is a sequence. Both are — so EPUB 3 was left silent on a file epubcheck reports. Building each shape and asking is what caught it; re-reading my own code would not have.

An EPUB 2 <package> no longer accepts any attribute (JSWolf, #236). epubcheck's list is exactly three — version, unique-identifier, optional id — and mine was a wildcard, so xml:lang and every EPUB 3 attribute passed silently. Across the 312 EPUB 2 books on my shelf this produced two new findings, both prefix="calibre: …" on a 2.0 package, both matching epubcheck exactly, and no false positives. The EPUB 3 grammar is untouched, with a test that says so in both directions: prefix and xml:lang are perfectly valid on a 3.0 package, and closing both lists would have traded a legacy gap for a false positive on most modern books.

KevinH — my view has not changed, only what I ship. Your objection is now written into the source beside the rule, so whoever reads that code next meets the argument and not just the constraint.

Two things I have not done, so they do not sit here looking finished. JSWolf's "changing an ePub3 to ePub2 without changing the rest of the code is actually pretty good at finding errors in epubveri" — I said I would steal that as a test, and I have not started; doing it properly means running it across the whole shelf, not on one book. And the EPUB 2 unused-resources check from earlier in the thread is still where I left it: measured, not promised.

As always — if anything here reports a problem on a book that is actually fine, that is the report I want most, and it jumps the queue ahead of everything else.

[Kayadelenium]

I have published a performance measurement of epubveri against epubcheck:

docs/BENCHMARK.md

First, the part that matters more than the speed. A tool that validates less is not faster, so the document opens with the evidence that both tools did the same work. On the same 385 real books the two agree on the verdict for 384, and a finding-by-finding run found identical message-ID sets on 383 of 385, with no message ID reported by epubveri alone. This is a performance document, not a correctness claim -- for what the two tools actually find, the coverage matrix is the honest place to look.

The setup. epubveri 0.12.0 against epubcheck 5.3.0 on OpenJDK 26, one machine (Apple M2 Pro, 10 cores, 32 GiB), 385 real EPUBs totalling 611 MiB, each tool run alone, both given -u.

  SUMMARY                     epubveri    epubcheck    ratio
  Wall-clock time                 69 s        758 s      11x
  CPU time                        68 s      2 875 s      42x
  Memory, typical book         7.4 MiB      415 MiB      56x
  Install footprint             2.8 MB       434 MB     156x

Time. The same three situations for both tools:

  TIME                        epubveri    epubcheck
  One small book (78 KB)          9 ms       1.76 s
  A typical book (median)       0.08 s       1.89 s
  The whole 385-book library      69 s        758 s

Worth knowing before you quote any ratio: epubcheck's time barely depends on the book. Its median is 1.77 s under 100 KB and 2.00 s at 2-10 MB -- 13% over a hundredfold range of content.

CPU.

  CPU                         epubveri    epubcheck
  Whole library                   68 s      2 875 s
  A typical book (median)       0.07 s       7.02 s
  Cores busy while running        0.99         3.79

The CPU gap is four times the clock gap, and that last row is why: epubcheck keeps about 3.79 cores busy -- JIT compiler and garbage collector threads alongside the work -- while epubveri is single-threaded. So epubcheck wins part of the wall-clock difference back through parallelism, but it takes that from the rest of the machine. If you are running a pipeline where you want those cores for your own concurrency, or you are on battery, the CPU column is the one that applies to you rather than the clock.

Memory.

  MEMORY (peak RSS)           epubveri    epubcheck
  A typical book (median)      7.4 MiB      415 MiB
  Worst book on the shelf       90 MiB    1 687 MiB
  Books needing over 512 MiB         0           94
  Books needing over 1 GiB           0            6

The tail says more than the average here. A quarter of my shelf pushes epubcheck past 512 MiB. In a memory-capped container, or inside an application, that is the number that decides whether the tool fits at all.

Disk.

  DISK                        epubveri    epubcheck
  Application / libraries       2.8 MB      36.4 MB
  Runtime required                none       398 MB
  Total to install              2.8 MB       434 MB

  Release archive, per OS   1.0-1.3 MB
  Browser build, over wire      477 KB

epubveri is one file with no runtime; epubcheck is 40 jars plus the JVM they need. Disk traffic during validation was not a differentiator -- with a warm cache neither tool reached the disk, and on a cold one both must read the same book.

Where the difference comes from, stated fairly to epubcheck. The usual explanation is JVM startup. I measured it, and it is not: a bare JVM starts in 22 ms and loading epubcheck's classes takes 65 ms, against 1758 ms to validate the smallest book on my shelf. Nor is it work proportional to the book, as the flat line above shows. About 1.7 seconds is fixed setup performed inside the validation path, most likely compiling the RELAX NG and Schematron schemas, so roughly 90% of a typical epubcheck run is book-independent. epubveri has no equivalent only because its schemas are compiled into the binary.

That also states epubcheck's best case: subtract each tool's floor and the remaining per-book work is about 0.13 s against 0.07 s -- much closer. epubcheck simply cannot reach it from the command line, which takes one file per invocation, so it pays the 1.7 s again for every book.

Limits, plainly. One machine, one library, one day. My shelf is mostly Turkish trade titles, Calibre output and Project Gutenberg. epubcheck ran with default JVM settings. Nothing was measured under parallelism. Any number above is an observation, not a property of either tool.

Which brings me to a request. I would rather you checked this than believed it.

• Run epubveri over your own books. Your libraries are nothing like mine. Several of the wrong errors I have fixed since 0.9.x were found by people in this thread rather than by my own test corpus, and the ones that reached a user all arrived that way. A false positive -- an error on a book you know is fine -- is the report I most want. A missing error is worth reporting too, just less urgent.
• If you have Java installed, run the comparison yourself. The recipe is in the document. The one thing that makes it unfair if you skip it is the -u flag: epubcheck hides usage findings by default and much of epubveri's output is usage, so pass it to both.

epubveri -u -i book.epub
java -jar epubcheck.jar -u book.epub

If your numbers come out different from mine, that is useful and I would like to see them -- a slower machine, a bigger book, a producer I have never seen. And if the two tools disagree about a book, that is more useful still. Downloads for eight platforms and a step-by-step guide are here if you have not tried it before: docs/USAGE.md.

[Kayadelenium]

epubveri 0.12.1 and 0.12.2 are out, and the idea behind both came from this thread.

JSWolf wrote a while back: "changing an ePub3 to ePub2 is pretty good at finding errors in epubveri." I said I'd steal that as a test. I finally did, and it was a better idea than I gave it credit for.

The tool takes every EPUB 3 book on my shelf, re-declares it as EPUB 2 — the version attribute on <package>, nothing else — and diffs epubveri against epubcheck on the result. The books it makes are massively invalid on purpose; that's fine, because the question isn't "is this book any good", it's "do the two tools agree about it". And it reaches something nothing else here could: the markup that stresses the EPUB 2 rules (HTML5 vocabulary, ARIA, epub:type, microdata, MathML) only exists on my shelf inside books that declare 3.0, where those rules never run.

Sixteen defects. Thirteen were the same shape — a rule epubcheck runs only for EPUB 3, firing on EPUB 2 books: the epub:type vocabulary family, deprecation warnings for epub:trigger/epub:switch/DPUB-ARIA roles, HTML5 microdata, MathML alt-text, the viewport family, CSS-015, and data: URLs in two places. Seven came straight out of the run; the rest from auditing the code around those seven, which the run couldn't have shown me because no book of mine carries the markup.

The other three:

- OPF-042, which I had backwards in both directions at once — missing on EPUB 2 where epubcheck reports it, and reported on EPUB 3 where epubcheck can't.
- A subtree in a namespace the grammar doesn't have (MathML in an EPUB 2 document, say) drew one error per element instead of one for the excursion. On one converted book: 243,483 findings from epubveri against epubcheck's 10,475. Now we say it once and stop, as epubcheck does.
- EPUB 2 validates inline SVG against SVG 1.1 normatively, and I'd been silent on all of it. 0.12.2 adds the required-attribute part (rect needs width and height, circle needs r…), each row checked against epubcheck one book at a time. The rest of that grammar is filed as an open issue — it's a big piece of work and I'd rather not add a new error surface in a hurry.

Who this helps: almost nobody, and then some people a lot. Validating an ordinary EPUB 2 from a normal tool, nothing changes — all 405 books on my shelf give byte-identical output before and after. The benefit is for anyone converting EPUB 3 to EPUB 2 and validating the result: Sigil, Calibre, any downgrading pipeline. Which is where the idea came from.

About the 100% figure, because it looks like more than it is. The README now says 607 of 607 on epubcheck's own test suite, up from 606. Nothing in the validator changed to make that happen. The last "miss" wasn't a defect: epubcheck can check a bare package document on its own and the suite has a scenario for that mode, while epubveri takes a packaged .epub only — so my harness wraps the fixture into a minimal book, and handed that same book epubcheck reports exactly the code epubveri reports. The suite scores the same defect separately in its packaged form, and epubveri already passed that one. So I fixed the measurement, not the tool, and the run prints the substitution every time. There was another route to 607/607 — emit the extra code alongside the right one — and I'm not taking it. Inventing a finding to move a number is the one thing this measurement must never do.

The ask from my last post still stands. Run epubveri over your own books and tell me about false positives; an error on a book that's actually fine is the report I want most. For the record: across the full 405-book shelf, and across W3C's own conformance suite, there is currently no message ID that epubveri reports and epubcheck doesn't. That's a fact about my books and W3C's tests, not about yours.

One known divergence I've filed rather than guessed at: when an element the EPUB 2 grammar doesn't have (say <center>) holds invalid children directly, we report each child and epubcheck reports only the container. The rule it follows lives inside a schema library I can't read, both obvious explanations failed when tested, and it has never happened on a real book.

Downloads for the eight platforms are on the release page; full notes for both versions are in the changelog.

https://github.com/veripublica/epubveri/releases

[Doitsu]

@Kayadelenium

epubveri missed one error in this old MR epub3 book.

ERROR(RSC-032): Fallback must be provided for foreign resources, but found none for resource "OEBPS/Misc/ls.js

If the mimetype is changed to:

<item id="ls.js" href="Misc/ls.js" media-type="text/javascript"/>

EPUBCheck no longer insists on a fallback declaration.

I also have one suggestion.

Currently, epubveri says:

USAGE OPF-090: media-type 'application/vnd.ms-opentype' is a non-preferred (but valid) Core Media Type

while EPUBCheck actually says what the preferred media type is:

USAGE(OPF-090): It is encouraged to use MIME media type "font/otf" instead of "application/vnd.ms-opentype".

It'd be helpful, if you also added the actual preferred media type.

As for testing, since my simple Calibre plugin has been downloaded more than a 100 times, maybe you should also ask in the Calibre forum that Calibre users report differences between epubveri and EPUBCheck on Github or in this thread. (I also created an EPUBCheck Calibre plugin a long time ago, which makes it easy for Calibre users to compare the output of both validators.)

[Kayadelenium]

@Doitsu — thanks. The reported one turns out to be deliberate, and then it found three things that weren't.

The RSC-032 on the .js. I reproduced it exactly, and epubveri is quiet on purpose. EPUB 3.4 exempts a resource referenced from <script src> from the foreign-resource fallback requirement — that's the spec editor's own [w3c/epubcheck#1654], marked accepted. epubcheck hasn't implemented it yet; epubveri has. It's the permissive direction — we accept something epubcheck rejects — which I ship without a flag, because the cost is a difference against epubcheck-as-it-is and nothing against the spec as it will be. Anything going the other way (us stricter than epubcheck) stays behind --advisory.

Your workaround works for a different reason than it looks: text/javascript is a Core Media Type, so the fallback question never comes up at all — which is why it draws OPF-090 instead.

There's a test whose only job is to stop someone widening that check and silently killing the exemption. Investigating your post, I widened it. The test failed within the hour. I've now put the reason next to the list rather than only in the test.

What your report actually found. Once I asked which other references epubveri never poses the fallback question to, three real defects fell out:

- iframe@src — never asked at all.
- input@src — asked only when type="image". epubcheck registers it whatever the type is.
- And the one that matters: input@src wasn't counted as referencing its target either, so an ordinary <input type="image" src="cover.png"> drew OPF-097: 'cover.png' is declared in the manifest, but no content document references it. That's a false positive on valid HTML5, epubcheck is silent on the same book, and nobody had reported it.

Two hand-maintained lists that answer different questions about the same markup had drifted apart. That's the third time that shape has bitten me; the list is now written down against its source in epubcheck's own handler, with the <script> exemption recorded in the same place so the next person doesn't undo it either.

OPF-090. Done, and you're right that "non-preferred" alone names the problem without naming the fix. It now reads:

media-type 'application/vnd.ms-opentype' is a non-preferred (but valid) Core Media Type; 'font/otf' is preferred

All six non-preferred types have a row, each checked against epubcheck one book at a time — including application/font-sfnt, which epubcheck resolves by file extension and reports as font/(ttf|otf) when it's neither.

All of the above is in the next release.

[Kayadelenium]

epubveri 0.12.3 is out. Eight changes, and the honest headline is that two of them are false positives we had been shipping — neither reported by anyone, both found while chasing something else.

Doitsu's report (thanks again) accounted for three. The RSC-032 he found is deliberate and I answered that separately — EPUB 3.4 exempts a resource referenced from

<script src>

and epubcheck hasn't implemented that yet. But asking which other references we never posed the fallback question to turned up three real defects:

iframe@src

was never asked,

input@src

was asked only when

type="image"

, and — the one that matters —

input@src

wasn't counted as referencing its target either, so an ordinary

<input type="image" src="cover.png">

drew

OPF-097: 'cover.png' is declared in the manifest, but no content document references it

. Wrong, on valid HTML5, and epubcheck is silent on the same book.

OPF-090

also now names the replacement, which was Doitsu's suggestion:

media-type 'application/vnd.ms-opentype' is a non-preferred (but valid) Core Media Type; 'font/otf' is preferred

.

The second false positive had been there since the SVG checks were written. Eleven ordinary SVG 1.1 element names were missing from our vocabulary —

altGlyph

,

color-profile

, the

font-face-*

family and others — so we were reporting valid SVG as unrecognised. Usage level, so no book's verdict moved, but wrong all the same.

No book could have shown it to me. Nothing in my 405-book test shelf uses SVG fonts or a colour profile, so the tool that diffs my output against epubcheck's over real books never had a chance. It came out of extracting the element declarations from epubcheck's own schema and diffing them against my list. Two related things went in beside it: SVG required attributes are now checked at EPUB 3 as well as EPUB 2 (epubcheck runs that grammar normatively for one and informatively for the other), and

OPF-037

no longer fires on EPUB 3 books.

That last one is worth a sentence because of how it was found. Its only call site in epubcheck sits in a base class, so it looks version-neutral to any search — what actually scopes it is that the EPUB 3 subclass overrides that method without calling

super

. Three separate audits of mine walked straight past it. It's now checked mechanically instead of remembered.

Two documentation changes, both prompted by people here.

For plugin and tool authors: the release archive names are now written down and promised — eight archives named after the Rust target triple, stable, added to but never renamed. Doitsu asked for exactly that, and it's in

docs/INTEGRATING.md

rather than in a reply to him, so the calibre plugin and whoever comes next read the same page. There's a section beside it on how often to update, which is a real question for a validator: new checks mean a book that was clean yesterday can be flagged today with nothing changed by its author.

And for everyone downloading the program: the instructions now tell you to ignore the two "Source code" archives GitHub adds to every release page automatically. They contain source text, not the program, and nothing in them will run. That one came from KevinH explaining why Sigil keeps plugin distribution off GitHub — his users kept downloading the wrong zip. It's a failure mode of the release page, and it applied to me too.

The standing ask is unchanged and this release is the argument for it. Both of the wrong findings above were on valid markup, both were invisible to every automatic check I have, and both surfaced only because someone reported something adjacent. If epubveri flags something in a book you believe is fine, please say so — that is still the most useful thing anyone can send me.

Downloads for the eight platforms are on the release page; full notes in the changelog.

[Doitsu]

@Kayadelenium

epubveri reports 10 fatal errors for this obfuscation test epub, but EPUBCheck reports only 6 errors.

Even though it's technically completely invalid it displays fine with ADE 4.5 and the Calibre e-book viewer.

[Kayadelenium]

Thank you — fixed, and sending both tools' output beside the book is what made it a ten-minute diagnosis instead of an afternoon.

You were right that this is about the obfuscation. Both tools say RSC-004 "its content will not be checked"; epubcheck means it, and we said it and then parsed the file anyway. An obfuscated resource's bytes are ciphertext, so of course they are not well-formed XHTML — that is fifteen findings on a valid book, ten of them fatal.

The fatals were the worse half. A fatal drops the rest of that document's findings, so the false positives were also hiding anything that was genuinely wrong in those files.

One deliberate detail, since it is the kind of thing that looks like a missed case: the filter is on the resource's *content*, not on the resource. An encrypted font is still checked for OPF-097 and PKG-026, exactly as epubcheck reports them on your book. Our output for it now matches epubcheck's exactly.

The fix is on main and will be in the next release. It is worth saying that nothing here could have found this: two of the 405 books we test against carry an encryption.xml and both are clean, and epubcheck's own test corpus has no obfuscated file that is also unparseable. That is the fourth false positive of yours that no instrument of ours could reach.

Issue: https://github.com/veripublica/epubveri/issues/101

[Kayadelenium]

epubveri 0.12.4 — https://github.com/veripublica/epubveri/releases/latest

Mostly a false-positive release: eight wrong findings on valid books.

The one that mattered is Doitsu's, from the obfuscation test book. An obfuscated resource's bytes are ciphertext — and although we printed RSC-004: its content will not be checked, we then went and checked it. Fifteen findings epubcheck doesn't make, ten of them fatal, and the fatals were the worse half: a fatal drops the rest of that document's findings, so they were also hiding whatever was really in those files. Thank you for sending both tools' output beside the book — that turned an afternoon into ten minutes.

The other seven I found by running epubcheck over its own test fixtures and diffing the two outputs. That asks a different question from the one our harness asks, and it sees a class the harness structurally cannot.

New, and relevant if you install or distribute the plugin: every release archive now ships a SHA256SUMS.txt and a signed build attestation.

shasum -a 256 -c SHA256SUMS.txt --ignore-missing
gh attestation verify epubveri-<target>.tar.gz --repo veripublica/epubveri

The second is the one that carries weight: signed by GitHub for this repository, naming the commit and workflow that produced the file. It comes straight out of KevinH's point in the plugin thread — plugins are short, pure Python, so read the source. Fair, and it doesn't reach a wrapper around a compiled binary. So this is my half of it.

One correction while I'm here: our published corpus recall now reads 599 of 599 instead of 607 of 607. Eight EDUPUB fixtures can't pose their question the way our harness packages them — epubcheck reports nothing there either — and they'd been counted as passes. A smaller denominator, not a better score; the README says why.

[JSWolf]

I've found more errors.

The book is a KF8 converted to ePub using KindleUnpack. That's where this error came from.

Here is the relevant code in the OPF file.

  <guide>
    <referen/>
    <reference type="start" title="Start" href="Text/cover.xhtml"/>
  </guide>

epubveri shows no error. epubcheck shows:

content.opf Line:47 Col:15 ERROR(RSC-005): Error while parsing file: element "referen" not allowed anywhere; expected element "reference"

If I change <referen/> to <abcdefg/> epubcheck shows:

content.opf Line:47 Col:15 ERROR(RSC-005): Error while parsing file: element "referen" not allowed anywhere; expected element "reference"

Now, I changed the ePub from 2.0 to 3.0 and now I find epubveri and epubcheck do not match the line/column for the next error.

Here is the OPF:

<?xml version='1.0' encoding='utf-8'?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" unique-identifier="uid">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title>The Long Game</dc:title>
    <dc:creator>Leckie, Ann</dc:creator>
    <dc:language>en</dc:language>
    <dc:identifier id="uid">1544457272</dc:identifier>
    <dc:identifier>urn:uuid:f9d24f3b-ddf4-4a1e-bdf2-f96c3bfe591c</dc:identifier>
    <dc:publisher>Amazon Original Stories</dc:publisher>
    <dc:source>eBook ISBN: 9781662515675</dc:source>
    <dc:date>2023-06-27</dc:date>
    <dc:rights>All rights reserved.</dc:rights>
  </metadata>
  <manifest>
    <item id="inserted" media-type="application/xhtml+xml" href="Text/cover.xhtml"/>
    <item id="x_titlepage" media-type="application/xhtml+xml" href="Text/titlepage.xhtml"/>
    <item id="x_copyright" media-type="application/xhtml+xml" href="Text/copyright.xhtml"/>
    <item id="x_startreading" media-type="application/xhtml+xml" href="Text/chapter01.xhtml"/>
    <item id="x_ch02" media-type="application/xhtml+xml" href="Text/chapter02.xhtml"/>
    <item id="x_ch03" media-type="application/xhtml+xml" href="Text/chapter03.xhtml"/>
    <item id="x_ch04" media-type="application/xhtml+xml" href="Text/chapter04.xhtml"/>
    <item id="x_ch05" media-type="application/xhtml+xml" href="Text/chapter05.xhtml"/>
    <item id="x_ch06" media-type="application/xhtml+xml" href="Text/chapter06.xhtml"/>
    <item id="x_ch07" media-type="application/xhtml+xml" href="Text/chapter07.xhtml"/>
    <item id="x_ata" media-type="application/xhtml+xml" href="Text/abouttheauthor.xhtml"/>
    <item id="ncx" media-type="application/x-dtbncx+xml" href="toc.ncx"/>
    <item id="item12" media-type="text/css" href="Styles/style0001.css"/>
    <item id="item16" media-type="image/jpeg" href="Images/author.jpg"/>
    <item id="x_cover-image" media-type="image/jpeg" href="Images/cover.jpg"/>
    <item id="item15" media-type="image/jpeg" href="Images/image00034.jpeg"/>
    <item id="item14" media-type="image/jpeg" href="Images/titlepage.jpg"/>
  </manifest>
  <spine toc="ncx">
    <itemref idref="inserted"/>
    <itemref idref="x_titlepage"/>
    <itemref idref="x_copyright"/>
    <itemref idref="x_startreading"/>
    <itemref idref="x_ch02"/>
    <itemref idref="x_ch03"/>
    <itemref idref="x_ch04"/>
    <itemref idref="x_ch05"/>
    <itemref idref="x_ch06"/>
    <itemref idref="x_ch07"/>
    <itemref idref="x_ata"/>
  </spine>
  <guide>
    <reference type="start" title="Start" href="Text/cover.xhtml"/>
  </guide>
</package>

epubveri shows:

OEBPS/content.opf	2	1	ERROR RSC-005: EPUB 3 requires a navigation document (a manifest item with properties="nav")

epubcheck shows:

content.opf Line:15 Col:13 ERROR(RSC-005): Error while parsing file: Exactly one manifest item must declare the "nav" property (number of "nav" items: 0).

[Kayadelenium]

epubveri 0.12.5 — https://github.com/veripublica/epubveri/releases/latest

Sixteen items. Both of JSWolf's are in it.

<guide><referen/></guide> now errors, as it does in epubcheck. Our grammar allowed any element name there. The comment explaining why said that naming the child "would duplicate a violation the surrounding grammar already reports" — and nothing reported it. Fixing it turned up two more beside it: <tours>'s child must be named tour, and a <tour> must contain <site> elements. Both were silent here and both error in epubcheck.

The missing-nav error now points at <manifest> instead of the package root. Nothing about the finding was wrong, only where it said to look, which is the whole of the problem if your editor jumps to the position. The line matches epubcheck exactly now; the column still differs by one convention — we point at the start of a tag and it points at the end, consistently, everywhere.

The other fourteen came from running epubcheck over its own test fixtures and diffing the two outputs, which turns out to see a class our usual test run structurally cannot. Eleven were false positives — findings we made on markup epubcheck accepts — and the rest were things we owed and had not made.

One shape appeared in three unrelated places and is worth naming, since it is the failure a user cannot notice: a check that defers to another check which does not cover the case. The <guide> child above was one. The OCF filename rules asked the manifest href because "an existing file's real name is already checked" — the condition was inverted. A media overlay's targets were "collected by the overlay pass", which ran after the question was asked. None of the three was a wrong answer. Each was no answer at all.

Finally, a correction that goes the other way from yesterday's. The published corpus figure moves from 595 to 603 because the denominator grew: our own test harness had been wrapping loose fixtures in a way that stopped epubcheck asking about eight of them, so they could not be scored at all. That was our harness's doing, not the suite's. Fixed, and verified from epubcheck's side — handed the rebuilt books it now reports the finding the feature file expects, where before it reported nothing.