[Kayadelenium]

v0.5.11 is out, with three of Doitsu’s four and JSWolf’s request.

Doitsu (#89) — OPF-096 on EPUB 2. You were right to be unsure; it was a bug. Reachability is an EPUB 3 requirement, EPUB 2.0.1 has no such rule. Three things agreed once I looked: every OPF-096 fixture in EPUBCheck’s corpus sits under epub3/, EPUBCheck says nothing about your book, and the note in my own source cited EPUBCheck’s EPUB 3 checker as where I’d read the rule off. Gated now. Same class as #21 and #9 — I clearly have a habit of applying EPUB 3 rules to everything, which is why this came with a test and not just a gate.

playOrder. Also right. All four elements now reported, at the lines EPUBCheck gives. One wrinkle worth spelling out, since it stops this being a plain duplicate scan: elements pointing at the same target may legitimately share a playOrder — one position, two routes. So it’s only a collision when they disagree about where they go, and then every one is named. Handing someone one line of a collision leaves them hunting for its partner.

Adobe page-map. OPF-062 added. The RSC-005 was already there, but the two say different things: one that the document is invalid, the other which non-standard extension is in use — the part that tells an author whether they meant it.

<big>, and <font>/<s>/<strike>/<u> — not fixed, and I’d rather say why than quietly leave it. You’re right on both counts, but they’re one bug and it isn’t a list I can patch. I have no EPUB 2 content model at all: the schema check runs the EPUB 3 (XHTML5) grammar against every content document. That single fact produces your whole table — big is valid XHTML 1.1 but removed in HTML5, so I invent an error; s and u are invalid in XHTML 1.1 but valid in HTML5, so I stay quiet. center agreeing with you is luck: invalid in both.

I could special-case those five and your file would go green today. I won’t, and the reason is last week’s OPF-087: that rule was written to match a fixture rather than the rule, agreed with EPUBCheck on every count of that fixture, scored green on my corpus, and was still wrong. Doing it knowingly, in the same week, isn’t a trade worth making. Filed as #24 with the real scope — an XHTML 1.1

OPS 2.0.1 grammar. Your test file is in the issue as the case to beat, and EPUBCheck’s messages turned out to be a gift: the “expected element …” lists it prints are the content model, spelled out. Better oracle than me guessing from the spec.

The pageList class message. Agreed, looks like an EPUBCheck bug — the NCX DTD has no required class there, and I don’t report it. Worth filing upstream; you’d get a better hearing than me.

JSWolf (#87) — unused fonts and images. Done: OPF-097, usage level, so the book stays valid and you just get told which files nothing uses. Fonts, images, any manifest resource.

“Unused” is narrower than it sounds, deliberately: a hyperlink doesn’t count as using something — only loading it does, an image drawn, a stylesheet applied, a font loaded. Exempt is whatever the reading system itself consumes: spine documents, the nav, the NCX. One case to expect: a cover-image with no cover page gets reported, because the package document names it but nothing draws it. EPUBCheck does the same. The message says “no content document references it” rather than “unused” for that reason — it’s a fact, not advice; deleting anything is your call.

Not me being clever, incidentally — OPF-097 is EPUBCheck’s own message, it just wasn’t implemented here. Which is a good lead-in to PeterT.

PeterT (#88) — “any and all errors, or a 1 for 1 replacement for EPUBCHECK?”

Neither, in a specific way.

EPUBCheck is the authority. It decides what an EPUB error is. If I flag something it passes, I’m not being more thorough, I’m being wrong — and I’m the one explaining it to whoever’s book just got rejected. So on verdicts (valid or not, which ID, what severity) I aim to match it exactly, and every disagreement so far has been my bug, not theirs. Four in two weeks, all found by people in this thread.

Where I intend to be better is detail, because it costs nothing and takes nothing away: exact line and column where EPUBCheck gives a file, a machine-resolvable element path in the JSON, a message that names the offending element. Same verdict, more usable. Plus speed and no JVM, which is the actual reason this exists.

Beyond EPUBCheck’s verdict, it’ll be opt-in and never default. JSWolf’s “don’t go by EPUBCheck’s glitches, go with what’s right” is the real tension and I don’t think it fully resolves — but it points one way more than the other. Leading EPUBCheck by being more permissive is safe: nobody’s book breaks. Leading it by being more strict means inventing errors it hasn’t decided on, and looking wrong when it does. So: default tracks EPUBCheck, stricter-if-you-ask sits on top.

One illustration, since this release is a good one. My headline number is 98.8% exact-ID recall against EPUBCheck’s corpus, and nothing in this release moved it, or could have — two of these are usage-level, and that metric only checks the expected ID was reported, not that nothing extra was. OPF-097 doesn’t even have a scenario there. Fourth time in a week that real books found something the corpus structurally cannot see. So part of the answer to “what are the goals” is: not the number. It tracks parity on the cases someone already thought to write down. This thread has been finding the rest, and that’s been worth more.

Binaries: v0.5.11 release page. Keep them coming.