I've run into an odd problem with e-pub files exported from In Design 5.5. It's only a problem with the Kindle, but that in itself is a pretty big problem. It has to do with the way In Design creates tables of contents. As you know, the "Table of Contents" feature in In Design is what generates the NCX or device navigation in your e-pub. For our books, we also have to create a linked table of contents within the text of the book. Below is a string of code generated by In Design that shows a typical chapter opening header that is included in the NCX and also links back to the table of contents within the text. The first id (toc_marker-10) is generated automatically by the "Table of Contents" function and is the id used by the NCX. The second id (Morella) was created by me using an anchor point and assigning a "hyperlink destination" to which an item in my in-text table of contents can link. Then this bit of text is hyperlinked (via that HREF) back to the table of contents page. As you can see, In Design places the second id near the end of the code and after the HREF which links back to my table of contents page. This works fine on all reading devices except the Kindle, which seems to become confused by the order of the elements in the code. Amazon have told me that because that second id comes after the HREF, the hyperlink does not appear on that text (Morella) and the linking breaks down. The way around this is simple: we just move the second id <a id="Morella"/> so that it comes immediately before the href and everything works. But this means going into the e-pub after the fact and tidying up every instance of the problem. Furthermore, there doesn't seem to any consistency in the order that In Design assigns to the elements in this code. In some cases where links were created in exactly the same way, the second id DOES appear before the HREF and the link works fine. Is this just a bug or does anyone know if In Design actually uses some logic to decide the order of the elements below?
<h4 id="toc_marker-10" class="chapternumber"><a href="Poe_Short_Stories-2.html#CONTENTS"><a id="Morella"/>Morella</a></h4>
It really does seem like a Kindle issue. InDesign is creating an EPUB file, not a Mobi file. It's designed to create an EPUB that will pass validation.
Creating the MOBI file from the EPUB is a separate issue and not something InDesign should concern itself with.
At this stage of eBook development (very early), it's pretty much expected that you'll need to script or manually change some of the CSS and XHTML to adjust the vagaries of different devices.
That's pretty much as I thought. We're trying to squeeze the maximum functionality out of In Design to minimize the amount of coding our designers have to do afterwards.
When I add this to our to-do list of items for cleaning up the code afterward, I see that almost all the items are to please the Kindle. It's a pretty unforgiving device.