Is there any epub element can define if epub has only image

6 posts / 0 new
Last post


Wondering is there any way (some potential epub element in opf?) to detect if epub only has image(or only image displayed) without layout the html?

Use case:
Many Japanese comic only use image. So for this type of book, can use some different approach (comparing with fixed layout book with canvas or reflow book) to display it for some reason.
But sometime creator also add some text with display:none to add kind of information inside book, so we can not force creator just use image in opf instead of using html.


Why don't you just look at the media type of the item referenced from the spine? If someone is putting images straight into the spine, the item will indicate an image media type.

If you want a general indication if a particular rendition is image-based, you could look at the rendition:accessMode selection attribute,[1] but it's not a reliable indicator that there are images in the spine; it's more for image-based fixed-layout documents. It's also not required to be used if there isn't more than one rendition, and the specification only just became a recommendation.


EPUB 3 can only have XHTML or SVG as content elements.
If there is only the navigation document as XHTML, content elements should be SVG.
This can be an indication, but if it is a mix, one can only guess by the number of content documents in one format.
I published comics with almost all content files as SVG and another type with SVG fragments inside XHTML - both is possible with slightly different advantages.
Raster images always require an additional text alternative and are no content documents themselves.

EPUB 3 can only have XHTML or SVG as content elements.

Not true. The requirement is that there be a fallback to an xhtml or svg content document if the format referenced from the spine is not one of those.

It's not an isolated case here, as there are a number of vendors not wanting to invoke an xhtml rendering engine just to show an image, and they argued in the last revision to drop the fallback requirement.

Some vendors want to provide an accessible version separately from the completely image-based one, for example, but to open epub up in this way would lead to content outside vendor-controlled environments with no accessible qualities, so the xhtml/svg fallback requirement remains.

No one has proposed metadata explicitly to identify image-in-spine-only renditions, since it remains a non-standard way of creating an epub.

EPUB3 can have XHTML or SVG or other images (png) in spine element (opf).
If only refer images in spine element, we can identify it as recommended above.
This case is some creator uses XHTML, and only image (png or svg) in xhtml.

You need some heuristics to analyse the XHTML, whether it contains not much more than img/object etc elements or elements containing text as well. Maybe for you preferred programming language there is a library for XSLT and DOM to simplify the task?

But my SVG-fragment-in-XHTML-comics combine both, the text in XHTML to ensure, that the font size aligns with the preferences of the audience and the SVG for automatic scaling to the available display size, additionally with a text alternative within the SVG. Will be difficult to detect such accessible and technically more advanced comics automatically.

Secondary menu