Device specific structure in epub files

3 posts / 0 new
Last post

I wonder if someone can enlighten me about the ePub and the possibilities for making device specific code in ePub files? I am thinking about the fact that devices have various hardware specification, and wondering about the possibility to somehow first determine what sort of hardware the device have, and then make various code depending on what hardware type is present.

In this case, am specifically, but not exclusively thinking about color depth. Various devices have virtually infinity depth of colors, while some eInk readers only have grayscale, maybe even just pure black/white. So is it possible, within the same ePub file specify various content, depending IF the device is eInk or LCD/OLED?

I am also wondering about this issue in a more general way, not just color depth. I know there are some talk about ARIA specifications and Fallback functionality, but I dont know much about that.

The AHL group is working on a specification that will allow switching between different renditions of the content based on the features of the device (via media queries), as well as based on other factors such as language and device orientation.

The spec is still a work in progress and not supported yet, but you can read it here.

The HTML working group is still debating how to enable selection just for images last I checked, but it's likely a long way off still. Last I saw the discussions had moved to a combination of src-n attributes with media queries.

According to EPUB 3 you can use CSS media queries at least for some of these issues,
especially, if you worry about the capabilities for visual presentation:
http://www.w3.org/TR/css3-mediaqueries/
This can be useful to provide a different styling for different devices, but not different content.
You cannot use it currently for relevant content, for example replacing graphics or images of the content by simpler variants.

The other concepts are typically fallback mechanisms, if some formats or parts of a format
are not interpreted, but do not care about specific hardware limitations.
Typically it is assumed, that hardware and software have to be provided in such a way, that
media queries or fallback mechanisms are sufficient to make content accessible.
And it is assumed, that an author does not force a viewer to present a huge number of complex files at once, if it is possible to put them as different files in the spine.

But one cannot assume, that even the software like normal browsers are adjusted to the
hardware, for example, if the processor and graphics card are too slow to show a video,
but the software interprets the video format anyway, typically it will try to display it.
As far as I understand the HTML5 drafts, their multimedia elements have no switches for this
problem.

And for example, you cannot determine, whether the computing capabilities or the memory is
sufficient for the rendering of complex SVG files. You have to guess, for example that it may
take some time to render an IFS (iterated function system), that consists of 10 generations
of use elements, referencing each other in a cascade.
You cannot determine either, whether it will be possible for a device to display an XHTML,
PNG, JPEG/JFIF file with the size of 10 or 100 MegaByte. You just can guess, that beyond
a few MegaByte there might start some problems for a few devices ;o)

Some of these advanced issues are covered for example with switches in SMIL, but this
format is not required for EPUB, or what is used in EPUB 3, does not contain this part of
SMIL and HTML5 does not use multimedia elements from SMIL either, they preferred to
reinvent the wheel (but not with a really round shape) ;o)

What you can provide is a manual switch - for example in the first page and in the navigation
you can provide links to two or more variants - a simple one and more advanced alternatives.
But this is comparable to the problem, if you want to provide a book with language alternatives,
unfortunately there is no general switch/skip option in EPUB.
Practically one always has all versions in the navigation file and in the spine and the user has
to choose what might be useful and has to stop reading, before the not useful parts appear in the spine.
But such a simple switch by the user has the advantage, that you can use the knowledge and
capabilities of the user instead to rely on the limited options of computer formats ;o)
Even if the knowledge and capability of the user are pretty low, such a user can just try - if the
complex version results in a frozen or crashed viewer, the user still can try the simpler variant.

Secondary menu