Possible replacement for EPUBCHECK - Page 8

Kayadelenium · Today, 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 · Today, 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 · Today, 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 · Today, 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.

Today, 05:23 AM	#108
JSWolf Resident Curmudgeon Posts: 84,206 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; Today 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

Today, 03:38 AM	#106
Kayadelenium Enthusiast Posts: 27 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.

Today, 06:55 AM	#109
Kayadelenium Enthusiast Posts: 27 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.

Advert