|
Hitch, you sound so worked up! I suspect this issue isn't worth that much angst.
I already know how an index will work in paper and the differences with ebooks. I also know how html works.
Your reply is actually full of good information that will come in handy for newbies who don't understand the mechanics of it. Should have been written up with a more helpful tone.
Making the target itself a blue underlinded piece of text is not appropriate, of course publishers are not enamored of it. Doing that only makes the target look like a link because that's what everyone is use to seeing after using the net ever since forever. And if it's only a target (and not a link back to the index) it's only blue underlined pieces of text. You'd have to put in a separate link back to the index. Possible, at this stage I haven't done that. On some browsers using the back button will take you back to the index, but not on all browsers. It's easy to make the target invisible by using different coding (thank you helpful mobileread people on a different thread).
Just to clarify, I'm only looking at a simply name index, but I suspect if my problems were solved it could be upscaled for large books with a complex index as well.
And when I say it's an overlooked opportunity I'm talking about the programmers who haven't yet worked out a solution. This isn't my area, I actually don't know how much work would be involved, but I suspect it hasn't been done because of the idea that search is enough rather that it not being possible.
The target text does not land at the top of the page in an ebook in any reader or software reader I've tested on, only on a html page.
The problem with the target not being blue underlined is that then the target can't be seen easily when the link is activated. It's somewhere on the page. (Which is how a paper index displays).
A solution to that could have been to have a temporary highlight on the target in an ebook when the link it activated, and that's what I've realised, on this thread, isn't possible with current html/css and ebook conversions.
And, actually, having multiple targets is easily displayed in the index using a, b, c etc. Looks good that way. The code part of the targets in mine also have letters that match. I use find so I don't miss an instance of a name and paste code down the page, just changing the letter difference as I go. I don't have trouble knowing where I'm up to and then I can create the correct number of links in the index just changing the letter on each.
And yes it is semi-painstaking. I've only done a small family history book. Working out a system helps (shrugs).
We could number paragraphs, and I've seen small ebooks that do that, but it is so clunky, especially so in a larger book, even if you use chapter no. and paragraph number. Clunky. And I don't like seeing chapter numbers in the text so they'd have to be invisible to satisfy me too. I may try this sometime.
As I said further up the target will not be on the top of the screen on an ebook reader or software (except by coincidence). This could be different in a .mobi or whatever ibooks use. I haven't tested those formats. It *will not* in an epub.
Ok, and saying again, I know it's the creation process. The creation process is what needs to change.
At this stage I don't care what publishers will pay for. Search is not as good as an index, an index is a structured finding tool that facilitates learning. Of course publishers are going to not pay for it unless they find dollar motivation. Publishers motivations have always involved money. On the other hand if some use proper indexes, others will be pressurred into using them.
Just because it's currently difficult doesn't mean it isn't a problem that shouldn't be solved. Talking about it will help push in that direction. Sitting back and ignoring it, or accepting half assed work arounds will only mean it's never solved.
|