The state of EPUB rendering: A comparison

A little discussion about the beaten-to-death topic of ebooks vs. paper books reminded me that I once wanted to do comparisons of EPUB rendering in various reader software. Now that the Fate/Zero project is complete, I have finally gotten round to doing it.

A note for readers: Here I focus entirely on rendering accuracy. The EPUB2 specification does have requirements for CSS support, and in this geek’s opinion any self-respecting EPUB reader should at least have some form of CSS support (even if not all features of it as required by the EPUB2 spec are included). Those looking for comparisons of filetype support and ability to render non-compliant EPUB files will have to turn elsewhere.

The test file used here is Fate/Zero Volume 1, downloadable here. It is validated to be error-free under epubcheck 1.2. The following CSS features are employed in this test EPUB file:

  • @font-face embedding support_ (truetype format)_
  • float <div>s (for sidenotes)
  • font-variant: small caps (for sidenotes, chapter leaders)
  • CSS selectors: :first-child pseudo-class (for unindented first paragraphs)
  • CSS3 hyphenation — experimental, using hyphens and hyphenate-resource (body text)
     See Styles/styles.css in the epub file for the full CSS stylesheet.

Image display support is not tested here, though images are included (bonus art, chapter covers). I may test this in a future post.

Font smoothing/anti-aliasing is largely software- and OS-dependent, since the font used, Vollkorn, has no font hinting encoded. Ignore any differences in font-smoothing methods used in the screenshots below. However, it does seem that EPUBReader does not do any font-smoothing whatsoever.

Only ebook reading software are tested here, as I still do not have a tablet or ebook reader device.

e-Readers without CSS support #

The following e-Readers failed CSS support unacceptably; they were unable to render almost all the features listed above. Some do not even support basic CSS styles like text-align, font-size, and so on. I suspect they may simply have broken external CSS embedding; they can’t possibly not support CSS at all.

Rendering support summary #

The following software/services were tested:

@font-face CSS float font-variant: small-caps :first-child CSS3 hyphens
Adobe DE
Bookworm
Calibre
EPUBReader
ibisreader

Caveats #

Adobe DE Missing Unicode glyph substitution Adobe Digital Editions (still) doesn’t seem to support Unicode glyph substitution. If you are using @font-face embedding and must have proper rendering in Adobe DE, ensure that the font you use has all the required glyphs. Missing glyphs will have a ? in their place instead (see screenshots below).

ibisreader custom margin-bottom ibisreader does not use margin-bottom as encoded in the css stylesheet (no extra spacing is added between paragraphs in the stylesheet). It also removes custom margin spacing in other styles; note the difference in spacing between chapters in the contents page.

Bookworm ignores header color Bookworm renders the Act/chapter titles as expected, but styles it with its own themed colours.

Adobe DE strange alignment issues Adobe Digital Editions seems to have some strange alignment issues that don’t show up in the other readers; note the right alignment of the chapter titles in the contents page.

Basic ligature support Basic ligature support is observed in EPUBReader and Calibre, although these are features of their respective rendering engines. Calibre uses freetype2, which recently gained this feature. Firefox has automatic ligature support as well.

2 thoughts on “The state of EPUB rendering: A comparison”

    1. Keep in mind that the look of text is affected by the OS’s rendering and font-smoothing features as well. XP’s Cleartype has limited use, and it is clearly showing its age (too bad that’s the only Windows OS I have at the moment. I might bug my brother to help me take screenshots in Windows 7 sometime).

      If anyone has a Mac, could you help post screenshots from Calibre, EPUBReader and Bookworm? I am quite curious to see how Vollkorn will be rendered on the Mac at different point sizes.

Comments are closed.