MobileRead Forums - View Single Post

Kayadelenium · Yesterday, 04:00 PM

Thanks for this. I rebuilt both books from your OPF and ran the two tools side by side.

The short answer first, because I'd rather say it plainly than bury it: in both cases we report the same errors as epubcheck, with the same IDs on the same lines, and the same number of them. Nothing is missed and nothing is invented. What differs is the column and the wording — and one of those was worth fixing.

The message that didn't say enough. You're right that this is close to useless:

Code:

element "meta" is missing a required attribute

epubcheck names them, and now so do we:

Code:

element "meta" is missing required attributes "content" and "name"

The commonest case isn't meta at all — it's an img with no alt. On my 405-book test library that message occurs 3,434 times, and until now not one of them mentioned alt. It also means a tool reading our JSON can act on the finding instead of parsing English. Both are in the next release.

The third epubcheck line in your EPUB 2 output. "text not allowed here" — we do implement that one. What you're seeing is deliberate: once an element has already failed on its attributes, we don't go on to report its content as well. Give the same meta valid attributes and stray text and we report it:

Code:

ERROR RSC-005: stray text is not allowed directly in "meta"; wrap it in an element

So epubcheck reports both, we report the first. Our RSC-005 count is lower than epubcheck's on purpose, so one mistake reads as one problem. If you'd rather see every consequence of a defect listed, that's a fair argument and I'd like to hear it — it's a choice, not a limitation.

The columns. We point at where a construct starts, epubcheck at where it ends. For opf:role on line 6 we say column 17, where the attribute begins; epubcheck says 32, just past it. Same for the nav one — line 12 either way, column 3 against 13. Neither is wrong, and ours is the position an editor would put a cursor at. I'm not planning to change it, but you were diffing columns, so you should know it's a decision rather than an accident.

The nav wording differs too — we say a navigation document is required, epubcheck says exactly one manifest item must declare the "nav" property. Same ID, same line, same defect, and I think both are clear enough to leave alone.

One caveat on all of the above: your manifest and spine were elided in the post, so I rebuilt them minimally. If the real file produces anything beyond the lines you quoted, send it and I'll look at the actual book rather than my reconstruction.

Yesterday, 04:00 PM	#257
Kayadelenium Zealot Posts: 101 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks for this. I rebuilt both books from your OPF and ran the two tools side by side. The short answer first, because I'd rather say it plainly than bury it: in both cases we report the same errors as epubcheck, with the same IDs on the same lines, and the same number of them. Nothing is missed and nothing is invented. What differs is the column and the wording — and one of those was worth fixing. The message that didn't say enough. You're right that this is close to useless: Code: element "meta" is missing a required attribute epubcheck names them, and now so do we: Code: element "meta" is missing required attributes "content" and "name" The commonest case isn't meta at all — it's an img with no alt. On my 405-book test library that message occurs 3,434 times, and until now not one of them mentioned alt. It also means a tool reading our JSON can act on the finding instead of parsing English. Both are in the next release. The third epubcheck line in your EPUB 2 output. "text not allowed here" — we do implement that one. What you're seeing is deliberate: once an element has already failed on its attributes, we don't go on to report its content as well. Give the same meta valid attributes and stray text and we report it: Code: ERROR RSC-005: stray text is not allowed directly in "meta"; wrap it in an element So epubcheck reports both, we report the first. Our RSC-005 count is lower than epubcheck's on purpose, so one mistake reads as one problem. If you'd rather see every consequence of a defect listed, that's a fair argument and I'd like to hear it — it's a choice, not a limitation. The columns. We point at where a construct starts, epubcheck at where it ends. For opf:role on line 6 we say column 17, where the attribute begins; epubcheck says 32, just past it. Same for the nav one — line 12 either way, column 3 against 13. Neither is wrong, and ours is the position an editor would put a cursor at. I'm not planning to change it, but you were diffing columns, so you should know it's a decision rather than an accident. The nav wording differs too — we say a navigation document is required, epubcheck says exactly one manifest item must declare the "nav" property. Same ID, same line, same defect, and I think both are clear enough to leave alone. One caveat on all of the above: your manifest and spine were elided in the post, so I rebuilt them minimally. If the real file produces anything beyond the lines you quoted, send it and I'll look at the actual book rather than my reconstruction.