epubveri – standalone EPUB validator - Page 25

DNSB · 09-26-2026, 05:24 PM

Quote:

Originally Posted by JSWolf

When checking the eBooks in calibre (not the editor), it would be good to know if any of the eBooks have HTML files that are too large. calibre's check book does not work outside the editor. The thing is, do you really want to make us have to run Quality Check before or after running epubvari? That's adding more work to check eBooks. It's best to have everything in one app to run once.

Jon, I was under the impression that epubveri was intended as a replacement for epubcheck without the need for the rather hefty Java overhead and was never intended to be a one step check everything in an ePub tool. Scope creep is a pestiferation.

I do not mind using multiple tools to check my ePubs—perhaps my age is showing there since I like small tools that do one job and do it well. Quality Check is just one of the tools I use on my Intake library and I neither expect nor want epubveri to replace all of them.

JSWolf · 09-26-2026, 08:21 PM

I found an issue with both epubckeck and epubvari. This happens with both ePub2 and ePub3.

The content in the meta name="cover" is supposed to be the id of the cover image. But it it isn't and both epubckeck and epubvari don't report this error.

Code:

<meta name="cover" content="fig_backad"/>
<item href="images/cover.jpg" id="cover_image" media-type="image/jpeg"/>

DNSB · 09-26-2026, 10:31 PM

Not even the obsolete meta element for ePub3?

Jellby · 09-27-2026, 02:38 AM

I believe the ePub2 spec says nothing about covers. The meta name="cover" tag is just an arbitrary tag that can contain whatever, it's up to reading systems to decide what to do with it. The de facto (calibre) standard may be having the file id, but nothing in the spec mandates it.

Kayadelenium · 09-27-2026, 06:14 AM

@JSWolf, @Jellby, @DNSB: Jellby is right. Neither EPUB 2 nor EPUB 3 defines <meta name="cover">; it's a convention that calibre and Kindle use. epubcheck has no rule for it, which I checked in its source, so it isn't an error, and neither tool should report it as one. DNSB, in EPUB 3 epubveri reports the element itself as outdated (OBS-001, as a usage), but that says nothing about what it points to.

Still, a cover meta that names nothing is a real defect for the readers that rely on it. So it's a candidate for an advisory, which is off by default and never changes the verdict. On my shelf, 436 of 474 books carry this meta, and every one points at an existing image. So it would only fire on books that are actually broken, like the one you found. I'll look at it before promising anything, mainly to see whether some tools write a file path there instead of an id.

JSWolf · 09-27-2026, 06:36 AM

The file path is not part of the meta name="cover". content points to the ID of the cover.

If there is a file path, then it's an error.

Here is a link from The Daisy Consortium showing this is how you define a cover for ePub2.

https://kb.daisy.org/publishing/docs/epub/cover.html

DNSB · 09-27-2026, 06:14 PM

Quote:

Originally Posted by JSWolf

The file path is not part of the meta name="cover". content points to the ID of the cover.

If there is a file path, then it's an error.

Here is a link from The Daisy Consortium showing this is how you define a cover for ePub2.

https://kb.daisy.org/publishing/docs/epub/cover.html

And that last part of that description which reads:

Quote:

In this case, the content attribute references the ID of the manifest item for the image. (Note that this practice is not officially part of the EPUB 2 specification, but is recognized by EPUB 2 reading systems.)

JSWolf · Yesterday, 05:26 AM

But without <meta name="cover"... some programs won't know the cover. So it is rather important to have this be correct.

Kayadelenium · Today, 02:08 AM

Thanks for the Daisy link, that's the useful part: it shows where the convention comes from.

I went to the specs to see what they say, EPUB 2 included, since that's where this convention lives.

- OPF 2.0.1 defines `meta` only as a free name/content pair ("arbitrary metadata beyond the data described by the Dublin Core specification"). Its schema puts no restriction on the `name` values and no link between `content` and a manifest id. The OPS and OCF documents don't mention it either. The only cover mechanism EPUB 2 actually defines is `<guide><reference type="cover" href="…">`.
- EPUB 3.4 lists the OPF 2 `meta` element among its "outdated features" (E.1): reading systems ignore it, and the spec advises checkers not to alert on its presence. The EPUB 3 way to mark a cover is the `cover-image` property on the manifest item (D.6.1).

So you're right that a `content` value naming no manifest item is a broken reference by the convention calibre, Kindle and Adobe use, and DNSB and Jellby are right that no spec, EPUB 2 or 3, defines that convention, so it can't be an error or a warning. What that leaves is an optional note. I'd word it as "the cover meta names no manifest item", and I wouldn't claim what a given reader will do with it.

Before I decide anything, I'd like some real cases from you. Is it always an id that doesn't exist (like your `fig_backad`), or have you seen a file name or a path in `content`? And roughly how many books in your library does it hit? On my own shelf of 524 books, 490 carry the meta and all 490 name an existing manifest item, so a check would fire on none of them, which tells me nothing about libraries like yours. I'm not promising it yet, but a few real examples would settle it.

DNSB · Today, 03:07 AM

I did a search on 17758 ePubs for '<meta name="cover"' in the .opf file. The search returned 17192 results.

The results were:

14,270 had '<meta name="cover" content="cover"/>'
741 had '<meta name="cover" content="cover" />'
539 had '<meta name="cover" content="cover-image"/>'
59 had '<meta name="cover" content="my-cover-image"/>'
52 had '<meta name="cover" content="cover_img" />'
48 had '<meta name="cover" content="my-cover-image" />'
43 had '<meta name="cover" content="cover_img"/>'
35 had ''<meta name="cover" content="x_cover-image" />'

For a total of 15,787 though some of those variants were from placing a space before the closing /.

The rest were a mix of filenames (cover.jpg was popular) and what looked like random IDs/ISBNs/book titles/etc. There was only 11 examples where the contents= did not match the ID in the file. As far as I could tell, those were from I had replaced a cover image and the ID was not updated.

I randomly checked the remaining block of ePubs where the '<meta name="cover"' search string was not found and they were a mix of old ePub2 files and ePub3 files.

The joys of sucking a text file into a spreadsheet and then sorting wildly.

09-26-2026, 08:21 PM	#362
JSWolf Resident Curmudgeon Posts: 85,100 Karma: 153791427 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I found an issue with both epubckeck and epubvari. This happens with both ePub2 and ePub3. The content in the meta name="cover" is supposed to be the id of the cover image. But it it isn't and both epubckeck and epubvari don't report this error. Code: <meta name="cover" content="fig_backad"/> <item href="images/cover.jpg" id="cover_image" media-type="image/jpeg"/> Last edited by JSWolf; 09-26-2026 at 08:34 PM.

09-27-2026, 06:36 AM	#366
JSWolf Resident Curmudgeon Posts: 85,100 Karma: 153791427 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	The file path is not part of the meta name="cover". content points to the ID of the cover. If there is a file path, then it's an error. Here is a link from The Daisy Consortium showing this is how you define a cover for ePub2. https://kb.daisy.org/publishing/docs/epub/cover.html Last edited by JSWolf; 09-27-2026 at 06:41 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Plugin] epubveri - Simple epubveri wrapper	Doitsu	Plugins	59	09-26-2026 06:36 AM
kepubify v4: A fast, standalone EPUB to Kobo EPUB converter	geek1011	Kobo Reader	49	12-30-2023 03:37 PM
Epub:type not allowed in epub validator	wDr	Editor	0	07-01-2016 09:03 PM
ePub Validator	odedta	ePub	9	06-01-2014 03:35 AM
epub validator	fiona86	Conversion	2	06-24-2011 11:34 AM

09-26-2026, 10:31 PM	#363
DNSB Bibliophagist Posts: 54,748 Karma: 182340541 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Not even the obsolete meta element for ePub3?

09-27-2026, 02:38 AM	#364
Jellby frumious Bandersnatch Posts: 7,600 Karma: 22000001 Join Date: Jan 2008 Location: Spaniard in Germany Device: Cybook Orizon, Kobo Aura	I believe the ePub2 spec says nothing about covers. The meta name="cover" tag is just an arbitrary tag that can contain whatever, it's up to reading systems to decide what to do with it. The de facto (calibre) standard may be having the file id, but nothing in the spec mandates it.

09-27-2026, 06:14 AM	#365
Kayadelenium Addict Posts: 209 Karma: 363834 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	@JSWolf, @Jellby, @DNSB: Jellby is right. Neither EPUB 2 nor EPUB 3 defines <meta name="cover">; it's a convention that calibre and Kindle use. epubcheck has no rule for it, which I checked in its source, so it isn't an error, and neither tool should report it as one. DNSB, in EPUB 3 epubveri reports the element itself as outdated (OBS-001, as a usage), but that says nothing about what it points to. Still, a cover meta that names nothing is a real defect for the readers that rely on it. So it's a candidate for an advisory, which is off by default and never changes the verdict. On my shelf, 436 of 474 books carry this meta, and every one points at an existing image. So it would only fire on books that are actually broken, like the one you found. I'll look at it before promising anything, mainly to see whether some tools write a file path there instead of an id.

Yesterday, 05:26 AM	#368
JSWolf Resident Curmudgeon Posts: 85,100 Karma: 153791427 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	But without <meta name="cover"... some programs won't know the cover. So it is rather important to have this be correct.

Today, 02:08 AM	#369
Kayadelenium Addict Posts: 209 Karma: 363834 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks for the Daisy link, that's the useful part: it shows where the convention comes from. I went to the specs to see what they say, EPUB 2 included, since that's where this convention lives. - OPF 2.0.1 defines `meta` only as a free name/content pair ("arbitrary metadata beyond the data described by the Dublin Core specification"). Its schema puts no restriction on the `name` values and no link between `content` and a manifest id. The OPS and OCF documents don't mention it either. The only cover mechanism EPUB 2 actually defines is `<guide><reference type="cover" href="…">`. - EPUB 3.4 lists the OPF 2 `meta` element among its "outdated features" (E.1): reading systems ignore it, and the spec advises checkers not to alert on its presence. The EPUB 3 way to mark a cover is the `cover-image` property on the manifest item (D.6.1). So you're right that a `content` value naming no manifest item is a broken reference by the convention calibre, Kindle and Adobe use, and DNSB and Jellby are right that no spec, EPUB 2 or 3, defines that convention, so it can't be an error or a warning. What that leaves is an optional note. I'd word it as "the cover meta names no manifest item", and I wouldn't claim what a given reader will do with it. Before I decide anything, I'd like some real cases from you. Is it always an id that doesn't exist (like your `fig_backad`), or have you seen a file name or a path in `content`? And roughly how many books in your library does it hit? On my own shelf of 524 books, 490 carry the meta and all 490 name an existing manifest item, so a check would fire on none of them, which tells me nothing about libraries like yours. I'm not promising it yet, but a few real examples would settle it.

Today, 03:07 AM	#370
DNSB Bibliophagist Posts: 54,748 Karma: 182340541 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	I did a search on 17758 ePubs for '<meta name="cover"' in the .opf file. The search returned 17192 results. The results were: 14,270 had '<meta name="cover" content="cover"/>' 741 had '<meta name="cover" content="cover" />' 539 had '<meta name="cover" content="cover-image"/>' 59 had '<meta name="cover" content="my-cover-image"/>' 52 had '<meta name="cover" content="cover_img" />' 48 had '<meta name="cover" content="my-cover-image" />' 43 had '<meta name="cover" content="cover_img"/>' 35 had ''<meta name="cover" content="x_cover-image" />' For a total of 15,787 though some of those variants were from placing a space before the closing /. The rest were a mix of filenames (cover.jpg was popular) and what looked like random IDs/ISBNs/book titles/etc. There was only 11 examples where the contents= did not match the ID in the file. As far as I could tell, those were from I had replaced a cover image and the ID was not updated. I randomly checked the remaining block of ePubs where the '<meta name="cover"' search string was not found and they were a mix of old ePub2 files and ePub3 files. The joys of sucking a text file into a spreadsheet and then sorting wildly.