View Single Post
Old 10-02-2016, 03:15 PM   #10
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 FizzyWater View Post
I realize this suggestion would take a lot of work, but if someone really wanted their ebook to contain the exact page numbers to correspond to a certain edition of a print book, could they add the page numbers as footnotes on the words that would be the last word on each page?
Without knowing your reasons, it's hard to say. YES, you could do that. When we have to link an index, we embed the page numbers invisibly, quite simply, as id's. No big deal.

However--and this is the point, to me--nobody seems to think about the usability of that. In other words, when you "go to" a page, in a print book, the term or concept you're looking for, IS on that printed page. So, you visually scan the page, and voila! There it is.

Right?

But when you create a MOBI, the page size is ABOUT 16.67% of the size of a printed page (or a "typewriter paper" page, 8.5" x 11"). That means that when you click that linked index item, you go to the top of page X. THEN, you have to scan through 1, 2 3, sometimes four pages, to find what you wanted.

To me, THIS is the bigger issue. Anyone--anyone at all--can create a MOBI or ePUB with page numbers in it. {shrug} Hell, anyone that's been doing this since the onset, say, eight years or so, has done it accidentally, probably, creating their first book from a scan.

But, what nobody HAS done, is make a "real page number" mechanism with linked indices, that isn't either nearly useless (the linked index) or frankly, hideous and intrusive (putting "real page numbers" in as either text or graphics.).

THEN, you end up going to FXL. But FXL is absolutely a horrible solution for books that are typically text-heavy, like textbooks. You can see the purpose in textbooks--you have students in a classroom, some with paper, some with electronic books, and you need to have a way to get there from here, easily. But, STILL, reading an FXL book on a Kindle, particularly, just like a PDF, is a pain in the @$$. You have to read, pinch-zoom, pan/scan, find where you are, read, pinch-zoom, pan/scan, lather, rinse, repeat.

To me--those are the real problems.

I think that the only viable solution is to create a "page map" as an index, at the back of the book. Embed the id page numbers, invisibly, as we already do for index-linked books, and put the page map at the rear, on the NCX, etc. The reader clicks "go to," and you try to put the page map on the Go To, but if that doesn't work, as a fallback, you have it on the TOC. Reader clicks goto TOC, then clicks the page map, clicks the relevant page, and goes to it.

I don't see, at this time, a more viable solution. That's what works, without being egregiously intrusive (real page numbers typed or inserted, which then have to be searched for). PLUS, if you are going to use this solution, which means, the reader has to use the SEARCH function, to go to the page they need--why not use page numbers that you're put in, hidden? Why not do that? What's the ADVANTAGE to visible page numbers, given that you HAVE TO use search, no matter what, in these two proposed solutions? Imaged and typed page numbers, I mean?

AND, for those of us who have done it--what happens when you have multiple inbound links, to a single element? A heading, for example, etc. If you've ever deal with the realities of indices or other back matter that creates multiple inbound links to a single target, you've had to then deal with the "many to one" issue, of--how do you get the reader BACK to where he was, when he clicked the index item? Ooooooh....you can't, if you are on a device WITHOUT a back button. If John flips through 2, 3 4, pages, seeking whatever it was he clicked for, and then wants to go BACK to the index...well, the back button has to be clicked quite a lot to get there from here. And if he doesn't have a BACK button, well, he has to go the long way--Go To TOC, go to Index, search for where he was using his eyes and his click. {sigh}

Those are my thoughts. Probably not going to have more, until a different/better solution comes along, than the visible, linked page map, going to either id numbers or Hidden page numbers (the problem with the hidden is having them NOT intrude on text continued from the prior page).

Good luck on this one, guys. See you around.

Hitch
Hitch is offline   Reply With Quote