Epub reader limitations

Question

Some ebook readers (like Sony PRS-650) does not handle epub files which contains HTML files bigger than ~200-300kbytes. Is there any other limitations which are not part of the standard but ebook readers cannot handle or handle erroneously? I would like to avoid these pitfalls to create epub books which can be used by most of the devices.

Answer 1

The answer to that can largely be broken down into two parts for EPUB2 and EPUB3. First, for EPUB2 as it is currently the most common EPUB format: The most important thing to understand with regards to EPUB compatibility is that there are actually only a few readers available for commercial (i.e. DRM'd) EPUB content. As you might expect, Amazon and Apple made their own readers, but the vast majority of other commercially DRM'd readers are based off of Adobe's RMSDK, and as such they are mostly subject to similar limitations and quirks. Now since there are literally hundreds of known and fixed issues with RMSDK, there is no possible way that I can list them all, but I can point you at the best publically available resource I know of, Datalogic's Release Notes. These are issues that Datalogics finds and fixes itself with regards to RMSDK rendering bugs, and these issues are often then fixed by Adobe in future versions of RMSDK, so at any given time you have to be on the lookout for any of these issues with regards to whatever RMSDK renderer you are looking at (including for example any of the Bluefire Reader Branded Readers.) The last I knew, Kindle was still using RMSDK to render EPUBs, so this would apply to Kindle as well unless something has changed recently.

The second biggest place that I know of for rendering EPUBs is Apple's iBooks, and a quick google search will turn up copious numbers of frustrated authors trying to get their books rendering correctly, but unfortunately I don't have any kind of "current issues" source for them. (If anyone else does, I would love to see it). They do regularly improve their rendering engine as well, but their release notes tend to mention solely the user interface changes.

Then of course, the there is the issue of the EPUB3 Spec. This might be where I have the best news of all, which is that there is an on-going, regularly updated support grid put out by BISG that tracks which renderers support which features. That extremely helpful document can be found here.

Answer 2

The FBReaderJ¹ used to have the limitation that the HTML files could not be in subdirectories within the EPUB/ZIP file. I am not sure when or if that was solved.

Calibre has some options for EPUB output generation, that include the above deficiency and the HTML file-size limitation mentioned in the question. Other such reader limitations, if widespread, would probably make it as an option to any often used program for EPUB generation.

A far less obvious, but still annoying, limitation is that several readers² do not respect file-as information about the creator/other, thereby sorting correct (western) author names by given name. This in turn made publishers mangle the creators element in their publications with the—for western names—incorrect form "LastName, FirstName (MiddleName/tussenvoegsel)" instead of the correct "FirstName (MiddleName/tussenvoegsel) LastName"³. The correct way to handle these devices (and the only way if you have multiple devices of which some have this error), is to mangle the EPUB creator element at the time of updating the device, by copying the file-as attribute information to the non-tag part of the <creator> element⁴.

¹ _{Now called FBReader for Android}
² _{This is a problem e.g. with the SONY PRS-700.}
³ _{For Dutch names the even worse "tussenvoegsel LastName, FirstName" is often used}
⁴ _{You can do this on the fly, as it does not happen that often.}