Epub check tool: ePubs do not pass

Portnull · 08-19-2009, 06:29 AM

Hey all (once again ;-))

I'm using the java epub check tool up on Google Code to validate my epub files. Unfortunately, up till now I haven't managed to create an epub book that passes 100%. Most of the work to get around these errors has to be done by creating valid XHTML files. Which in itself is rather tough already, when you're working on educational material (consequently: lots of tables, figures, lists, footnotes, example boxes, remark boxes, notification boxes, and the like).

But even XHTML that validates, runs into errors when converting them into epub. The best I got was the tool finishing with a few 'unfinished element' messages. I think these have to do with the process of Calibre splitting the XHTML document into multiple HTML files before compressing them into epub format. Defining TOC levels instead of splitting may be a solution, but I haven't found a way yet to *not* have Calibre split my XHMTL into multiple files, and just keeping one big HTML file with multiple TOC elements.

kovidgoyal · 08-19-2009, 11:20 AM

Use the dont split on page breaks option and set maximum flow size to something very large.

You should also know that epubcheck is completely useless. The errors it complains about mostly work on all EPUB renderers and the things that it doesn't complain about cause EPUBs to break on Adobe Digital Editions.

tompe · 08-19-2009, 12:17 PM

Quote:

Originally Posted by kovidgoyal

You should also know that epubcheck is completely useless. The errors it complains about mostly work on all EPUB renderers

That should not matter. A tool should always produce standard conformant documents or if not clearly indicate that the documents do not follow the standard.

JSWolf · 08-19-2009, 12:17 PM

But how do we know that epubcheck actually works properly?

tompe · 08-19-2009, 12:23 PM

Quote:

Originally Posted by JSWolf

But how do we know that epubcheck actually works properly?

Does it matter how we get confidence in a program? I would say we know that it works properly in the same way we know how a computer program works properly. We look at the evidence.

kovidgoyal · 08-19-2009, 12:26 PM

Quote:

Originally Posted by tompe

That should not matter. A tool should always produce standard conformant documents or if not clearly indicate that the documents do not follow the standard.

Umm come up with an automated way to take arbitrarily bad HTML ad produce standards compliant XHTML from it while still preserving its meaning to human readers and I will be happy to implement it.

tompe · 08-19-2009, 12:29 PM

Quote:

Originally Posted by kovidgoyal

Umm come up with an automated way to take arbitrarily bad HTML ad produce standards compliant XHTML from it while still preserving its meaning to human readers and I will be happy to implement it.

I actually just meant that the tool should not add their own non compliances. And actually I think the tool should run a ePub checker and not produce any output called an ePub file if the XHTML is not compliant.

I think it is a big problem if the set of ePub files floating around is not standard compliant.

kovidgoyal · 08-19-2009, 01:09 PM

Quote:

Originally Posted by tompe

I actually just meant that the tool should not add their own non compliances. And actually I think the tool should run a ePub checker and not produce any output called an ePub file if the XHTML is not compliant.

I think it is a big problem if the set of ePub files floating around is not standard compliant.

I think not being able to convert existing ebooks to epub is a far bigger problem.

HarryT · 08-19-2009, 01:26 PM

So an ePub file could, for example, be completely compliant with the standard, and yet not work on, say, the Sony PRS-505 because the flow size was too large?

tompe · 08-19-2009, 01:38 PM

Quote:

Originally Posted by kovidgoyal

I think not being able to convert existing ebooks to epub is a far bigger problem.

Eh, if the result is not standard compliant then it is not an ePub file.

So what is produced is files that will work on specific readers and we will loose a lot of the advantages with having a standard.

HarryT · 08-19-2009, 01:40 PM

Quote:

Originally Posted by tompe

Eh, if the result is not standard compliant then it is not an ePub file.

So what is produced is files that will work on specific readers and we will loose a lot of the advantages with having a standard.

But being standard-compliant is no guarantee that an ePub file will work on all readers, Tommy.

tompe · 08-19-2009, 01:42 PM

Quote:

Originally Posted by HarryT

But being standard-compliant is no guarantee that an ePub file will work on all readers, Tommy.

No, and so what? Then we have a bug that a reader manufacturer will be motivated to fix.

The bigger problem is that people writing new readers have to implement all quirks and non standard behaviour in other readers since the ePub files that are available on the net or sold is not standard compliant.

kovidgoyal · 08-19-2009, 01:53 PM

Quote:

Originally Posted by tompe

No, and so what? Then we have a bug that a reader manufacturer will be motivated to fix.

The bigger problem is that people writing new readers have to implement all quirks and non standard behaviour in other readers since the ePub files that are available on the net or sold is not standard compliant.

The point is that since almost all epubs at the moment are created by converting from other sources, which are almost never XHTML compliant, it is virtually impossible to generate EPUB files that epub-check will not complain on. Furthermore, the things epubcheck complains about are of no practical use to some one trying to create an EPUB today that will work on multiple devices.

While I agree that EPUB tools should not introduce new incompatibilities as far as possible, running epubcheck on EPUBs remains pointless, for someone trying to create EPUBs taht work on actual devices.

tompe · 08-19-2009, 03:21 PM

Quote:

Originally Posted by kovidgoyal

The point is that since almost all epubs at the moment are created by converting from other sources, which are almost never XHTML compliant, it is virtually impossible to generate EPUB files that epub-check will not complain on. Furthermore, the things epubcheck complains about are of no practical use to some one trying to create an EPUB today that will work on multiple devices.

While I agree that EPUB tools should not introduce new incompatibilities as far as possible, running epubcheck on EPUBs remains pointless, for someone trying to create EPUBs taht work on actual devices.

ARe you really saying that the files are standard compliant even if EPUB checker complains?

So what will happen when a new reader that is more restrictive in what is accepted is released?

kovidgoyal · 08-19-2009, 03:25 PM

Quote:

Originally Posted by tompe

ARe you really saying that the files are standard compliant even if EPUB checker complains?

So what will happen when a new reader that is more restrictive in what is accepted is released?

No, I'm saying that those files will still work in all current readers.

And if someone were to develop a stricter EPUB reader, it would fail, miserably.

08-19-2009, 06:29 AM	#1
Portnull Member Posts: 14 Karma: 10 Join Date: May 2009 Device: Sony 505	Epub check tool: ePubs do not pass Hey all (once again ;-)) I'm using the java epub check tool up on Google Code to validate my epub files. Unfortunately, up till now I haven't managed to create an epub book that passes 100%. Most of the work to get around these errors has to be done by creating valid XHTML files. Which in itself is rather tough already, when you're working on educational material (consequently: lots of tables, figures, lists, footnotes, example boxes, remark boxes, notification boxes, and the like). But even XHTML that validates, runs into errors when converting them into epub. The best I got was the tool finishing with a few 'unfinished element' messages. I think these have to do with the process of Calibre splitting the XHTML document into multiple HTML files before compressing them into epub format. Defining TOC levels instead of splitting may be a solution, but I haven't found a way yet to not have Calibre split my XHMTL into multiple files, and just keeping one big HTML file with multiple TOC elements.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
epubcheck, any software can pass its validiation check?	droople	ePub	96	08-16-2011 01:38 PM
epub - force a 2nd pass to improve structure detection ?	cybmole	Calibre	10	10-08-2010 01:00 AM
errors after epub check	ericp20	Sigil	2	06-13-2010 10:40 AM
epub check mentiones an error	NASCARaddicted	Calibre	13	02-15-2010 09:50 AM
ePub Corrections Check - Help.	nboshart	ePub	3	10-01-2009 04:25 PM

08-19-2009, 11:20 AM	#2
kovidgoyal creator of calibre Posts: 44,963 Karma: 27109050 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Use the dont split on page breaks option and set maximum flow size to something very large. You should also know that epubcheck is completely useless. The errors it complains about mostly work on all EPUB renderers and the things that it doesn't complain about cause EPUBs to break on Adobe Digital Editions.

08-19-2009, 12:17 PM	#4
JSWolf Resident Curmudgeon Posts: 78,402 Karma: 142887248 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	But how do we know that epubcheck actually works properly?

08-19-2009, 01:26 PM	#9
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	So an ePub file could, for example, be completely compliant with the standard, and yet not work on, say, the Sony PRS-505 because the flow size was too large?

Advert

Advert