Possible replacement for EPUBCHECK - Page 7

JSWolf · Yesterday, 05:43 AM

delete post

JSWolf · Yesterday, 05:51 AM

I'm trying 0.5.11. Would you mind removing -i? I don't see a need for it. Thanks.

Another fix, when the CSS references named fonts but there is no @font-face for it, please flag it as either an error or a warning.

Also, please check the CSS for errors. The CSS has an error of font-eight that should be flagged as an error. There is also a class for h4a which is also an error as there is no h4a.

font-size: x-small;; was missed as an error.

DiapDealer · Yesterday, 07:31 AM

Quote:

Originally Posted by JSWolf

I'm trying 0.5.11. What with -i? It should not be needed. Please remove -i. Thanks.

Don't use it. Please stop conflating personal preferences with real issues.

j.p.s · Yesterday, 10:47 AM

Quote:

Originally Posted by JSWolf

Would you mind removing -i? I don't see a need for it. Thanks.

Yeah, well you originally didn't see a need for epubveri.

Doitsu · Yesterday, 01:41 PM

@Kayadelenium:

Here's one final test case. It's mostly cosmetic issues:

epubveri output:

Spoiler:

EPUbCheck output:

Spoiler:

EPUBCheck didn't check the validity of the <dc:date> value, which, IMHO, is a bug. It also didn't make sure that the <html> tag language attributes were identical.

epubveri might never become an EPUBCheck drop-in replacement, but from what I've seen so far it's often more compliant with the EPUB spec than EPUBCheck is.

Doitsu · Yesterday, 04:33 PM

@KevinH

Out of curiosity, I tested an epub3 book with some elements that were at one point deprecated in XHTML.

Spoiler:

epubveri flagged: big, center, font and strike.

However, EPUBCheck only flagged big and center.

EPUBCheck output:

Spoiler:

Would you agree that this is an actual EPUBCheck bug?

Kayadelenium · Yesterday, 06:38 PM

Hi, I released two versions, but I noticed a few more bugs; I'm working on fixing them.

Your latest test and the other tests are passing successfully. I also fixed more issues than just those related to `big`, `center`, `font`, and `strike`.

I'll let you know and write a detailed post once I've completely cleared out the bugs.

Kayadelenium · Yesterday, 08:28 PM

v0.5.14 is out, with Doitsu’s empty-metadata case and a first pass at JSWolf’s CSS ones.

Doitsu — empty dc: metadata (EPUB 2). Fixed: an empty (or whitespace-only) Dublin Core element in an EPUB 2 package — an empty dc

ublisher, dc:creator, and so on — now draws OPF-072 at usage level, which is what EPUBCheck reports. dc:title and dc:date are left to their own existing rules. EPUB 2 only, and usage-level, so it never changes a book’s valid/invalid verdict — it just tells you the element is carrying nothing.

JSWolf — font-eight, x-small;;, and .h4a. One is a real find, two aren’t, and I’d rather say which than quietly ship all three.

font-eight (a typo for font-weight) is the real one: a property name CSS doesn’t define. The catch is that EPUBCheck doesn’t validate property names at all — it never flags an unknown property — so reporting it by default would be me inventing an error the authority hasn’t decided on, which is the one thing I’ve said I won’t do. So it’s there, but opt-in: run with --advisory and you get ADV-001: 'font-eight' is not a recognized CSS property, at the exact line and column, at usage severity (it never affects the exit code). Same for an unknown at-rule descriptor — a bogus @font-face descriptor is ADV-002. Off by default the output is byte-for-byte what it was.

Two things worth spelling out about how it decides “unknown”, because the failure mode of a property linter is false positives:

The known-property list is the union of the W3C “all properties” index and MDN’s property data — MDN carries the legacy aliases and SVG properties the W3C index omits (word-wrap, text-rendering, and friends), which were the false positives when I tried the W3C list alone. Vendor-prefixed (-webkit-…) and custom (--…) names are exempt.
It’s a distinct message family (ADV-…), deliberately not a CSS-0xx. Matching EPUBCheck on verdicts means not minting a code in its namespace for something it doesn’t define.

The other two I checked and don’t think are errors:

x-small;; — the doubled semicolon is an empty declaration, and CSS Syntax says to just discard it. It’s valid; EPUBCheck doesn’t flag it, and neither do I. (If you meant something else by it, show me the whole rule and I’ll look again.)

.h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS.

The property-name check rides on a separate small library I’ve been building alongside this (styloria, a pure-Rust CSS parser); the validation is the part that’s new in it. Value- level checking — whether color: 3px is nonsense — is a much bigger job and isn’t in yet.

And there’s more to come — this is a first pass, not the finished picture. A few improvements are already lined up: the advisory checks only run from the command line for now (the in-browser/WASM build can’t opt in yet), value-level CSS checking is the natural next layer, and the deeper content-model work continues. I’d rather ship these in small, verifiable steps than announce a big list, so I’ll post them as they land — and this thread has been better than any roadmap for deciding what’s worth doing next.

Binaries: v0.5.14 release page. Keep them coming — the font-eight case is exactly the kind of thing I’d never have written a test for on my own.

Kayadelenium · Today, 04:24 AM

v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last.

Read this first if you validate your own books: this release changes verdicts. A book that nests elements illegally, or points an attribute at an id that isn’t there, now comes back invalid (RSC-005) where 0.5.14 passed it. That’s not a regression — it’s catching real errors EPUBCheck catches too — but if a book that was green suddenly isn’t, this is almost certainly why. Check the new message before assuming something broke.

What’s actually new, in three parts:

Nesting rules — the constraints a grammar structurally can’t state, because they’re about a node’s ancestors, not its immediate contents. An <a> inside another <a>; interactive content (a <button>, a <select>, an <audio controls>) inside an <a> or <button>; a <form> inside a <form>; <header>/<footer> nested in each other; a <label> in a <label>. Element placement — the <span> and loose text directly under <body> that Doitsu reported way back — was already caught by the grammar; this is the other half.

Broken references — every id an attribute points at now has to exist, and where the reference is typed, point at the right kind of element: aria-describedby / aria-labelledby / aria-controls and friends must resolve; <label for> must target something labelable; headers must name <th> cells in the same table; aria-activedescendant must be an actual descendant. This is the one I think matters most day to day — a dangling aria-describedby is a real accessibility bug and easy to introduce by editing.

A handful of smaller structural rules — duplicate <map> names, a <select> with two selected options, more than one <meta charset>, and so on.

All of it is EPUB 3, all reported as RSC-005 at the offending element with a line and column, and all verdict-matched to EPUBCheck — I check each rule fires on the mistake and stays quiet on the valid shape, and the whole EPUBCheck test corpus is unchanged. Thanks to Doitsu for the original report (thread post #54); this closes it out.

One other thing, for the CSS crowd: the opt-in --advisory check from 0.5.14 — the one that flags a misspelled CSS property like font-eight — now works in the in-browser (WASM) build too, not just the command line. Still opt-in, still never changes a book’s verdict.

Binaries: v0.5.15 release page. As always, the fastest way to find the next bug is to point this at a book EPUBCheck disagrees with and tell me — that’s been worth more than any test I’d have written on my own.

Doitsu · Today, 05:22 AM

Quote:

Originally Posted by Kayadelenium

v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last.

Thanks for adding this feature. You can test it with this MR epub.

It contains one paragraph with a misplaced </p> tag.

<p>»Auf Wiedersehen, <i>Jarl</i>!«</p>, antwortete der junge Mann schaudernd, denn das war das erste Mal, dass er den heiligen Namen Gottes von den Lippen des Kapitäns hörte.

epubveri reports this issue twice. Once with a reference to the actual line and once with a reference to the <body> tag.

ERROR RSC-005: text is not allowed directly in "body"; EPUB 2 requires block-level content
ERROR RSC-005: character data is not allowed in element "body"

IMHO, character data is not allowed in element "body" maybe technically correct, but might not be understood by the average ebook creator.

How about:

Bare/unwrapped/stray text found in element "body"

or:

Text found outside any tag.

JSWolf · Today, 05:47 AM

Quote:

Originally Posted by Kayadelenium

.h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS.

It's not .h4a. It's just h4a (no period). There is no h4a.

Thank you for diving into the CSS. It's no good when epubcheck says an ePub is good to go and it's not because the CSS has mistakes.

JSWolf · Today, 05:50 AM

Quote:

Originally Posted by Doitsu

How about:

Bare/unwrapped/stray text found in element "body"

or:

Text found outside any tag.

How about:

Bare/unwrapped/stray text in element "body" is outside any tag.

KevinH · Today, 11:56 AM

Quote:

Originally Posted by Doitsu

@KevinH

Out of curiosity, I tested an epub3 book with some elements that were at one point deprecated in XHTML.

Spoiler:

epubveri flagged: big, center, font and strike.

However, EPUBCheck only flagged big and center.

EPUBCheck output:

Spoiler:

Would you agree that this is an actual EPUBCheck bug?

Yes, it seems like it but whatwg (the living html spec group) only removed support for big, font, and center, whereas strike afaict is still just deprecated.

The funny thing is most modern browsers do not exactly implement the whatwg standard and they purposefully keep old tags around (ie. they deprecate them but do not remove them) to maintain pretty full backwards compatibility.

If the browsers did not do that, that whole whatwg house of cards would come down since a living standard moves too fast to be truly useful for anything over 5 years old.

For example our gumbo implementation of the whatwg spec includes all of them.
And luckily chrome / QtWebEngine has kept support for most of them. Because without that backwards compatibility, Sigil would soon have to drop support for most epub2 epubs and many early epub3 epubs since Preview would fail.

Browser devs luckily seem to understand backwards compatibility is very useful. Without isit most epub ereaders that support epub2 would be toast as the same webengine/webkit is used to display both epub2 and epub3.

Yesterday, 05:43 AM	#91
JSWolf Resident Curmudgeon Posts: 84,195 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	delete post Last edited by JSWolf; Yesterday at 06:02 AM.

Yesterday, 05:51 AM	#92
JSWolf Resident Curmudgeon Posts: 84,195 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I'm trying 0.5.11. Would you mind removing -i? I don't see a need for it. Thanks. Another fix, when the CSS references named fonts but there is no @font-face for it, please flag it as either an error or a warning. Also, please check the CSS for errors. The CSS has an error of font-eight that should be flagged as an error. There is also a class for h4a which is also an error as there is no h4a. font-size: x-small;; was missed as an error. Last edited by JSWolf; Yesterday at 08:16 AM.

Yesterday, 08:28 PM	#98
Kayadelenium Member Posts: 24 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.14 is out, with Doitsu’s empty-metadata case and a first pass at JSWolf’s CSS ones. Doitsu — empty dc: metadata (EPUB 2). Fixed: an empty (or whitespace-only) Dublin Core element in an EPUB 2 package — an empty dcublisher, dc:creator, and so on — now draws OPF-072 at usage level, which is what EPUBCheck reports. dc:title and dc:date are left to their own existing rules. EPUB 2 only, and usage-level, so it never changes a book’s valid/invalid verdict — it just tells you the element is carrying nothing. JSWolf — font-eight, x-small;;, and .h4a. One is a real find, two aren’t, and I’d rather say which than quietly ship all three. font-eight (a typo for font-weight) is the real one: a property name CSS doesn’t define. The catch is that EPUBCheck doesn’t validate property names at all — it never flags an unknown property — so reporting it by default would be me inventing an error the authority hasn’t decided on, which is the one thing I’ve said I won’t do. So it’s there, but opt-in: run with --advisory and you get ADV-001: 'font-eight' is not a recognized CSS property, at the exact line and column, at usage severity (it never affects the exit code). Same for an unknown at-rule descriptor — a bogus @font-face descriptor is ADV-002. Off by default the output is byte-for-byte what it was. Two things worth spelling out about how it decides “unknown”, because the failure mode of a property linter is false positives: The known-property list is the union of the W3C “all properties” index and MDN’s property data — MDN carries the legacy aliases and SVG properties the W3C index omits (word-wrap, text-rendering, and friends), which were the false positives when I tried the W3C list alone. Vendor-prefixed (-webkit-…) and custom (--…) names are exempt. It’s a distinct message family (ADV-…), deliberately not a CSS-0xx. Matching EPUBCheck on verdicts means not minting a code in its namespace for something it doesn’t define. The other two I checked and don’t think are errors: x-small;; — the doubled semicolon is an empty declaration, and CSS Syntax says to just discard it. It’s valid; EPUBCheck doesn’t flag it, and neither do I. (If you meant something else by it, show me the whole rule and I’ll look again.) .h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS. The property-name check rides on a separate small library I’ve been building alongside this (styloria, a pure-Rust CSS parser); the validation is the part that’s new in it. Value- level checking — whether color: 3px is nonsense — is a much bigger job and isn’t in yet. And there’s more to come — this is a first pass, not the finished picture. A few improvements are already lined up: the advisory checks only run from the command line for now (the in-browser/WASM build can’t opt in yet), value-level CSS checking is the natural next layer, and the deeper content-model work continues. I’d rather ship these in small, verifiable steps than announce a big list, so I’ll post them as they land — and this thread has been better than any roadmap for deciding what’s worth doing next. Binaries: v0.5.14 release page. Keep them coming — the font-eight case is exactly the kind of thing I’d never have written a test for on my own.

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, 06:38 PM	#97
Kayadelenium Member Posts: 24 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Hi, I released two versions, but I noticed a few more bugs; I'm working on fixing them. Your latest test and the other tests are passing successfully. I also fixed more issues than just those related to `big`, `center`, `font`, and `strike`. I'll let you know and write a detailed post once I've completely cleared out the bugs.

Today, 04:24 AM	#99
Kayadelenium Member Posts: 24 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last. Read this first if you validate your own books: this release changes verdicts. A book that nests elements illegally, or points an attribute at an id that isn’t there, now comes back invalid (RSC-005) where 0.5.14 passed it. That’s not a regression — it’s catching real errors EPUBCheck catches too — but if a book that was green suddenly isn’t, this is almost certainly why. Check the new message before assuming something broke. What’s actually new, in three parts: Nesting rules — the constraints a grammar structurally can’t state, because they’re about a node’s ancestors, not its immediate contents. An <a> inside another <a>; interactive content (a <button>, a <select>, an <audio controls>) inside an <a> or <button>; a <form> inside a <form>; <header>/<footer> nested in each other; a <label> in a <label>. Element placement — the <span> and loose text directly under <body> that Doitsu reported way back — was already caught by the grammar; this is the other half. Broken references — every id an attribute points at now has to exist, and where the reference is typed, point at the right kind of element: aria-describedby / aria-labelledby / aria-controls and friends must resolve; <label for> must target something labelable; headers must name <th> cells in the same table; aria-activedescendant must be an actual descendant. This is the one I think matters most day to day — a dangling aria-describedby is a real accessibility bug and easy to introduce by editing. A handful of smaller structural rules — duplicate <map> names, a <select> with two selected options, more than one <meta charset>, and so on. All of it is EPUB 3, all reported as RSC-005 at the offending element with a line and column, and all verdict-matched to EPUBCheck — I check each rule fires on the mistake and stays quiet on the valid shape, and the whole EPUBCheck test corpus is unchanged. Thanks to Doitsu for the original report (thread post #54); this closes it out. One other thing, for the CSS crowd: the opt-in --advisory check from 0.5.14 — the one that flags a misspelled CSS property like font-eight — now works in the in-browser (WASM) build too, not just the command line. Still opt-in, still never changes a book’s verdict. Binaries: v0.5.15 release page. As always, the fastest way to find the next bug is to point this at a book EPUBCheck disagrees with and tell me — that’s been worth more than any test I’d have written on my own.

Advert

Advert