Real Page Numbers for Reflowable Kindles

[Bob Doyle]

When I published my first book, Free Will, on Amazon in 2011, it was a reflowable mobi generated by Kovid Goyal's Calibre.

I created 340 small gifs and added them to the text flow at or near actual page breaks in my print edition.

I am now working on my second book and hope to upload it soon to Amazon.

I have several test Kindles, my original as well as the latest Fire HD8 and the Paperwhite. The PPW optionally displays the real page numbers in my Free Will book as well as their locations.

In the PPW Go to menu, I can go to Page or Location.

But the Go to menu in the Kindle Fire has the Page option grayed out. I can't see why.

Amazon tells me I can offer two versions of the Kindle book, one FXL, one reflowable. I have exported both types of EPUB from InDesign. Kindle Previewer throws lots of errors for both.

Calibre converts to a MOBI that plays well in the PPW, but I am having trouble sideloading into Fire HD8.

I am writing up a HOW TO ADD REAL PAGE NUMBERS for textbook authors who want page numbers that correspond to their print edition.

Instead of gifs, this time I added page numbers with the same style as those in the print edition.

I attach a draft and would appreciate critical feedback. I will submit this to InDesign Magazine.

[jhowell]

This question would be better asked in the Workshop forum. That is the place for questions about e-book creation. (You could ask to have this thread moved there if you like.)

----

ETA: Regarding the problem with the Fire tablet:

Kindle reading devices do not look inside a MOBI file for page numbers. They expect a separate page number file (with an .apnx extension) to be delivered by Amazon along with the book. Without that file only location numbers will be shown.

(An exception to this is the newer KFX format. It supports real page numbers without an apnx file.)

[NullNix]

Originally Posted by Bob Doyle

I attach a draft and would appreciate critical feedback. I will submit this to InDesign Magazine.

That looks, frankly, entirely terrible. The last time I saw a book formatted like this it was a really, really bad scan-and-OCR and the people doing the OCRing hadn't realised that they had to strip page numbers out.

Page numbers embedded in the text look horrendous in reflowable books for exactly the same reason that a page number stuck in the middle of the running text of a page would look horrendous in a paper book: page numbers (and other header/footer information) must stay out of the way, at the top or bottom of the visible page area, and the Kindle has no way to implement floats like that (indeed, it's hard to see what it could even mean, when the user can change font size or move any multiple of 128 chars back or forward at any time).

There is already a mechanism for out-of-line page numbers. Smuggling them in like this does nothing but make your book unreadable.

[HarryT]

Moved to the Kindle format forum, where questions such as this belong.

[Doitsu]

Originally Posted by jhowell

Kindle reading devices do not look inside a MOBI file for page numbers. They expect a separate page number file (with an .apnx extension) to be delivered by Amazon along with the book. Without that file only location numbers will be shown.

BTW, it isn't possible to generate APNX files with KindleGen, but KindleUnpack will reverse-engineer them if the original ePub contained an Adobe page-map file or an NCX pageList section.

(AFAIK, ePub3 NAV page-list sections aren't supported by KindleGen, even though KindleGen has partial support for other epub3-only features.)

[Hitch]

Originally Posted by Doitsu

BTW, it isn't possible to generate APNX files with KindleGen, but KindleUnpack will reverse-engineer them if the original ePub contained an Adobe page-map file or an NCX pageList section.

(AFAIK, ePub3 NAV page-list sections aren't supported by KindleGen, even though KindleGen has partial support for other epub3-only features.)

Thank you, Doits.

Hitch

[Hitch]

Originally Posted by jhowell

This question would be better asked in the Workshop forum. That is the place for questions about e-book creation. (You could ask to have this thread moved there if you like.)

----

ETA: Regarding the problem with the Fire tablet:

Kindle reading devices do not look inside a MOBI file for page numbers. They expect a separate page number file (with an .apnx extension) to be delivered by Amazon along with the book. Without that file only location numbers will be shown.

And, as far as I know, a self-publisher has no way to deliver the .apnx with the MOBI. Via the KDP. Isn't that what we all determined, the last time we all got involved in a "real page number" project here on MR?

(An exception to this is the newer KFX format. It supports real page numbers without an apnx file.)

Yes...but who knows if the KFX will even last? Honestly, to me, it looks like a half-step toward something else--but you'd know best, as you've done all the work on it.

Hitch

[FizzyWater]

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?

[HarryT]

Let's take a step back here. Perhaps the OP can explain why he wants to have these page numbers in his book. There may well be a better solution available.

[Hitch]

Originally Posted by FizzyWater

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

[Tex2002ans]

Originally Posted by Bob Doyle

I created 340 small gifs and added them to the text flow at or near actual page breaks in my print edition.

[...]

Instead of gifs, this time I added page numbers with the same style as those in the print edition.

Ouch... In ebooks, you DO NOT want to have numbers in the middle of the text. (As others have mentioned, they are distracting).

And GIFs of page numbers? That sounds like the absolute WORST. I shudder to think what that looks like when the user raises the font size or changes colors.

Originally Posted by Bob Doyle

Amazon tells me I can offer two versions of the Kindle book, one FXL, one reflowable. I have exported both types of EPUB from InDesign. Kindle Previewer throws lots of errors for both.

The last time InDesign-specific discussion + Page Numbers came up was in this topic:

https://www.mobileread.com/forums/sho...d.php?t=272034

and from what I was able to gather, InDesign CC only generated the page-list files for fixed format EPUBs.

Originally Posted by Bob Doyle

I am writing up a HOW TO ADD REAL PAGE NUMBERS for textbook authors who want page numbers that correspond to their print edition.

First, you have to painstakingly go through the book and insert invisible links like this wherever there is a page break:

<p>This is some example text<a id="page99"></a> that goes onto the next page.</p>

Probably best to use a logical ID like "page###".

Then you generate the necessary files. There are three different methods to insert "Real" Page Numbers into EPUBs as Doitsu has mentioned:

• EPUB2 Methods
  
  • page-map (only works in ADE-based readers)
    
    • This is a separate XML file you can insert into the EPUB.
      
    • *** Will cause EPUBs to fail epubcheck ***
      
    • You can read more about that in the MobileRead Wiki here: https://wiki.mobileread.com/wiki/Adob...tions#Page-map
      
  • pageList
    
    • This is XML that gets inserted into the toc.ncx file.
      
    • You can read more about that in the MobileRead Wiki here: https://wiki.mobileread.com/wiki/PageList#PageList
      
    • Doitsu's PageList plugin for Sigil is the only tool I am aware of to make generating the PageList easier: https://www.mobileread.com/forums/sho...d.php?t=265237
      
• EPUB3-only Method
  
  • page-list (confusing name... I know)
    
    • This uses EPUB3-specific <span epub:type="pagebreak"> code.
      
    • See this article as an example: http://www.digitalbookworld.com/2015...ntents-part-2/

As Doitsu mentioned, KindleGen can successfully convert the first two types into Amazon's equivalent.

Originally Posted by FizzyWater

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?

While I could see that being better than having GIFs... I still would argue it would be better to not have the "real" page numbers clogging up the text at all. Plus there are better methods.

Originally Posted by Hitch

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.

[...]

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.

For anyone who is not aware, there was a fantastically in-depth discussion in the thread "Sick of Amazon Kindle books without Page Numbers":

https://www.mobileread.com/forums/sho...d.php?t=272392

There is lots of information in there for everyone to learn from... but I think the real fun begins at Post #129 when I arrive!

"Real"/Physical Page Numbers make no sense in a digital book.

[FizzyWater]

Originally Posted by HarryT

Let's take a step back here. Perhaps the OP can explain why he wants to have these page numbers in his book. There may well be a better solution available.

This is from the original post:

Originally Posted by Bob Doyle

I am writing up a HOW TO ADD REAL PAGE NUMBERS for textbook authors who want page numbers that correspond to their print edition.

I took that to be the reason.

[meeera]

As far as I can see, the better solution to the problem is simply for the user to use the tools that ebooks have that print books don't: namely, the electronic searching that is already inbuilt. Back-of-the-book indices are an obsolete tool relevant only to paper books.

[Tex2002ans]

Originally Posted by meeera

As far as I can see, the better solution to the problem is simply for the user to use the tools that ebooks have that print books don't: namely, the electronic searching that is already inbuilt. Back-of-the-book indices are an obsolete tool relevant only to paper books.

You should give that Page Numbers topic a thorough read.

I see Page Numbers + Indexes as closely related topics, but maybe we should keep this topic JUST towards discussing how to add the Page Numbers to the EPUBs/MOBIs.

I wouldn't mind if you contributed your thoughts back in that topic though. Just ignore that "This thread is quite old" warning and post your own input. I think more people need to see/read it!

Quick Side Note: Search in an ebook, while absolutely fantastic = a Concordance (a list of all the words in a book).

A well-made/well-curated Index is superior, because it can handle more broad AND more specific cases where Search fails.

Here are the the examples I gave (Post #139 if you are interested):

Originally Posted by Tex2002ans

The superiority of the Index is the human curation.

They can tackle more specific topics that you can't get through a simple search. For example:

"Ricardo, David -> law of association, 158–163, 168, 174"

If you did a search for "Ricardo", you may get a ton of different hits (43 hits in this book), or if you did a search for "law of association" you may get a whole other host of hits (10 hits). But if you wanted to know about David Ricardo's law of association... that is a different beast.

Or an Index can cover much broader topics such as "Ancestry" (which would cover "ancestor" + all related terms/words).

An Indexer also makes sure that all the irrelevant mentions are not needed. (Aristotle might be mentioned 10 times in the book, but in only 2 cases is he actually relevant to the text).

[HarryT]

Originally Posted by meeera

As far as I can see, the better solution to the problem is simply for the user to use the tools that ebooks have that print books don't: namely, the electronic searching that is already inbuilt. Back-of-the-book indices are an obsolete tool relevant only to paper books.

I strongly disagree. A good index is far more than a simple list of words; it will provide guidance on broad topic areas of interest to the reader. Creating a good index is a highly skilled and specialised job.