Possible replacement for EPUBCHECK - Page 8

Kayadelenium · Yesterday, 03:38 AM

Doitsu — thank you, that's exactly the evidence I asked for, and it settles it: no divergence. EPUBCheck flags big and center as RSC-005 errors, so it rejects obsolete elements just like epubveri does. We quietly agree, and there's nothing to file upstream.

The one thing worth noting is why your output shows two errors and epubveri shows four. EPUBCheck reports big (in the first <p>) and center (directly in <body>) — but not the font and strike, because both sit inside the <center> it already rejected, and the RELAX NG validator doesn't descend into an element it has thrown out. So its schema does exclude all five (big, center, font, strike, tt) exactly as I read it — the two that surface are just the ones not masked by a rejected parent. epubveri validates the children on their own merits too, so it names font and strike in the same pass. Same verdict, same IDs, same severity — one extra pass of detail, so you fix everything at once instead of re-running after unwrapping the center.

(And s / u stay unflagged in both, since they're still conforming.) Appreciate you building the test book — settling this on evidence rather than my guess is worth a lot.

Doitsu · Yesterday, 05:01 AM

Unfortunately, I've found another test case where incorrect attributes weren't flagged in epub2 and epub3 books.

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title>word html</title>
</head>

<body vlink="purple" link="blue" class="calibre">

<h1 vlink="purple" link="blue" class="calibre">word html</h1>
  <p class="MsoNormal">lorem <span class="calibre1"> <br clear="all" class="calibre2" id="calibre_pb_1"/>ipsum</span></p>

  <p class="MsoNormal"><a name="_ftnref3" class="calibre7" id="_ftnref3">footnote</a> dolor amet</p>

  <hr width="33%" size="1" class="calibre13"/>
</body>

epubveri flagged none of them, while EPUBCheck reported link, vlink, clear, name, width and size. See the attached .csv files for more information. (Column B is the line number, column C is the character offset.)

JSWolf · Yesterday, 05:23 AM

@Kayadelenium I think we have to stop going with what's valid CSS and go with what's valid CSS for ePub2 and ePub3. Because what may be allowed for a website may not be allowed in an eBook and even if it's allowed, it may not work.

As for fonts, I see your point about unused @font-face declarations since you would have to do a full scan of the entire CSS to check if it's used or not.. But we really do need to flag any font-family that specifically specifies a font name that has no @font-face to go with it such as font-family: "Times New Roman" when that isn't an embedded font. On some programs, that could prevent selecting a font. So I would flag the font-family when there's no embedded font to go with it.

Kayadelenium · Yesterday, 06:55 AM

v0.5.17 is out — again straight from this page.

Doitsu — the obsolete attributes (#107). Fixed: link, vlink, clear, name, width and size are now flagged (RSC-005) on the legacy hosts where they don’t belong. Two things your paired test made me get right that I’d have missed with a single book:

First, the count. EPUBCheck reports one message per offending attribute, so I do too — every occurrence at its own attribute, not one summary per element. Your EPUB 2 book comes back with 8 and your EPUB 3 book with 7, matching your CSVs line for line.

Second — and this is the reason a paired EPUB 2 / EPUB 3 test was worth so much more than either alone — those two numbers differ, and only on name. EPUBCheck flags name on <a> in EPUB 2 but not in EPUB 3. My first cut flagged it in both, which would have over-reported against EPUBCheck on every EPUB 3. So I went and checked EPUBCheck’s own schemas: its EPUB 2 content model is XHTML 1.1, whose <a> genuinely has no name attribute (1.1 dropped it in favour of id), while its EPUB 3 XHTML5 schema still permits name on <a>. So a@name is now an EPUB 2-only rule. Worth being straight here: WHATWG does consider name on <a> obsolete, so by the letter of the living spec EPUBCheck is lenient in EPUB 3 — but since the whole point is to match EPUBCheck’s verdicts, I follow EPUBCheck rather than invent a stricter one. (Same principle as the strike discussion above, just pointing the other way.)

One design note in case it’s useful: width/size/name are only obsolete on these hosts. width is still valid on <img>, size on <input>, name on <input>/<form>/<meta> — so I can’t just ban the names outright, or I’d fire on the near-universal <meta name>. They’re pinned per host; link/vlink/clear have no valid host anywhere and are flagged on any element.

JSWolf — a font-family with no @font-face. I’ve thought hard about this one and I’m going to be honest rather than half-ship it: I’ve decided not to do it, for the same reason EPUBCheck doesn’t. The problem is that CSS gives no way to tell two cases apart. font-family: "Times New Roman" names a system font that must not have an @font-face — it’s on the device already. font-family: "MyEmbeddedSerif" names an embedded font that must have one. Both look identical to a validator: a family name with no matching @font-face. So a check that flags “named font, no @font-face” would fire on essentially every book that uses Georgia, Arial, or any of the dozen web-safe faces — which is almost all of them. The only way to narrow it is a hand-kept “these are system fonts” allowlist, and that list is device-dependent and never complete: what’s a system font on a Kobo isn’t one on a Kindle. I’d be trading a real problem I can’t see for a steady stream of false alarms on books that are fine. My rule for this whole project is that I’d rather report nothing than report wrongly, so this stays out — but the door’s open if anyone finds a heuristic that doesn’t misfire.

On the broader point behind it — “validate against what’s valid for EPUB, not just the web” — I agree in principle, and that’s exactly what the EPUB 2 vs EPUB 3 split above is: the content model already tracks each version’s own vocabulary, not one generic HTML. Where I’ll push back is only when “invalid for EPUB” can’t actually be determined from the file, which is the @font-face case.

A word on where this is heading, since this page has shaped so much of it. My aim is to get epubveri to a genuinely stable release — not “feature complete”, but solid and predictable — and then shift most of my weight to the repair side: a companion tool that doesn’t just find these problems but fixes them. I’ll be honest that this is where the real difficulty and the real time sink is. Telling you an <a name> is wrong is one thing; safely rewriting it without breaking the book around it, across the thousands of shapes real books come in, is a much harder problem, and that’s the part I expect to spend the most time on. Once that’s carrying its weight, I want to take the producer/ conversion side and see how close I can get a single book to genuinely correct, end to end — validate, repair, rebuild, repeat.

And beyond the EPUB tooling itself, I’ve got two or three other ideas in my head — things that wouldn’t just help people who make ebooks, but that could be useful to just about anyone. I’m turning those over on the side, and I think it’s right to spend some of this energy there too rather than pour all of it into one funnel. I’ll say more when they’re real enough to show rather than just describe.

Binaries: v0.5.17 release page. Thanks again — this test pair was the kind that teaches the tool something it couldn’t have learned from a single book.

Doitsu · Yesterday, 01:41 PM

@Kayadelenium

Unfortunately, the attribute detection code isn't ready for production yet, because epubveri, will fail to detect made-up or mistyped attributes.

For example, it won't flag the following:

Code:

  <p fake="fake" clas="header">*</p>

I don't expect much from an EPUB validator but at a bare minimum it must be able to reliably detect valid and invalid tags and valid and invalid attributes.

I had your code checked by Claude.ai and it suggested the following, which hopefully will make sense to you:

Quote:

Originally Posted by claude.ai

Enumerate the true global attribute set; delete the wildcard.
File: schemas/xhtml.rng, globalAttrsCore (lines 117–140).
Change: remove <ref name="anyOtherAttr"/> (line 139) and the anyOtherAttr define (lines 161–183) entirely. In their place, add explicit <optional><attribute name="..."> entries for the real fixed-size HTML5 global set that isn't already listed: draggable, itemscope, itemtype, itemid, itemref, itemprop, role, slot, part, is, inputmode, enterkeyhint, popover, plus the full ARIA attribute list (aria-label, aria-hidden, aria-describedby, aria-live, aria-labelledby, etc. — WAI-ARIA 1.2 defines a closed, finite set, so this is a real enumeration, not a prefix match). These are all closed, spec-defined lists, so this is pure schema authoring, no engine work.

Handle data-* outside RNG, since it's the one genuinely open-ended family.

rantanplan · Yesterday, 01:44 PM

The tool doesn't seem to list the errors chronologically. I chose a epub with lots of the same errors and you can see that seems to be listed in a random order.

Click image for larger version

Name: Bildschirmfoto 2026-07-19 um 13.51.49.png
Views: 12
Size: 145.0 KB
ID: 224522

PeterT · Yesterday, 02:14 PM

Quote:

Originally Posted by rantanplan

The tool doesn't seem to list the errors chronologically. I chose a epub with lots of the same errors and you can see that seems to be listed in a random order.

Attachment 224522

Presumably the order that files are present IN the zip file directory

Kayadelenium · Yesterday, 02:53 PM

v0.5.18 is out — and a word about where this goes next, because the last two posts deserve a straight answer rather than just a changelog line.

rantanplan —the findings weren’t in order. Fixed. You were right: on a book with many of the same error they came out in what looked like a random order. The cause was that epubveri runs its checks in passes — the grammar, then the structural rules, then the hand-coded and CSS passes — and was printing findings in the order the checks produced them, not the order they appear in the book; and one of those passes iterated a hash table, which added a genuine shuffle on top. Findings are now sorted by position within each file (files themselves stay in reading order), and two runs over the same book now produce identical output. Thanks for the clear report — an easy thing to miss until someone points at a screenshot.

Doitsu — unknown and mistyped attributes. You’re right, and I want to say so plainly rather than argue: a validator that lets <p fake="fake" clas="header"> through is not doing its job. 0.5.17 added the obsolete attributes, but that’s a hand-picked list; it does nothing for a made-up name or a typo of a real one, and “reliably tell valid from invalid” is the whole point of the tool. So this isn’t a nice-to-have I’ll get to — it’s a hole in the floor.

Here’s the honest shape of it. epubveri’s grammar checks elements strictly (an unknown tag like <foobar> is already rejected), but it checks attributes permissively: it accepts any attribute name except a small denylist. That’s backwards for a validator, and it’s the root cause. The fix is to invert it — every element gets a real allowlist, and anything not on it is flagged, exactly as EPUBCheck does. The one trap I have to respect is that the grammar currently leans on that permissive default to cover element-specific attributes it never bothered to list (required on <input>, download on <a>, and many more) — so I can’t just flip a switch, or half the valid books out there would suddenly fail. It has to be built up first, element by element, and I’m using EPUBCheck’s own schema as the reference for each list, since matching EPUBCheck is the entire point. It’s tracked in the open here as #31 if you want to watch it.

And the bigger decision your feedback pushed me to, since I’d rather be transparent than quietly re-plan: I’m making “catch, then surpass, EPUBCheck” the priority, and I’m holding off on the repair side of this (the companion I mentioned last time) until epubveri is genuinely solid. You can’t write a tool that rewrites people’s books on top of a validator whose own behaviour is still shifting week to week — the ground has to stop moving first. So the next stretch is unglamorous: a careful pass through where epubveri and EPUBCheck disagree, starting with attributes, closing the gaps one verified step at a time. Less to announce, but it’s the part that makes the thing trustworthy.

All of you have been more useful than any test suite I’d have written alone — the tool keeps learning things from real books that it couldn’t from my own fixtures. Please keep breaking it.

Binaries: v0.5.18 release page.

rantanplan · Yesterday, 03:07 PM

Thank you for being so open about the current state and fixing the sort order. Great work.

And don’t stress yourself out too much, no one is expecting perfection within such a short time. Keep up the good work!

Yesterday, 05:23 AM	#108
JSWolf Resident Curmudgeon Posts: 84,214 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	@Kayadelenium I think we have to stop going with what's valid CSS and go with what's valid CSS for ePub2 and ePub3. Because what may be allowed for a website may not be allowed in an eBook and even if it's allowed, it may not work. As for fonts, I see your point about unused @font-face declarations since you would have to do a full scan of the entire CSS to check if it's used or not.. But we really do need to flag any font-family that specifically specifies a font name that has no @font-face to go with it such as font-family: "Times New Roman" when that isn't an embedded font. On some programs, that could prevent selecting a font. So I would flag the font-family when there's no embedded font to go with it. Last edited by JSWolf; Yesterday at 05:25 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
EPUBCheck v4.2.6	jhowell	ePub	0	06-30-2021 03:49 PM
EPUBCheck v4.2.5	jhowell	ePub	0	03-23-2021 09:45 AM
EPUBCheck v4.2.4	jhowell	ePub	3	06-24-2020 09:51 AM
EPUBCheck v4.1.1	Doitsu	ePub	2	03-18-2019 10:39 AM
Web-based epubcheck upgraded to epubcheck 1.0.5	kjk	ePub	4	02-09-2010 09:53 PM

Yesterday, 03:38 AM	#106
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Doitsu — thank you, that's exactly the evidence I asked for, and it settles it: no divergence. EPUBCheck flags big and center as RSC-005 errors, so it rejects obsolete elements just like epubveri does. We quietly agree, and there's nothing to file upstream. The one thing worth noting is why your output shows two errors and epubveri shows four. EPUBCheck reports big (in the first <p>) and center (directly in <body>) — but not the font and strike, because both sit inside the <center> it already rejected, and the RELAX NG validator doesn't descend into an element it has thrown out. So its schema does exclude all five (big, center, font, strike, tt) exactly as I read it — the two that surface are just the ones not masked by a rejected parent. epubveri validates the children on their own merits too, so it names font and strike in the same pass. Same verdict, same IDs, same severity — one extra pass of detail, so you fix everything at once instead of re-running after unwrapping the center. (And s / u stay unflagged in both, since they're still conforming.) Appreciate you building the test book — settling this on evidence rather than my guess is worth a lot.

Yesterday, 06:55 AM	#109
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.17 is out — again straight from this page. Doitsu — the obsolete attributes (#107). Fixed: link, vlink, clear, name, width and size are now flagged (RSC-005) on the legacy hosts where they don’t belong. Two things your paired test made me get right that I’d have missed with a single book: First, the count. EPUBCheck reports one message per offending attribute, so I do too — every occurrence at its own attribute, not one summary per element. Your EPUB 2 book comes back with 8 and your EPUB 3 book with 7, matching your CSVs line for line. Second — and this is the reason a paired EPUB 2 / EPUB 3 test was worth so much more than either alone — those two numbers differ, and only on name. EPUBCheck flags name on <a> in EPUB 2 but not in EPUB 3. My first cut flagged it in both, which would have over-reported against EPUBCheck on every EPUB 3. So I went and checked EPUBCheck’s own schemas: its EPUB 2 content model is XHTML 1.1, whose <a> genuinely has no name attribute (1.1 dropped it in favour of id), while its EPUB 3 XHTML5 schema still permits name on <a>. So a@name is now an EPUB 2-only rule. Worth being straight here: WHATWG does consider name on <a> obsolete, so by the letter of the living spec EPUBCheck is lenient in EPUB 3 — but since the whole point is to match EPUBCheck’s verdicts, I follow EPUBCheck rather than invent a stricter one. (Same principle as the strike discussion above, just pointing the other way.) One design note in case it’s useful: width/size/name are only obsolete on these hosts. width is still valid on <img>, size on <input>, name on <input>/<form>/<meta> — so I can’t just ban the names outright, or I’d fire on the near-universal <meta name>. They’re pinned per host; link/vlink/clear have no valid host anywhere and are flagged on any element. JSWolf — a font-family with no @font-face. I’ve thought hard about this one and I’m going to be honest rather than half-ship it: I’ve decided not to do it, for the same reason EPUBCheck doesn’t. The problem is that CSS gives no way to tell two cases apart. font-family: "Times New Roman" names a system font that must not have an @font-face — it’s on the device already. font-family: "MyEmbeddedSerif" names an embedded font that must have one. Both look identical to a validator: a family name with no matching @font-face. So a check that flags “named font, no @font-face” would fire on essentially every book that uses Georgia, Arial, or any of the dozen web-safe faces — which is almost all of them. The only way to narrow it is a hand-kept “these are system fonts” allowlist, and that list is device-dependent and never complete: what’s a system font on a Kobo isn’t one on a Kindle. I’d be trading a real problem I can’t see for a steady stream of false alarms on books that are fine. My rule for this whole project is that I’d rather report nothing than report wrongly, so this stays out — but the door’s open if anyone finds a heuristic that doesn’t misfire. On the broader point behind it — “validate against what’s valid for EPUB, not just the web” — I agree in principle, and that’s exactly what the EPUB 2 vs EPUB 3 split above is: the content model already tracks each version’s own vocabulary, not one generic HTML. Where I’ll push back is only when “invalid for EPUB” can’t actually be determined from the file, which is the @font-face case. A word on where this is heading, since this page has shaped so much of it. My aim is to get epubveri to a genuinely stable release — not “feature complete”, but solid and predictable — and then shift most of my weight to the repair side: a companion tool that doesn’t just find these problems but fixes them. I’ll be honest that this is where the real difficulty and the real time sink is. Telling you an <a name> is wrong is one thing; safely rewriting it without breaking the book around it, across the thousands of shapes real books come in, is a much harder problem, and that’s the part I expect to spend the most time on. Once that’s carrying its weight, I want to take the producer/ conversion side and see how close I can get a single book to genuinely correct, end to end — validate, repair, rebuild, repeat. And beyond the EPUB tooling itself, I’ve got two or three other ideas in my head — things that wouldn’t just help people who make ebooks, but that could be useful to just about anyone. I’m turning those over on the side, and I think it’s right to spend some of this energy there too rather than pour all of it into one funnel. I’ll say more when they’re real enough to show rather than just describe. Binaries: v0.5.17 release page. Thanks again — this test pair was the kind that teaches the tool something it couldn’t have learned from a single book.

Yesterday, 01:44 PM	#111
rantanplan Weirdo Posts: 1,159 Karma: 13000010 Join Date: Nov 2019 Location: Wuppertal, Germany Device: Kobo Sage, Kobo Libra 2, reMarkable PaperPro	The tool doesn't seem to list the errors chronologically. I chose a epub with lots of the same errors and you can see that seems to be listed in a random order.

Yesterday, 02:53 PM	#113
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.18 is out — and a word about where this goes next, because the last two posts deserve a straight answer rather than just a changelog line. rantanplan —the findings weren’t in order. Fixed. You were right: on a book with many of the same error they came out in what looked like a random order. The cause was that epubveri runs its checks in passes — the grammar, then the structural rules, then the hand-coded and CSS passes — and was printing findings in the order the checks produced them, not the order they appear in the book; and one of those passes iterated a hash table, which added a genuine shuffle on top. Findings are now sorted by position within each file (files themselves stay in reading order), and two runs over the same book now produce identical output. Thanks for the clear report — an easy thing to miss until someone points at a screenshot. Doitsu — unknown and mistyped attributes. You’re right, and I want to say so plainly rather than argue: a validator that lets <p fake="fake" clas="header"> through is not doing its job. 0.5.17 added the obsolete attributes, but that’s a hand-picked list; it does nothing for a made-up name or a typo of a real one, and “reliably tell valid from invalid” is the whole point of the tool. So this isn’t a nice-to-have I’ll get to — it’s a hole in the floor. Here’s the honest shape of it. epubveri’s grammar checks elements strictly (an unknown tag like <foobar> is already rejected), but it checks attributes permissively: it accepts any attribute name except a small denylist. That’s backwards for a validator, and it’s the root cause. The fix is to invert it — every element gets a real allowlist, and anything not on it is flagged, exactly as EPUBCheck does. The one trap I have to respect is that the grammar currently leans on that permissive default to cover element-specific attributes it never bothered to list (required on <input>, download on <a>, and many more) — so I can’t just flip a switch, or half the valid books out there would suddenly fail. It has to be built up first, element by element, and I’m using EPUBCheck’s own schema as the reference for each list, since matching EPUBCheck is the entire point. It’s tracked in the open here as #31 if you want to watch it. And the bigger decision your feedback pushed me to, since I’d rather be transparent than quietly re-plan: I’m making “catch, then surpass, EPUBCheck” the priority, and I’m holding off on the repair side of this (the companion I mentioned last time) until epubveri is genuinely solid. You can’t write a tool that rewrites people’s books on top of a validator whose own behaviour is still shifting week to week — the ground has to stop moving first. So the next stretch is unglamorous: a careful pass through where epubveri and EPUBCheck disagree, starting with attributes, closing the gaps one verified step at a time. Less to announce, but it’s the part that makes the thing trustworthy. All of you have been more useful than any test suite I’d have written alone — the tool keeps learning things from real books that it couldn’t from my own fixtures. Please keep breaking it. Binaries: v0.5.18 release page.

Yesterday, 03:07 PM	#114
rantanplan Weirdo Posts: 1,159 Karma: 13000010 Join Date: Nov 2019 Location: Wuppertal, Germany Device: Kobo Sage, Kobo Libra 2, reMarkable PaperPro	Thank you for being so open about the current state and fixing the sort order. Great work. And don’t stress yourself out too much, no one is expecting perfection within such a short time. Keep up the good work!