Answers.Body: <p>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, <a href="http://kb.datalogics.com/articles/FAQ/What-updates-fixes-changes-and-enhancements-have-been-made-to-the-Adobe-Reader-Mobile-SDK-by-Datalogics?retURL=/apex/knowledgeProduct?c=Adobe_Reader_Mobile_SDK&amp;k=&amp;lang=en_US&amp;popup=false&amp;lang=en_US" rel="nofollow">Datalogic's Release Notes</a>.  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 <a href="http://www.bluefirereader.com/white-label-apps.html" rel="nofollow">Bluefire Reader Branded Readers</a>.) 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.</p>
  
  <p>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 <em>love</em> to see it).  They do regularly improve their rendering engine as well, but their release notes tend to mention solely the user interface changes.  </p>
  
  <p>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 <a href="http://epubtest.org/results/" rel="nofollow">here</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2013-12-28T18:12:59.900Z
Answers.Text: 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!
Answers.UserDisplayName: DVK
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2013-12-28T22:27:07.880Z
Answers.Text: The best source I could give for that would be the patent system, and perhaps Bill Rosenblatt's book on DRM: http://www.amazon.com/Digital-Rights-Management-Business-Technology/dp/0764548891 - 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.
Answers.UserDisplayName: Palantar
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2013-12-28T14:51:15.930Z
Answers.LastActivityDate: 2014-02-28T17:07:10.957Z
Answers.LastEditDate: 2014-02-28T17:07:10.957Z
Answers.UserDisplayName: Palantar
Answers.Body: <p>The <a href="http://fbreader.org/FBReaderJ">FBReaderJ</a>¹ 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.</p>
  
  <p>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.</p>
  
  <p>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 <a href="https://en.wikipedia.org/wiki/Given_name">given name</a>. This in turn made publishers mangle the creators element in their publications with the&mdash;for western names&mdash;incorrect form "LastName, FirstName (MiddleName/<a href="https://en.wikipedia.org/wiki/Tussenvoegsel">tussenvoegsel</a>)" 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 <strong>at the time of updating the device</strong>, by copying the <code>file-as</code> attribute information to the non-tag part of the <code>&lt;creator&gt;</code> element⁴.</p>
  
  <p>¹ <sub>Now called FBReader for Android</sub><br>
  ² <sub> This is a problem e.g. with the SONY PRS-700.</sub><br>
  ³ <sub>For Dutch names the even worse "<a href="https://en.wikipedia.org/wiki/Tussenvoegsel">tussenvoegsel</a> LastName, FirstName" is often used</sub><br>
  ⁴ <sub>You can do this on the fly, as it does not happen that often.</sub></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2013-12-27T07:07:47.523Z
Answers.LastActivityDate: 2013-12-27T07:33:51.587Z
Answers.LastEditDate: 2013-12-27T07:33:51.587Z
Answers.UserDisplayName: Anthon
Body: <p>Some ebook readers (like Sony PRS-650) does not handle <code>epub</code> 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 <code>epub</code> books which can be used by most of the devices.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T12:34:57.327Z
Comments.Text: Because "part of the standard" is not defined as a specific standard, answer will be opinion based.
Comments.UserDisplayName: James Jenkins
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T12:56:29.227Z
Comments.Text: @Mark: I don't think so. See the update, please.
Comments.UserDisplayName: palacsint
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T13:01:27.513Z
Comments.Text: @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.
Comments.UserDisplayName: palacsint
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T13:47:49.830Z
Comments.Text: 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?
Comments.UserDisplayName: James Jenkins
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T16:32:48.160Z
Comments.Text: @JamesJenkins: Not exactly. There might be other limitations, not just file size. (See the answers below.) http://idpf.org/epub/201
Comments.UserDisplayName: palacsint
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-29T20:50:34.730Z
Comments.Text: It is still a "shopping question"as there is no **one correct** answer, there will be several answers one for each buggy reader
Comments.UserDisplayName: mmmmmm
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-28T18:47:38.913Z
Comments.Text: Isn't this a shopping list question? (albeit what not to buy)
Comments.UserDisplayName: mmmmmm
Tags: <epub><ebook-readers><creation>
Title: Epub reader limitations
UserDisplayName: palacsint
ThreadText: # Epub reader limitations
  
  (Asked by: username_0 on 2013-12-27)
  
  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.
  
  **Tags:** epub, ebook-readers, creation
  
  > **Comments:**
  > **username_2**: Isn't this a shopping list question? (albeit what not to buy)  
  > **username_1**: Because "part of the standard" is not defined as a specific standard, answer will be opinion based.  
  > **username_0**: @Mark: I don't think so. See the update, please.  
  > **username_0**: @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.  
  > **username_1**: 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?  
  > **username_0**: @JamesJenkins: Not exactly. There might be other limitations, not just file size. (See the answers below.) http://idpf.org/epub/201  
  > **username_2**: It is still a "shopping question"as there is no **one correct** answer, there will be several answers one for each buggy reader  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2013-12-28. Score: 9
  
  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](http://kb.datalogics.com/articles/FAQ/What-updates-fixes-changes-and-enhancements-have-been-made-to-the-Adobe-Reader-Mobile-SDK-by-Datalogics?retURL=/apex/knowledgeProduct?c=Adobe_Reader_Mobile_SDK&k=&lang=en_US&popup=false&lang=en_US). 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](http://www.bluefirereader.com/white-label-apps.html).) 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](http://epubtest.org/results/).
  
  > **Comments:**
  > **username_4**: 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!  
  > **username_3**: The best source I could give for that would be the patent system, and perhaps Bill Rosenblatt's book on DRM: http://www.amazon.com/Digital-Rights-Management-Business-Technology/dp/0764548891 - 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.  
  
  ---
  
  ### Answer by username_5 on 2013-12-27. Score: 7
  
  The [FBReaderJ](http://fbreader.org/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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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  element⁴.
  
  ¹ Now called FBReader for Android  
  ²  This is a problem e.g. with the SONY PRS-700.  
  ³ For Dutch names the even worse "[tussenvoegsel](https://en.wikipedia.org/wiki/Tussenvoegsel) LastName, FirstName" is often used  
  ⁴ You can do this on the fly, as it does not happen that often.
  
  
  ---
  
  