Possible replacement for EPUBCHECK

[DNSB]

Originally Posted by KevinH

Hopefully with line and column information now.

Not in build 0.4.0.

Current output is:

C:\Users\<user>\Desktop>D:\builder\epubveri\target\release/epubveri monospace_test.epub
ERROR RSC-005: value of attribute "property" is invalid (must not be empty) [OEBPS/content.opf]
ERROR OPF-096: non-linear content 'OEBPS/Text/nav.xhtml' is not reachable from the reading order [OEBPS/content.opf:2:1]
— 2 error(s), 0 warning(s): INVALID

[KevinH]

The position info was supposedly added in build 0.2.0.

Perhaps something broke.

[KevinH]

Actually it is after the file path separated by colons. So OEBPS/content.opf, line 2, column 1.

Unfortunately neither of the other errors have position info.


ERROR OPF-096: non-linear content 'OEBPS/Text/nav.xhtml' is not reachable from the reading order [OEBPS/content.opf:2:1]

Is there anything interesting on that test epub's content.opf on line 2 column 1?

[JSWolf]

epubveri is reporting that

<dc:date>2025-04-24T17:00:00Z</dc:date>

is wrong when it's not wrong.

ERROR OPF-054: dc:date value '2025-04-24T17:00:00Z' is empty or doesn't conform to ISO 8601 [OEBPS/content.opf:9:5]
— 1 error(s), 0 warning(s): INVALID

[rantanplan]

dc:date is a date but you posted a datetime.

[DNSB]

Testing version 0.4.1 and now I get one error message

ERROR OPF-096: non-linear content 'OEBPS/Text/nav.xhtml' is not reachable from the reading order [OEBPS/content.opf:2:1]
— 1 error(s), 0 warning(s): INVALID

Line 2 in the content.opf file is:

<package version="3.0" unique-identifier="BookId" xmlns="http://www.idpf.org/2007/opf">

Line 22 in the content.opf file is:

<itemref idref="nav.xhtml" linear="no"/>

I've also posted this as an issue.

[j.p.s]

Your lines of content.opf didn't make it into your issue text.

[JSWolf]

Originally Posted by rantanplan

dc:date is a date but you posted a datetime.

epubcheck does not call that line an error.

[KevinH]

When filing a github issue, you can use 3 back ticks at the start of a new line to indicate the start and end of things that need to not be interpreted as xhtml, xml.

```
This line will not be hidden
```

On github those 3 back tics before before and after, act like our CODE tags here.

So if you edit your github post, you can add them to make it seeable.

[KevinH]

And if you make your nav non-linear in the spine and no links exist to it, epubcheck will complain in the exact same way. The key is here is that Sigil built nav code actually links to itself as the "nav" in its landmarks section. This link from the nav to itself is enough to prevent the epubcheck error as technically a link does point to the nav.

Frankly, this error and its epubcheck "workaround" are both for the birds, as all valid epub3 e-readers can display the nav to the user as part of its navigation features just like the older epub2 ncx could be displayed by the epub2 e-readers.

So this error could apply to other non-linear content without any links landing in it, but should never have been applied to the epub3 nav in the first place!

I argued this with the epubcheck devs to no avail. Their tests for correctness just looks for urls that land inside any xhtml file with no exceptions made for it being the nav.xhtml.

My guess is, the epubverif devs are not running the test to see if a url link lands in an xhtml part. So the self-linking trick to workaround epubcheck's stupidity concerning the nav will not work for epubverif.

Hope this explains this better.

Ps. The reason for this rule by epubcheck is because some xhtml marked non-linear in the spine can never be reached on some e-readers yet, on other e-readers they can still be reached but at the end of the spine by page turning.

The Idpf do not want this, so epubcheck created the rule that nonlinear xhtml resources must have a destination link to them. They just did not properly special case the nav.xhtml nor handle the case of javascripted access to an xhtml file either. So I never pointed out to the epubcheck devs that an internal link to itself in no way helps to solve their problem because the nav.xhtml never should have been treated like the other xhtml files. To top it off the landmarks section is rarely even visible on some e-readers.

The same internal link trick works for any xhtml file listed as non-linear and always has.

[j.p.s]

Originally Posted by JSWolf

epubcheck does not call that line an error.

Then epubveri has uncovered a bug in epubcheck.

[DNSB]

For what it may worth, I tried epubveri 0.4.2 and my test ePubs showed no error. Then I tried a fresh new created with Vellum ePub. Epubveri does not seem to like @media in CSS files.

[DNSB]

And now with 0.4.3, epubveri seems to be happy with my test ePub set with no errors being reported that epubcheck did not also report.