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.

  • Isn't this a shopping list question? (albeit what not to buy)
    – mmmmmm
    Commented Dec 28, 2013 at 18:47
  • Because "part of the standard" is not defined as a specific standard, answer will be opinion based. Commented Dec 29, 2013 at 12:34
  • @Mark: I don't think so. See the update, please.
    – palacsint
    Commented Dec 29, 2013 at 12:56
  • 1
    @JamesJenkins: Although size limitation is not part of the spec, Sony PRS-650 can't handle it. I can't see why is it opinion based because I can prove that bug in Sony's firmware. There might be other devices with other limitations. I've updated the question a little bit, please check it.
    – palacsint
    Commented Dec 29, 2013 at 13:01
  • So what you are trying to ask is; 'What is the largest chunk of html that most ereaders can handle in an epub?' with your PRS-650 example being one known case. Also you have not defined 'standard' what is the standard? can you provide a link to it? Commented Dec 29, 2013 at 13:47

2 Answers 2


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.

  • Great answer! Any chance of adding a reference for "the vast majority of other commercially DRM'd readers are based off of Adobe's RMSDK" assetion? Thanks!
    – DVK
    Commented Dec 28, 2013 at 18:12
  • The best source I could give for that would be the patent system, and perhaps Bill Rosenblatt's book on DRM: amazon.com/Digital-Rights-Management-Business-Technology/dp/… - DRM in books is a very patent encumbered technology and very few companies have licensed the appropriate patents to allow them to legally do DRM. Adobe in particular holds the patents to restrictable DRM rights which have historically been important in the book industry.
    – Palantar
    Commented Dec 28, 2013 at 22:27

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.