Quote:
Originally Posted by eschwartz
I "bought" the book, and cracked it open with calibre editor.
Inside is a single HTML file, all CSS is applied directly via style attributes, chapters are separated by
Code:
<div style="page-break-after:always"></div>
and there are no ids to direct a link to.
The tox.ncx in calibre editor shows a bunch of links to "text/part0000.html" -- no fragment identifier. The ebook-viewer sees the same, I imagine.
On my Kindle, the Go To menu can see the chapters just fine (what id is it pointing at?  ). Same with swiping up/down (the KT still allows you to flip though chapters like that). |
Thanks for going to the trouble and having a look. This confirms my own experience. But where does this leave us? The Go To menu on the Kindle and on Kindle applications works presumably because it:
1. Does not rely on the toc.ncx; and
2. Does not rely on a toc.html as there is none; and
3. Identifies chapters directly from the div tags.
The Calibre viewer presumably uses the toc.ncx which, as you rightly point out, does not function as there are no ids to direct a link to. Moon Reader, when there is a toc.ncx present, seems to actually use the links to progress through the book, hence (with a converted epub, of course) will not progress past the first couple of pages unless the toc is corrected or removed. I haven't tested others, but imagine that most other non-Kindle readers and reading software will be fine reading the book (once again appropriately converted, of course) but the TOC links will not be functional.
I corrected the problem relatively easily in Calibre's toc editor by deleting the contents of the existing TOC and auto-generating a new working one. However, I recall one other book which had no TOC and where any of the existing auto-generation options resulted in an empty one. In this case I "gave up" and just created it manually as it would have taken me far longer to play with XPath expressions for a likely one-off case.
Is my description of what is happening correct? I am currently checking all azw3 files I download for this problem, and correcting it before importation to Calibre. I am finding probably about 1 in 10 books affected on a small sample so far. Can you think of any better solution than my current one?
I am reluctant to submit it as a bug, since I really don't see it as a problem with Calibre, and I also don't see any easy fix forthcoming. I suspect that the Calibre Developers have far more important priorities, as this thread now at least lets those concerned know what the problem is and how to correct it. What do you think?
Once again, thank you for your help.