epubveri – standalone EPUB validator

[JSWolf]

BAEN uses calibre to make their eBooks and the covers are SVG cover with xlink: in them.

Will epubcheck display usage messages for ePub2 to remove klink:?

[DNSB]

Originally Posted by JSWolf

BAEN uses calibre to make their eBooks and the covers are SVG cover with xlink: in them.

Will epubcheck display usage messages for ePub2 to remove klink:?

The outdated messages only apply to ePub3. See E. Obsolete features.

Jon, please try taking a more experimentalist approach to answering some of your own questions. It's is easy enough to open a ePub2 file and see what usage errors are given by epubcheck and epubveri.

[Karellen]

Originally Posted by Kayadelenium

2. What breaks first? Navigation with no NCX, the cover, the SVG wrapper, HTML5 sectioning elements, CSS — which of these actually ruins a book on those devices, and which merely looks worse? I would rather cover two things that matter than eight that sound plausible.

On my Libra2, if there is no ncx file in an epub3, there is no table of contents.

[JSWolf]

Originally Posted by Karellen

On my Libra2, if there is no ncx file in an epub3, there is no table of contents.

Using KePub or RMSDK (ePub)?

[Karellen]

epub3

[Kayadelenium]

epubveri 0.16.0 — ARIA attribute values

This finishes what Doitsu started at #279. That post was about role accepting any token it was handed; the fix took the role vocabulary and left the layer underneath it alone, which was the aria-* attributes themselves. Every one of them accepted any string, so aria-hidden="ZZZ", aria-level="abc" and aria-live="ZZZ" passed epubveri and failed EPUBCheck. They no longer do.

What this can do to your books

33 of the 49 ARIA states and properties now carry the value space their schema gives them: 24 enumerations, 6 positive integers, 3 floating-point numbers, and the three counts (aria-colcount, aria-rowcount, aria-setsize) that accept a non-negative integer or the literal -1. The 16 that are genuinely free text or an idref — aria-label, aria-labelledby, aria-describedby and their relatives — are untouched, deliberately.

These are errors, so a book with a bad ARIA value that epubveri called valid yesterday is invalid today. It was already invalid in EPUBCheck, so this closes a gap rather than opening a disagreement — but it is the one change here that can move a verdict, so it belongs at the top.

In practice the exposure is close to nothing, and that is measured rather than hoped. Across the 474 books I test against, exactly three aria-* attributes occur at all: aria-label in 50 books, aria-labelledby in 6, aria-controls in 1. All three are free text and none of them is constrained by this change. Not one book on the shelf moved.

The same number is the limit of that evidence: with no book here using a constrained attribute, no book here could have caught a wrong row either. Each of the 33 was measured against EPUBCheck 5.4.0 one value at a time.

A datatype fix underneath it, and why this is 0.16.0

Three of those rows are floating-point numbers, and epubveri's RELAX NG datatype table had been mapping float onto decimal. A decimal has no exponent and no INF or NaN, so aria-valuenow="1e3" and five other shapes EPUBCheck accepts would have been reported as errors. float is now a type of its own. No schema had asked for it before this release, so no published build ever validated anything as the wrong type — but it had to be fixed before the ARIA rows above could land.

That fix is a breaking change for anyone using the crate rather than the command line, and it is why this is 0.16.0 rather than 0.15.3: rng::datatype:atatype gained a variant, so an exhaustive match on it no longer compiles, and Datatype::from now answers Float for "float" and "double". Nothing in the command line, the WASM package or the JSON report changes shape.

If you use the Sigil or calibre plugins

They fetch the new version themselves, so no plugin update is needed. Across a 60-book sample what all three plugins read — verdict, the counts at every severity, and the set of message IDs with their severities — is identical to 0.15.2.

What did not change

EPUBCheck's own test suite: the same message ID on 685 of 687 expected errors, and no false positive on its 368 valid books. The 209 W3C conformance publications: agreement with 5.4.0 on the exact message-ID set in 209 of 209. Still deliberately not implemented, as with role: the per-element layer that decides which element may carry a given aria-* attribute. EPUBCheck answers "element p missing required attribute role" there, which is a different question from the value, and guessing at it would invent errors on real accessibility markup.

Downloads and the full list of changes: https://github.com/veripublica/epubv...es/tag/v0.16.0

The questions I asked at #313 are still open, and they are the ones I would most like answers to — this release is the small kind of work, and that thread is the one that decides the next large kind.

[JSWolf]

Originally Posted by Karellen

epub3

That doesn't say which renderer, you used. ePub3 is just the type of ePub.

[Karellen]

I don't use kepub. If I did, I would say so.

[Karellen]

@Kayadelenium

Thanks for your efforts. I've only just started following this.

I have it installed and was a bit confused by all the "Usage" messages, but a quick read back explained what was going on there.

I haven't read back far enough to understand the "why" or how this differs from epubcheck.

I also use this checker in addition to epubcheck... https://jigsaw.w3.org/css-validator/#validate_by_input
It picks up errors that, for some reason, epubcheck won't.
I had hoped that this new validator would pick up those same errors, but it does not.
Is it a feature still to be implemented, or no plans to? Which might mean I need to use 3 checkers?

Here is a sample of the errors picked up by the above online checker.

99 	h2 	Value Error : text-decoration normal is not a text-decoration value : normal
198 	th 	Value Error : font-style bold is not a font-style value : bold
246 	.box 	Value Error : background-color normal is not a background-color value : normal
389 	.titlepage1 	Value Error : text-decoration normal is not a text-decoration value : normal

[DNSB]

Originally Posted by Karellen

epub3

Are you using RMSDK (sending to your Libra 2 as an .epub) or TENG (sending to your Libra 2 as a .kepub.epub)? RMSDK needs an NCX since it is not that great of an ePub3 renderer and does not know how to handle a HTML navigation document. TENG is a lot more capable as an ePub3 renderer and does not need a NCX navigation document if the HTML navigation document is present.

[DNSB]

Originally Posted by Karellen

@Kayadelenium

Thanks for your efforts. I've only just started following this.

I have it installed and was a bit confused by all the "Usage" messages, but a quick read back explained what was going on there.

I haven't read back far enough to understand the "why" or how this differs from epubcheck.

I also use this checker in addition to epubcheck... https://jigsaw.w3.org/css-validator/#validate_by_input
It picks up errors that, for some reason, epubcheck won't.
I had hoped that this new validator would pick up those same errors, but it does not.
Is it a feature still to be implemented, or no plans to? Which might mean I need to use 3 checkers?

Here is a sample of the errors picked up by the above online checker.

99 	h2 	Value Error : text-decoration normal is not a text-decoration value : normal
198 	th 	Value Error : font-style bold is not a font-style value : bold
246 	.box 	Value Error : background-color normal is not a background-color value : normal
389 	.titlepage1 	Value Error : text-decoration normal is not a text-decoration value : normal

For my uses using Sigil, I either use the on-line W3C validator under Tools or Doitsu's CSSValidator - Offline W3C CSS Validator. These are not errors in the ePub stucture/syntax but rather errors in the CSS stylesheet.