Bug Report: Mobi Conversion puts TOC Nav in wrong spot
 

If I take an untouched retail ePub with a perfectly functioning TOC (ie, which guaranteed navigates to the correct position in the book), convert it to Mobi, and then either to htmlz for editing or even directly back to ePub, the conversion puts the TOC navigation anchors in the wrong spot.

When I look at the intermediate html code, the Mobi conversion has placed tags like:

<pagebreak id="something">

...but it places these BEFORE the <div class="mbppagebreak"></div> code, so when you navigate in the final converted ePub, it goes to the bottom of the page before page break and the actual chapter you want.

It should be putting these tags AFTER the <div>

And while I'm at it, why doesn't it just add the id=whatever to the <div> tag so you don't need the extra non-standard <pagebreak> tag? The problem is that <pagebreak> isn't a real html tag, and it hangs tools like HTMLTidy, the file can't be processed to clean up the code with these <pagebreak> tags in it, they have to be manually converted to something else like <p> or <div> before Tidy can be used.

Is this something that can please be fixed? manually changing the tags and them moving them to fall after the <div class="mbppagebreak"> tag takes a lot of effort.

Thanks
The REAL Joe

Does that work in HTML? I thought that you could only link to IDs within <a> tags.

Dont convert it to MOBI first. Convert it directly to HTMLZ or EPUB.

I have a particular reason for wanting to do the mobi conversion first. A lot of retail ePub's are formatted with hard coded font families, line heights and other things that are very difficult to manually strip out - conversion from ePub to htmlz leaves a lot of remnants behind making the process tedious and frustrating. Converting first to mobi strips all that crap in one fell swoop, which I've found much simpler to deal with, but has these pagebreak issues...

Cheers
The REAL Joe

There's a filter css option in the conversion settings under Look & Feel