View Single Post
Old 01-22-2011, 08:53 AM   #5
bfollowell
Fanatic
bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.bfollowell ought to be getting tired of karma fortunes by now.
 
Posts: 541
Karma: 1152752
Join Date: Aug 2010
Location: Evansville, IN, USA
Device: Samsung Galaxy Tab 4 Nook & Samsung Galaxy Tab S 10.5
Quote:
Originally Posted by DMSmillie View Post
This is a somewhat obscure bug that I've run into myself. It seems to revolve around how the Kindle OS handles applying formatting when jumping to a named location.

If the formatting (e.g. centered text) is linked to an element that comes before the element that contains the bookmark name that is being jumped to, the formatting doesn't get applied. If, after jumping to the start of the chapter, you move one page back then one page forward, you should see the correct formatting applied to the chapter heading.

So, in the example code you provided, I'm going to guess that the text center formatting is linked to the "chapterhead" class, but the navpoint is the id in the H2 element? So when you use the 5-way controller to jump to the chapter start, the Kindle ignores what comes before the H2 element, and only applies the formatting that is coded from that point on. If you page back and then forward again, though, it picks up the formatting linked to the "chapterhead" class, and the chapter heading is displayed properly.

If I'm right and that's what is happening here, the only way to avoid this is to ensure that the formatting you want for the chapter heading is applied to the heading element itself (i.e. to the element which contains the id used in the navpoint/TOC link), and not to a containing element (in this case, the "chapterhead" div).
DMSmillie,

Thanks so much for your post. I believe you may be onto something. I had to read through it several times before it started making sense.

No, all of my chapter header formatting is actually in the h2 element chapternumber. All of the previous elements seem to serve very little purpose actually, especially the chapterhead division directly around the h2 element, though the nav point is setup in the topmost chapter element.

I am going to try removing the division around my chapternumber altogether and then move the navpoint ID down to the h2 element and see what this does. I have a feeling that this will take care of my issue. I'll post back if it's successful. This all stems from a wealth of Microsoft Reader files that I'm working to convert for use on my K3. I'm first converting to epub for editing & cleanup then converting to mobi. 99% of the time everything goes smoothly and I get a mobi file that is formatted better than most of the commercially available ones I've seen. The other 1% of the time I get something weird like this and I have to work on it for a while as I'm still teaching myself html/css.

Thanks again for your help.

- Byron
bfollowell is offline   Reply With Quote