Hi Kratos
I'll be happy to help, but it does, I'm afraid, require being able to go in and edit some HTML. However what's needed isn't very complicated.
As far as I can tell from my own experiments regarding this bug, what's happening is this:
When converted to HTML, each of your chapter headings consists of something along these lines:
Code:
<h1 class="heading1style"><a name="bookmarkname">Chapter One</a></h1>
This is absolutely correct in terms of HTML syntax and validity. The H1 element is the HTML equivalent of Word's "Heading 1" style, and the "class" attribute references a CSS style which contains the formatting you applied to the "Heading 1" style in Word. The A element and its "name" attribute" are the HTML equivalent of the bookmark created in the Word document by the automated TOC feature, enabling the entry in the TOC to link to this heading.
What
should happen (and what does happen if you were to open the HTML file in a browser) is that when the application follows the link from the TOC entry to the bookmark, it should recognise that the A element is contained with the H1 element, and apply the formatting defined for the H1 element to the text it contains.
However, as far as I can tell, what the Kindle appears to do when following an internal link within a book, such as the links in the TOC, is to go directly to the element containing the bookmark attribute - in this instance the A element - and it fails to pick up the formatting associated with the H1 element that contains it. However if you page forward and back, or page back and then forward, the Kindle picks up the element construction correctly, and applies the correct formatting.
So... the only solution I've found to this Kindle formatting bug is to edit the HTML so that the bookmark attribute is in the heading tag, rather than being in an A tag contained within the heading tag. That way, when the Kindle follows the TOC link to the heading, it arrives at the heading element itself, and applies the correct formatting.
Note that the "name" attribute is gradually being phased out in HTML, in favour of the "id" attribute. So, although the "name" attribute will still work perfectly well, it's probably best, if you're editing the HTML anyway, to switch to using the "id" attribute.
The above HTML example code would be changed to the following:
Code:
<h1 class="heading1style" id="bookmarkname">Chapter One</h1>
As you can see, there's now no A element, and the bookmark attribute (now "id" rather than "name") is inside the H1 tag.
In terms of
how to do this, the simplest way, I think, would be to save your Word doc as "Web Page, Filtered", then open the resulting HTML file in a plain text/HTML editor, so you can edit the actual HTML code. The main thing is
not to use anything that offers a WYSIWYG interface. Windows' Notepad is absolutely fine for this, or if you already have a favourite plain text editor, use that.
Go through the file and change the code for each of the chapter headings, then save the amended HTML file.
Then, in Mobipocket Creator, import that HTML file rather than the original Word doc, and create your ebook. Hopefully, this time round, the formatting should behave correctly when you follow the links from the TOC to each chapter.
The main downside of this (apart from having to go in and edit the HTML directly, of course
) is that if you have to make any changes to the original Word doc, and then re-save as HTML, you'll have to go through the process of editing the HTML code all over again. So, after trying it to see if it solves the formatting problem, you probably don't want to bother about the formatting issue while you go through each round of amending the Word doc, creating a .prc file, then checking it in the Kindle. Then, once everything else is fine, save as HTML, edit the heading codes, and create the final version of your .prc file.
Any problems or questions, just shout.