Signalling needed properties for EPUB3

[roger64]

Hi

Between basic EPUB2 and EPUB3 ((I mean having about the same features for both sides) there are differences, for exemple for writing some metadata.

There is one about svg: If I insert a svg tag in an EPUB3 html file (it could be a wrapper svg for the cover, or any other svg tag inline within a html file) Epubcheck will recommend me to add

properties="svg"

to the corresponding item definition in the .opf file (the "item" being the html file).

Once you know how to do, it's obvious how to proceed. Many users don't know. Would you consider proposing an automatic fix to this when we check the EPUB3?

[eschwartz]

calibre officially doesn't support EPUB3.

[roger64]

I failed to see it:

First line of the Help of the Calibre Editor:

"Calibre a un éditeur d’e-book intégré qui peut être utilisé pour éditer des livres aux formats EPUB et AZW3 (Kindle)."

which means:

"Calibre has an integrated e-book editor which can be used to edit books in EPUB and AZW3 (Kindle) formats."

Today more and more software produce EPUB3 compliant books. Of course, this "EPUB2 only "statement cannot be hold much longer...

[eschwartz]

Perhaps the manual could be clarified. However I do assure you that it is a matter of policy that calibre is designed to handle EPUB2 specifically.

Kovid is on record for not wanting to bother with EPUB3 as it is not widely used (that is expected to change once it is widely used).

[kovidgoyal]

If I add support for epub 3, check book will naturally check epub 3 specific structures. Though I have yet to see any reason to adopt epub 3 beyond "it exists".

[Bertrand]

Originally Posted by kovidgoyal

Though I have yet to see any reason to adopt epub 3 beyond "it exists".

Well... calibre is a popular software. Supporting epub3 could be a step towards a wider adoption of the epub3 standards ? Maybe not a big step. Just a step.

And seeing that more and more tools are available for epub3 could encourage manufacturers, ebooks creators/publishers to follow ? At least, some of them... ?

[kovidgoyal]

The question no one has answered for me, is why? Why should I waste countless hours of my life adding support for epub 3 to calibre? What does epub 3 enable that epub 2 does not? Just because some committee has declared a new "standard" does not mean that standard is automatically a good thing and must be adopted by everyone.

I have yet to see a use case that I care about that is possible with epub 3 but impossible with epub 2. As such I have far more important things to spend my calibre development time on.

Furthermore, since epub 3 is not backward compatible with epub 2 generating epub 3 files will mean your books will not work properly on large numbers of existing installations. UNless you restrict yourself to things that could be done in epub 2 anyway, in which case what is the point.

[roger64]

Hi

Your reluctance is natural: beginning to implement a new standard when you invested so much time with the old one is heart-breaking. Furthermore, the two standards will coexist for the years to come. I am afraid nevertheless evolution cannot be stopped. Validating tools like Epubcheck are able to discriminate between Epub2 or 3 and check them accordingly.

I switched to EPUB3 some days ago as soon as my opensource software of choice for quite a long time allowed me to do so (with version 1.5.2. alpha). To concur with what you says, it does not bring me yet any additional capability. For this, I will have to wait version 1.6 which is still some few months away. Up to now, it's just a plain Epub2 with a new dress. This software can export odt files either to Epub2 or Epub3 formats.

http://sourceforge.net/projects/writ...r2LaTeX%201.5/

I find the transition to be smooth and the compatibillity to be good for example with my Kobo v. 2.8.1. which is quite an old version or with Prince PDF and the Calibre viewer. I did not have time however to make extensive tests on this field.

Comparing the files, I am just discovering some minor technical differences, hence my questions: the biggest ones are for writing metadata, others for .opf like the "properties" thing*, for the nav file and backward support for ncx, and that's nearly it.

I think it's a good way to join the fray. I feel I will be in a good position to implement later any new feature that could be of interest for me when they will appear, one at a time.

* when I tried to add a svg tag.

[Toxaris]

I think you misunderstand his reluctance. It is not about the hours already spent on ePUB2, but more in that there is no real added value to ePUB3 if you want them to be backwards compatible with ePUB2. Besides that, there aren't that many ways to view an ePUB3 correctly. The vast majority cannot read ePUB3 on their readers...

[roger64]

Hi

You write software too.

But the EPUB3 standard was published four years ago. Just have a look at the picture right now.

There is not one company which is not making marked progress on this field.

[kovidgoyal]

@roger64: That site is complete propaganda. Most of those percentages come from HTML renderer tests. Since all major readers (except possibly the one from Adobe) are based on WebKit engines, those percentages would be virtually identical if those same tests were carried out with the same HTML/CSS in an EPUB 2 wrapper. For instance, if you ran that silly test suite with the calibre ebook viewer you would get a pretty high percentage, despite the fact that calibre does not support epub 3, at all.

You dont seem to understand how ebook rendering works. An EPUB is just a zip file full of HTML/CSS. A ebook renderer basically unzips that zip file and feeds the HTML/CSS to a browser rendering engine, which then renders it into what you see on the screen. The contents of the opf are almost entirely meaningless to this process. No reader I know off deliberately disables features of its rendering engine based on the contents of the opf file. Therefore, any fancy epub 3 thing you like that works in your shiny epub 3 reader of choice, you can put into an epub 2 and it will still work with that reader.

The only thing in EPUB 3 that does not work in EPUB 2 is the new metadata. Of that, the only useful addition that I can see is series metadata. And I'm sorry, but implementing the entire epub 3 spec to get series metadata, which anyway nothing on the market currently supports and which already exists in epub 2 via a calibre extension, is just not worth it.

[darryl]

Originally Posted by kovidgoyal

I have yet to see a use case that I care about that is possible with epub 3 but impossible with epub 2. As such I have far more important things to spend my calibre development time on.

I totally agree. For those who want epub3 support Kovid has stated plainly how you can at least start to get him interested. That is, show him a use case that he cares about. My technical knowledge of the two standards is admittedly limited and is likely to stay that way. However, it seems to me a good start to seeking epub3 support would be to present any use cases and worry about whether Kovid cares about any of them later. The only such case I see in this thread was raised by Kovid himself, being series metadata, which clearly does not alone justify implementing an entire standard which is very lightly used right now.

So, what are your use cases for epub3?

[roger64]

Thank you for your reply and sorry to make you angry.

I did not intend to look critical and I should have added that the Calibre Editor is also my editing tool of choice and that I will keep it that way.

This question, undoubtedly, will resurface later.

[kovidgoyal]

No worries

And let me add that while I personally see no use for EPUB 3 -- calibre is open source, and I welcome contributions. So if someone else wants to work on adding support for EPUB 3 to calibre, I will be happy to review code contributions.

[theducks]

Originally Posted by kovidgoyal

The question no one has answered for me, is why? Why should I waste countless hours of my life adding support for epub 3 to calibre? What does epub 3 enable that epub 2 does not? Just because some committee has declared a new "standard" does not mean that standard is automatically a good thing and must be adopted by everyone..

Plus 1

Or just because Apple says so

<rant>
What gets me riled, is they are obsoleting (the not backwards compatible bit) and have not fixed the blatant (static) BOOK omissions .

#1 is License the standard 'EPUB' so non-compliant can NOT use that name/extension . This alone will simplify book creation. No more "I have to make a 'X' version because "X" will not center a partial HR

#2 Standard metadata does not even include everyday info like Series

#3 No Standards on Bookmarks and reading position to make cross-(EPUB)device use compatible
</rant>