epubcheck, any software can pass its validiation check?

[rmm200]

Epubcheck, like Calibre, is a work in progress. Again like Calibre, I think it is supported by volunteers.

Just because it has limitations is no excuse to not use it. Until something better comes along, I think anyone generating Epubs should use it as the before-mentioned sanity check. And if you don't like the way it works - volunteer some of your time to make it better.

Epubs need good tools to reach their potential - and for the moment Epubcheck is the best we have.

Robert

[kovidgoyal]

My objection to epubcheck is that it gives the impression that using it means your epub is actually guaranteed to work on anything

To put it another way

I would have no objection to epubcheck if it was was named epub-schema-check or if it printed out a big fat disclaimer about how it's checks dont guarantee anything.

Or to put it slightly less seriously

Circling a banyan tree three times while reciting the English alphabet backwards appeases the God of e-book formatting, so you should always do that immediately after you run epubcheck. Just in case. It can't hurt. Banyan trees are shady, and good for the environment.

[kovidgoyal]

@rmm200: Are you implying that the fact that a piece of software is developed by volunteers means that it is bound to be mediocre?

[rmm200]

Originally Posted by kovidgoyal

@rmm200: Are you implying that the fact that a piece of software is developed by volunteers means that it is bound to be mediocre?

I love Calibre - I think it is great. Last time I looked Calibre had a bunch of closed bugs and a fair number of open ones. Work in progress means you are not done yet... There is always another bug ahead.

Are you saying Epubcheck will never be better than mediocre?

I am not associated with Epubcheck, but I know the great value of tools like FindBugs (http://findbugs.sourceforge.net/) in the Java arena. There are definite analogies here - and I would consider myself irresponsible as a programmer if I did not use the tools available to me.

Robert

[kovidgoyal]

Originally Posted by rmm200

I love Calibre - I think it is great. Last time I looked Calibre had a bunch of closed bugs and a fair number of open ones. Work in progress means you are not done yet... There is always another bug ahead.

Are you saying Epubcheck will never be better than mediocre?

I am not associated with Epubcheck, but I know the great value of tools like FindBugs (http://findbugs.sourceforge.net/) in the Java arena. There are definite analogies here - and I would consider myself irresponsible as a programmer if I did not use the tools available to me.

Robert

Are you saying you should use a tool simply because it exists, irrespective of whether it is any good or not? I have no idea if epubcheck will one day become useful or not. All I can say is whether it is useful or not today.

In fact I would even happily stipulate it is useful today, I just want to emphasize that it does not perform the function that many people assume it does, that of guaranteeing an EPUB will work.

So an EPUB creators job doesn't really end if his EPUB is passed by epubcheck. She needs to actually look at it in a few common EPUB viewers as well.

As an illustration, 90% of the code in the calibre EPUB output plugin deals with transforming perfectly valid (as per epubcheck) structures to other perfectly valid structures. Except that the second set of structures have the advantage that they actually work as intended on common EPUB renderers.

[JSWolf]

mypictureshares.com is way too slow. Whoever is using it, please unlink from it. Thanks.

[Peter Sorotokin]

Originally Posted by kovidgoyal

Just so you know: epubcheck is totally meaningless. A file that *passes* epubcheck may or may not work with any given epub renderer. A file that *does not pass* epubcheck may or may not work with any given epub renderer.

The best that could possibly be said about epubcheck (and I wouldn't be comfortable saying this without actual data) is that a file that passes epubcheck may be more likely than a file that does not pass to render correctly with most epub viewers. Even if this were true it would most likely be so because files that tend to pass epubcheck tend, on average, to have extremely simple markup, as they are typically the product of machine translation from some extremely simple format.

What I'm trying to say is that the things that epubcheck checks are those things that it is easiest to write software to check, not those things that are most likely to cause problems, or those things that are most likely to occur in the wild.

What epubcheck is good for, is those situations where you have absolutely no idea why your epub file is not rendering with a particular renderer. In that case, you can try running epubcheck on it and fix the errors it points out. Of course, that may or may not fix your actual problem. And even for this use case, epubcheck is extremely sub-optimal since its error messages are incredibly unhelpful.

That's my epubcheck jeremiad for this week.

Even though I do not totally agree with what you say, I can certainly see your point and confirm that there is a lot of truth in it. When you hit a specific problem that epubcheck should have caught in your opinion, could you make a note of it and either post this stuff somewhere, or send me a message, or create an issue for epubcheck? This way it can be improved to be a more useful tool.

[kovidgoyal]

Sure, I'll be happy to. Most issues I come up against are typically limitations of this or that EPUB viewer software though. I'm not sure if these are the kinds of issues you want epubcheck to check. If so, I'll be happy to open bug reports for it. Perhaps epubcheck should get a --rendering mode that can be used to check issues that affect rendering on various EPUB viewers.

There's already a long list of these types of issues at http://bugs.calibre-ebook.com/wiki/ADEQuirks that affect Adobe Digital Editions. Most of these issues have probably been fixed in newer ADE releases, but the existence of legacy readers means that EPUB documents need to workaround them to be sure of rendering well on old SONY readers for example.

[pdurrant]

Originally Posted by Peter Sorotokin

Even though I do not totally agree with what you say, I can certainly see your point and confirm that there is a lot of truth in it. When you hit a specific problem that epubcheck should have caught in your opinion, could you make a note of it and either post this stuff somewhere, or send me a message, or create an issue for epubcheck? This way it can be improved to be a more useful tool.

I was pleased to find that the latest 1.0.5 epubcheck no longer reportes problems on IDPF-obfuscated fonts. It still reports problems on Adobe-obfusticated fonts, which is reasonable, I suppose, because the Adobe method is non-standard.

Of course, (nearly) all ePub readers understand Adobe obfusticated fonts, and the most important one, Adobe Digital Editions, doesn't understand IDPF obfusticated ones. Which makes the situation less than optimal.

Sigh... I just want to publish an ePub with an embedded fton in a way that satifies the font vendors, and yet doesn't encrypt the text. An obfusticated font is the way to go, but using Adobe obfustication means the file won't pass epubcheck, and so my distributor won't take it, and using IDPF obfustication passes epubcheck, but then the font won't show up for the majority of (current) users!

Hopefully ADE will support IDPF obfusticated fonts soon.

(Hmm... I seem to be trying to hijack the thread. Apologies.)

[Valloric]

Originally Posted by Peter Sorotokin

Even though I do not totally agree with what you say, I can certainly see your point and confirm that there is a lot of truth in it. When you hit a specific problem that epubcheck should have caught in your opinion, could you make a note of it and either post this stuff somewhere, or send me a message, or create an issue for epubcheck? This way it can be improved to be a more useful tool.

I personally find epubcheck to be an invaluable tool even after taking its limitations into consideration. The only thing I don't like about it is that it's written in Java, and therefore can't be easily embedded into Sigil. But that's my problem, not epubcheck's.

Keep up the good work.

Originally Posted by pdurrant

Sigh... I just want to publish an ePub with an embedded fton in a way that satifies the font vendors, and yet doesn't encrypt the text. An obfusticated font is the way to go, but using Adobe obfustication means the file won't pass epubcheck, and so my distributor won't take it, and using IDPF obfustication passes epubcheck, but then the font won't show up for the majority of (current) users!

Oh the pain. That's horrible.

[Peter Sorotokin]

Originally Posted by pdurrant

Of course, (nearly) all ePub readers understand Adobe obfusticated fonts, and the most important one, Adobe Digital Editions, doesn't understand IDPF obfusticated ones. Which makes the situation less than optimal.

The most recent Adobe SDK does implement IDPF method, so you'll see devices that support it pretty soon. But yes, it will take time to filter down.

[Peter Sorotokin]

Originally Posted by kovidgoyal

Sure, I'll be happy to. Most issues I come up against are typically limitations of this or that EPUB viewer software though. I'm not sure if these are the kinds of issues you want epubcheck to check. If so, I'll be happy to open bug reports for it. Perhaps epubcheck should get a --rendering mode that can be used to check issues that affect rendering on various EPUB viewers.

Frankly speaking, I wanted to add such a mode for a long time, but I was concerned that it would be seen as some sort of evil Adobe plot. Perhaps I'll give it another thought.

[pdurrant]

Originally Posted by Peter Sorotokin

The most recent Adobe SDK does implement IDPF method, so you'll see devices that support it pretty soon. But yes, it will take time to filter down.

Excellent news. Thanks.

[kovidgoyal]

Originally Posted by Peter Sorotokin

Frankly speaking, I wanted to add such a mode for a long time, but I was concerned that it would be seen as some sort of evil Adobe plot. Perhaps I'll give it another thought.

Well it should not only warn about problems with ADE. For example, empty <pre> elements are not rendered correctly in webkit based viewers and stanza can't handle an epub that has files with the same filename in different directories.

Of course, Stanza has so many problems that it's probably not worth supporting at all.

[JSWolf]

Originally Posted by Peter Sorotokin

The most recent Adobe SDK does implement IDPF method, so you'll see devices that support it pretty soon. But yes, it will take time to filter down.

But unless Sony implements the most recent SDK for the 300, 500, 505, 600, & 700, then the publishers cannot use the new fixes/changes as the books will then break on a Sony Reader. I'm not sure how up-to-date the 900 is. But Sony needs to keep the ADE engine updated. Why that have not it silly. Do you know if Sony is planning on implementing the latest ADE on the Readers or is Sony making the world have to work with the old version despite changes/fixes?

I do think Adobe should make it part of the contract that if they use ADE, that it has to be updated so we are not stuck with old ADE when new ADE has bug fixes and other enhancements. Sure, the new ADE supports IDPF font handling. But if a number of Readers do not, then what good is it?