View Single Post
Old 11-28-2014, 05:54 PM   #6
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 11,503
Karma: 158448243
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
Quote:
Originally Posted by Peter Ahlstrom View Post
I'll give an example.

So, I have a book where each chapter has some introductory text at the top of the page, before the chapter title. The chapter title is what is listed in the Table of Contents, but if a user clicks on that entry, I want them to see the introductory text before the chapter title. So the link goes to the top of the page, not exactly to the chapter title header text.

Now, that chapter has 3 subheadings in it. If they click on the 2nd or 3rd subheading, they will go directly to that exact spot in the chapter. Great.

But the 1st subheading is directly under the chapter title. The reasons I have for wanting them to see the page's introductory text are just as valid for the first subheading as they are for the chapter title. So I want clicking on the first subheading in the TOC to also take them to the top of the page, just as clicking on the chapter title does.

So does that help?

I could work around this Sigil error by having multiple a id= tags up at the top of the page. But that would be a workaround, not a final solution.

The basic point is that Sigil's Table of Contents GUI editor in this case is taking valid input data and creating an invalid toc.ncx. So it's a bug in Sigil.
No. It's not a bug in Sigil; it's invalid data. The "can't point two playorders to the same location" issue has been around for ages, IIRC. How is Sigil supposed to overcome that? You're pointing, apparently, to the same precise file, with nary a distinction--no id's, no anchors, nada.

We use id's for this type of use, OR, more customarily, we create more detailed TOC's, like Kevin's suggestion. In a print book, yes, the TOC, if you actually did it this way, would all point to the same "page," but now that's functioning like an INDEX, where the expectation is that the reader will figure out where on the page s/he is supposed to be, even though, by default, she's taken "to the top of the [print] page," when she thumbs to the relevant page, from the INDEX. OR, for that matter, from the TOC.

You're expecting the NCX to really function like a print book, by forcing the reader to start at the top of the page, no matter what they select. One option is simply to remove the extraneous elements from the NCX, and let the reader just go TO THE CHAPTER, which is, apparently, the behavior you want to force on them in the first place--the rest is window dressing, isn't it? I'm really not being argumentative, but if you don't want those readers to go elsewhere, why put the "elsewhere" in the NCX in the first place? (And, yes, I know that the answer will be, because later, that same reader might want to find X.")

But this isn't print. An NCX isn't some decorative, harmless page, as is a TOC in a print book. It's structural. You gotta give Sigil a little help here, and at the very least, give it SOMETHING to point to, like an id.

Just my $.02.

Hitch
Hitch is offline   Reply With Quote