What happens when an EPUB2 reader encounters an EPUB3 file?

6 posts / 0 new
Last post

At O'Reilly's TOCCON last week in New York, I asked this question in one of the EPUB-related sessions:

- what happens when an ereader that supports EPUB2(and earlier) opens an EPUB3 file?

While the speaker did not have an answer at that moment, it is a question I am trying to understand.

Assuming that you provide both a "toc.xhtml" for EPUB3 and a "toc.ncx" for backwards-compatibility, what will current ereaders do? Will they:

1. simply ignore the extra tags and features of EPUB3 and render the file as if it were EPUB2? (what I would like to happen)
2. open the EPUB3 file but wind up messing up the formatting;
3. not open the EPUB3 file and give an error about having the incorrect version;
4. crash/die/quit.

I would love the answer to be #1, but I suspect that we'll see some of all of this with the different EPUB readers out there.

Has anyone tried any experiments with taking an EPUB3 file that demonstrates some of the features of EPUB3 and opening it in various current ereaders?

Just curious,
Dan

I guess the companion question is - what happens if a current ereader attempts to open an EPUB3 file that does NOT contain a "toc.ncx" file? i.e. it is a true EPUB3 file with only a toc.xhtml. Will it still display the ebook fine but just without a proper TOC?

Yes, I did some testing with an epub(3) (no audio/video; just html5 semantic tags, semantic inflection, tables, figures; toc.ncx+toc.xhtml; valid as per epubceck 3.0b3; generated from a docbook workflow).

It appears that the file is rendered reasonably, as the html5 semantic tags are simply skipped and rendered as divs. Even ADE does a reasonable job (if reasonable is something appropriate for ADE). epub:type semantic inflection does not interfere. Best results are on firefox epub reader plugin. Quite ironically, Readium refuse to open the file reporting that it is not valid (but epubcheck 3.0b3 says everything is OK).

I have not jet done any test under Ibooks, but I don't expect problems.

I have not jet tried kindle/KFire conversion, but I *do* expect it will not work.

The real problem is validation: if you are delivering on a channel that require an epubcheck 2.x validation, you cannot use any html5 tags as they invalidate the file.

Cheers,
__peppo

I would expect 1 through 3 are all possible, with 4 somewhat unlikely.

EPUB 2 only allows a smaller subset of CSS (2.0 versus 2.1 + some CSS3 in EPUB 3), so how the content renders will depend on what properties are being used. It doesn't mean your styling will be messed up, per se, but it may lead to visual oddities. Then again, the unsupported properties may not have an appreciable effect.

And EPUB 2, as noted, does not support the new HTML5 elements, but HTML rendering typically translates into unknown elements and attributes being ignored. It's not just new elements that won't be supported, either, but scripting, SSML and other features that EPUB 3 has added.

There's no prose in the OPF2 specification about what a reading system must (or even should) do if it encounters a version number it doesn't recognize. A reading system might ignore the value and attempt to process the publication as an EPUB 2, as peppobon has noted, but it could equally well give you a message that the file can't be rendered.

EPUB 3 is a little clearer in this regard, including a Forward Compatibility section in 2.2 of the Publications specification. But again, you can't mandate that a reading system attempt to process newer version publications, and the clause only suggests that you should.

And, again, it's difficult to say what will happen in the absence of an NCX. Adobe Digital Editions is forgiving (no contents available), but another program might be more draconian. It all depends on the programming.

It was a goal, as much as possible, to ensure that v3 content could still open in a v2 reading system, but you can't rely on support.

The Changes document is a good read if you want to know what to watch out for if you want your content to render optimally in both kinds of reading systems, too.

Many thanks for the helpful feedback and suggestions. Very interesting point, peppo, about validation and distribution channels. Matt, I'll check out that Changes document, too. Thanks.

This is close to my question, which is how to best set up the file system inside the container so that an ePub2 reader will fallback into a alternate rendition specifically intended for it.

That is, I see a reference in the document level fallback retained in the spine in 3.0 ... is it possible to persuade a 2.1 reader that its wants to take the fallback? And if so, how early in the processing chain is it possible?

Eg, a graphic novel with whatever is hammered out for fixed layout in ePub3.0, with the z-coord=-1 art overlaid by panel by panel SVG text boxes fill with text, possibly with alternate language translations, possibly with optional scripted guided view, possibly with audio clips of voice acting of the GN ...
... and a fallback to some ePub2.1 approach to fixed layout with the text boxes provided by rendered graphic text boxes as transparent page-sized overlays.

Secondary menu