View Single Post
Old 09-18-2012, 04:54 PM   #3
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 9,530
Karma: 43837842
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Code:
<p class="heading-2" id="toc-anchor-1"><a id="start" name="start"></a>Chapter 1</p>
That type of code results in rendering/navigation issues (visible html tags/attributes, etc...) in the older MOBI format. I have no idea if it's quite as critical/drastic in KF8, but it's still pointed out in the Amazon Kindle Publishing Guidelines as a no-no. As per section 3.9.2: "Anchors Must Be Added Before Formatting Tags."

The example given in the guide is with an <h2>, but I know for a fact, a styled <p> tag triggers the same sort of issues in the older MOBI format. I started thinking of it as "Anchors Must Be Added Before Formatted Tags" and I never had any more problems with it.

The bottom line is ... if your guide elements, or html ToC links, or footnote links (or links of any kind) are going to include url fragments (href="html/Test document.xhtml#start"), then that anchor your href is shooting for needs to come before any formatted (inline or CSS) tags.

So your code (ignoring the toc-anchor-1 ID for now):
Code:
<p class="heading-2" id="toc-anchor-1"><a id="start" name="start"></a>Chapter 1</p>
Should be (according to the guidelines -- and my experiences):
Code:
<a id="start"></a><p class="heading-2" id="toc-anchor-1">Chapter 1</p>
And if you're planning on linking from your ToC to the "p" tag's id, you should technically change the id to an anchor and move it before the formatted p tag as well.
Code:
<a id="toc-anchor-1"></a><p class="heading-2">Chapter 1</p>
But I'd probably just double-up and have the Chapter 1 ToC link point to the <a id="start"></a> anchor as well and be done with it.

Don't misunderstand me ... I have no idea if any of this will affect or fix the Start Point issue you and others are experiencing, but I do know it has always tripped people up on the traditional MOBI side of things. Repeatedly and often. So it probably wouldn't hurt to comply and see what happens.

This sort of thing is exactly why—with the exception of footnote links—I just don't use url fragments and anchor (or id) targets in my ebooks. Period. Every link in my ToC points to an individual xhtml file. Same for every navPoint in my NCX file, and every source/href in my OPF file. Footnotes are a different story, of course, but as long as I follow the "Anchors Must Be Added Before Formatted Tags" rule ... all's golden.

EDIT: how ironic would it be if Amazon's own Indesign plugin was producing mobi source code that didn't abide by its own publishing guidelines?

Last edited by DiapDealer; 09-18-2012 at 05:02 PM.
DiapDealer is online now   Reply With Quote