Real Page Numbers for Reflowable Kindles
 

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.

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.)

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.

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

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

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?

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

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?

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.

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

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.

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.

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

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.

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.

:thumbsup:

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.

This is from the original post:

I took that to be the reason.

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):

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.

Yes - however I am thinking of a high quality search engine, which gives results with a sentence or so of context, not merely a list of page numbers on which the searched word appears.

That combined with a high-quality Table of Contents certainly gives me everything I could ever need. I'd ask for my money back on any book that had hard coded page numbers everywhere.

Read the Page Number topic + put your thoughts together + post. I'll respond to you there! *hint hint nudge nudge* I think you will be glad you did.

I personally think that is one of the top-most informative threads on all of MobileRead. :)

:thumbsup:

A simple example of something I could get from an index, but not a search:

The author Charles Dickens lived in many different houses over the course of his life. In a good biography of Dickens, I can look up "house" or "home" in the index, and I'll get a list of all the houses that Dickens lived in, with text references for each one. There is no simple search I could do in the book which would get me such a list. As I said in my previous post, an index allows you to search on topics rather than on just words that appear in the text.

Yes, Harry:

I concur, completely. This is part of the conundrum, when I'm discussing this issue with a client or prospective client. This is why we started using the embedded ids, so as to create a linked index...but as I mentioned, it's cumbersome, at best, to use.

Yes, but we all asked WHY, to tease out the actual usability issue. IOW, why do we WANT RPNs? (Real Page Numbers, I'm sick of typing it out.) What are the reasons?

1. An instructor in a course that will have people with both e- and print books, wants to be able to say "this week's coursework is from page X to Y."
2. We have an index, and want to be able to go directly to that page.
3. Now I'm out of reasons.

In the case of 1, you can do that with either a) the embedded id's linked to a back-of-book page map. Using the invisible (to the eye) id's, alone, doesn't QUITE get the less tech-savvy there, (and you can't really search for ids, using an on-device search), and that likely works best, and the least intrusively, for the user. Bear in mind, for this one, if you put images in, you can't search those. That makes those worse than useless, in my opinion. If you type page numbers in, and the book goes to (say) page 324, and you're searching for page 24, you'll get p. 24, 224, 324...and etc. This then combines the interrupted page appearance (which ALWAYS looks like you've made an error, to the buyer, and don't think that they won't hop, skip and jump to go tell Amazon about it!!!), and a form of search. So, this doesn't really emulate the user-friendliness of RPNs and thumbing, not really.

In the case of 2, we can all do what we've been doing--embed the page number as an id, and jump the user there, EXACTLY as they would have, using some page-flipping/thumbing, so that the person ends up at the top of the "page." Then, just like print, they are on their own to find the material "on the page" or screen(s). As I hope I explained, above, that has some real drawbacks.

I guess that 3 would be, "just because that's how it is in print, and I want it." I mean, to restate what I said, if you embed pngs, or jpegs, icons, whatever, you cannot search on those. That, to me, is pretty useless. No offense to the OP here. What's the point? What, the reader opens the file, and then click-click-clicks his way, to find page 158? Sweet moses on a pony. How user-friendly is that?

If there's some other aspect to having "real page numbers," I don't know what it is. I've now had 3 different folks, in the last few weeks, ask me to make FXL books for them, because they say that they HAVE TO HAVE RPNs. But the thing that gets me is, they can never really elucidate the WHY. As in, what functionality, from print, EXACTLY, is being replicated?

My issue isn't that we're unwilling to do what it takes, to make RPNs. My issue is the end-user experience. Amazon--and let's face it, ePUB or MOBI, those dudes are the 900lb. gorillia--is VERY attuned to this. You get 1, 2, or 5 complaints about usability, and they get VERY nasty, very quickly, with the publisher. That, then, is on the publisher.

About my selfish reasons:



Oh, yes, of course--you can create FXL. But I still feel strongly that FXL is the WRONG solution for text-heavy pages. Lord, talk about a BAD reading experience! Hundreds of pages of pinch-zoom, pan/scan, etc.? NO THANKS.

Them thar are my thoughts, gang. Meera--I don't agree that a concordance is a reasonable substitution for a properly-curated index. I agree that it's better than NOTHING, of course, but...they're not the same.

Just my $.02,

Hitch

The third reason (and it should really be the first) is that writers of Serious Books might want to quote you, and the citation really should work both on the print edition and the digital one. It's absurd and somewhat embarrassing to have to put "location 3543". (I usually just grit my teeth and cite by chapter, but that wouldn't work in À la recherche du temps perdu, would it?)

It's not just academic works that get quoted! A couple years ago I published a book that cited among other things The New Yorker, a 17th century troubador song (from the internet), and the Polish historical novel Potop ("The Deluge").

RPNs are wonderful. (If only they were easy.)

EXCELLENT point. Thanks.

Excellent point. It truly is, and I have no argument with it. Now, for a lighter moment:

Now I'll write that that guy (James Scott Bell) who cited me (unbelievable!!!) and tell him that I need him to use RPNs. MWAHAHAH. Seriously--he cited me from something ON THE WEB. I can see people trying to Strunk & White or CMOS that sucker. :rofl: (Speaking of Lost Time...)


Hitch

Hi All,

Thanks very much for all the references to other posts which I will read carefully.

First, may I explain why do I need page numbers in the text of my reflowable eBooks?

It's because, as Tex2002ans explained, my multilevel index (topic entries and subentries) was curated carefully, by me as the author and by Heather Hedden, a board member of the American Society of Indexers, as editor. It cost over $1000 to prepare the index for my472-page textbook.

Now Hitch is rightly concerned about her "many-to-one problem," but an entry with multiple page numbers works beautifully in my two books, at least on some Kindles, notably the Paperwhite (which has a great back button)..

Consider the entry
Einstein, Albert
light quantum hypothesis of 361–364, 377

When I click on 377, it jumps to a "location" two pseudo-pages past the location with the in-text page number 377, as Hitch criticizes. But it goes precisely to the text with the Einstein marker I embedded in InDesign - just where it should go.

And, when I hit the back button in PPW, it jumps back to the "location" in the index with the Einstein entry, so I can now go to page 361 to learn more about Einstein's amazing hypothesis.

Once again, it goes precisely to the end of page 361 (we see page number 362 just below) and once again it is the right position in the text where I embedded the index marker.

And still once again, if I hit the back button, I am back with the subentries under Einstein, which is where I want to be to continue researching this topic.

Despite Tex2002ans other comments, I se nothing "distracting" about my page numbers (I agree the gif images were clunky in my 2011 book). With page numbers, students can be sure they read the assigned pages.

If students made up their own search terms, they would be most unlikely to find the right information, nor could I assign search terms that would zero in as perfectly as page numbers do from my carefully crafted index.

I think a hyperlinked index with page numbers in the text (this isn't a novel or comic book where numbers would be a nuisance) is an excellent thing in digital publishing.

Digital search is of course a terrific edition. My students say they use search when in a preliminary research mode, but they always read print material for deep study.

As the developer of the first desktop publishing software, MacPublisher, for the original 128K Mac in 1984, I am very happy with the Adobe InDesign CC that I use today. It produces very fine ePubs for iBooks and other standard eReaders that put Amazon Kindle to shame. But Amazons sells a lot of my print books and even more Kindle versions, so I am stuck with them.

I should note that Kovid Goyal's Calibre chokes on the EPUB3 FXL exported from InDesign. But a young EPUB developer from India (Pratibha Saini) has succeeded in producing a beautiful KF8/mobi fixed layout version of my latest book, Great Problems in Philosophy and Physics Solved?

Unfortunately, the page numbers in the index are not working as hyperlinks in Kindle Previewer 3, or when I sideload the file into my Fire HD8.

When I mouseover a number, the cursor changes in Previewer so the link is under there somewhere. But it just doesn't work. In the HD8, it doesn't even change the pointer to the hand as Previewer does.

Ken Jones' Circular FLO generates a somewhat similar file. it's fixed
layout looks good (though it's over twice the size of Pratibha's), but the links don't show a hand as I mouseover. The whole page always shows a hand cursor that goes nowhere in Previewer.

I am not recommending fixed layout for the smallest Kindles (as Hitch might think?), but my Fire HD8 screen looks to be about 95% of the page size in my 6"x9" textbook. The HD8 screen in 1/2" taller and 1/2" narrower that the iPad Mini, and my fixed layout book is quite readable in both without pinch and expand.

The FXL eBook is a precise replica of my textbook, which not only has page numbers, but also informative chapter titles and even chapter thumb tabs in the margins for easy physical navigation. Here is the Einstein reference page...

http://www.informationphilosopher.co...s/Einstein.png

It seems clear that InDesign is putting something in their EPUB3 export that conflicts with Kindle's guidelines. My Indian developer claims it is in the CSS.

KDP recommends that a KF8 book start with an EPUB.

Do any of you know of an EPUB template whose OEBPF files could be unzipped and inspected for the right CSS, metadata, and any xhtml file headers that would satisfy the KDP conversion process?

I can see everything in my BBEdit and <oXygen/> editors. I just need to know what is required for KF8/AZW3 or whatever format KDP wants.

Thanks again for your help to textbook authors who want them to be as similar to our print works as possible.

Cheers,

Bob

Dear Notjohn,

Thanks so much for mentioning citations, which are essential for references in academic articles.

In my many thousands of pages website, informationphilosopher.com, I wrote a javascript to "Cite this page," but of course a web page is the equivalent of many print pages, so it's very rough. Maybe I should add sub-page numbers! Many scholars have used it and thanked me for an automatic citation. My site is widely used in schools. Google Analytics reports 700-800 unique new visitors a day.

By the way, the original material for my two books (so far) and maybe seven more books to come, is now on my website. I also post there free PDF versions of my first two books.
informationphilosopher.com/books

And you can read more about my revisionary history of Einstein and quantum mechanics here.
http://www.informationphilosopher.co...ists/einstein/

Coming back to real page numbers, my colleague Heather Hedden ran a subgroup of the American Society of Indexers on web indexing years ago. That has now been renamed digital publishing indexing, and she is preparing a report for the next annual meeting of the ASI on indexing a digital publication.

I hope to help her with research on the current state of the art. And we might submit an article to InDesign Magazine on the subject.

Frankly, all the standard EPUB readers do an excellent job (especially with InDesign index output) so Amazon is now a travesty that would be great to repair if we can find a template for an EPUB FXL sample file that converts both ToC and index with working hyperlinked page numbers.

For my purposes, Kindle reflowable is quite acceptable now - with my Indesign EPUB3 reflowable converted by Kovid Goyal's Calibre (although I have read many comments saying this does not work) and my unorthodox insertion of a paragraph with the page number at or near a page break.

Thanks again,

Bob

Page Numbers

Anyone 87 who actually reads 88 ebooks finds 89 page 90 numbers 100 in the middle of text 101 distracting.

• Breaks search
  
  • What if I wanted to do a search but the sentence crosses pages?
• Don't work the way you want.
  
  • As Hitch mentioned. Trying to search for "24" will lead you to: "124", "224", "241", [...]. Plus all of the actual TEXT: "24 apples", "240 bananas", "in 1248 BC".
• Break copy/paste
  
  • What happens if a paragraph crosses the page boundary?
    
  • What happens when a single paragraph encompasses multiple pages? (Imagine a large figure that takes up 3/4 of a page + a large paragraph before/during/after it).
    
• Interfere with Text-to-Speech

And there are already ways to handle Page Numbers in EPUBs (mentioned previously). They are a part of the standards (so you can easily "jump to the correct page"), and they can appear non-intrusively on the device (out of the way in the device's Footer).

Not to mention Accessibility reasons (a screen reader will be able to use the standards-compliant way, not the hodgepodge way a single author decides to code their book).

Just beware if Amazon will crack down on such a poor design. Page Numbers DO NOT belong in the flow of the text, and many readers will return the book as "Defective".

Amazon recalled a book over the Text-to-Speech issues when an author used MINUS SIGNS instead of hyphens. It caused a giant ruckus.

I 102 could see the same hammer be applied to 103 page numbers in text (as Amazon already does when enough 104 people return REALLY crappy OCRed books).

Indexes

You would have to show specific code examples. Most Indexes are designed with page### ids and jump to approximate locations.

Key word is SOME. SOME devices/readers don't have a back button. We have to design the ebooks taking many of the lowest common denominators into account.

In the case of a Footnote in the Text:

Code at end of Chapter (or in separate Footnotes chapter):

The user WITH the back button can either click on the link to jump back OR use their back button.

The user WITHOUT the back button can still click and jump back.

In the case of One-to-One, this is great usability!

With the Index (Many) -> Page Number (One).

Code in Text:

Code in Index:

You have a few problems (off the top of my head):

1. The link is ONLY ONE WAY.
   
   • Users without a back button are screwed.
2. MULTIPLE links point to page 100, but there is no good way to go from page 100 BACK to the X amount of Index references (Hitch's Many-to-One Problem).
3. See below.

The problem here is again what Hitch brought up: FONT SIZES (font size can be much larger than in print) and DEVICE SIZES (most ereaders are not as large as pages in print books = less text per screen).

Here is just a quick example I grabbed:

Index: Period of production, 484

Ok, let me bust out my dusty ol' tome and hurt my hands dragging this thing to page 484! :D

PDF of Page:

Attachment 152204

Ebook (this is on my phone [much tinier than the physical page] with a slightly larger font size):

Attachment 152205 Attachment 152206 Attachment 152207

I followed the link to "Page 484", but I had to read through to the THIRD SCREEN before I found where he talked about "period of production".

As Hitch mentioned, depending on the variables, it could be ~1-5 Screens away from where I was dropped off!

Sure, SOME of the references might be exactly at the "top of the page", but the experience for a digital reader is very poor.

Side Note: The usability/helpfulness of these types of Linked Indexes in ebooks is debatable. Even many PUBLISHERS think that this is unhelpful, and completely strip the Print Indexes out of their ebooks.

In the "Kindle Page Numbers" topic, I came up with the terms "Format-Specific" + "Format-Neutral". Go read that topic for more details! I think the Indexes would be more useful if they were more Neutral.

Great. I hope the material can be released for anyone to read. From what I was able to gather in my previous Indexing research, a lot of those Indexing/Library journals + articles are locked behind prohibitively expensive paywalls.

Fixed Format

Calibre doesn't read Fixed Layout EPUBs, and most of us are not fans of the absurd format anyway (it is trying to be like PDF, but a thousand times worse!).

There isn't ONE flavor of Fixed Layout... there are TENS, and they all have their own quirks and are COMPLETELY incompatible with each other.

You have to design the HTML/CSS specifically for Store/Device X:

• iBooks
  
  • ipad: This is what InDesign mostly caters towards.
    
• B&N
  
  • Nook
    
  • Nook Color
    
  • [...]
    
• Kobo
  
  • [...]
• Amazon
  
  • Kindle
    
  • Kindle Fire
    
  • [...]
    

Each one has to be hand-designed/tweaked PLUS each individual page needs its own CSS file, and everything has to be pixel-placed.

Also, a simple thing like device size will completely change the design of the "Fixed Format" (let us say your initial book is 7"x10", but you have to squeeze that design onto a small 5" ereader.).

Fixed Format drastically shrinks your sellable market, because the book is only going to be readable on a very tiny subset of devices.

AND Fixed Format books throw out the entire PURPOSE and advantage of ebooks (reflowability, changing fonts, changing colors, reading on all different devices, being able to flip Landscape/Portrait, [...]).

On top of it all, they are a pain in the neck to navigate (as Hitch said, pinching/zooming, panning/scanning).

Hitch covers some of the Fixed Format stuff here:

http://www.booknook.biz/booknook-ser...d-fixed-format

We discussed the Pros/Cons of Fixed Format at length before. Just do a search on MobileRead and you will come across those topics.

PDFs are the better "Fixed Format" experience AND can be read on more infinitely more devices. (Although trying to read a book-sized PDF on a phone, or a PDF on a lower powered ereader... absolute crap.)

InDesign creates an ABSOLUTE FUCKING ABOMINATION of code in their Fixed Format EPUBs. It isn't just the HTML/CSS.

(Forgive the language, but there is just no other words for the crap that comes out of it.)

Here is one sentence out of the latest conversion from InDesign I worked on:

Attachment 152203

This is what a CLEAN Fixed Layout code would look like (and a properly done Fixed Layout Book [like Hitch's company would design]):

This is the same sentence in InDesign's Fixed Format EPUB3:



they wrap a span around EVERY... STINKING... WORD... and absolutely position it with pixels + letter-spacing.

There is a reason why companies like Hitch's charge so much for Fixed Layout. Each one pretty much has to be designed over from scratch. And there is so many little quirks and oddities for each device that you have to take into account.

Misc.

Citing Websites + Digital Books directly is perfectly legitimate/valid.

Leave page numbers in the dust bin of history. :D

When you properly cite Tex2002ans from MobileRead in your articles... I don't want to see any "As the illustrious Tex2002ans stated on MobileRead on Page 3 when set to 10 posts per page, in the topic 'Real Page Numbers for Reflowable Kindles' [...]." :rofl:

The ebook should be SIMILAR in spirit... but trying to force the crappy Physical into a Digital experience is the absolutely wrong method.

Tex:

Thank you, for your as-always detailed and incisive addition to the discussion. Pardon me whilst I go off a bit:

I think that something is getting lost, in this conversation. Tex brought it up, twice, but as he is spared the indignities of dealing with fixed-layout and retailers, he's not quite as attuned to it as I.

Yes, you CAN build a fixed-layout "mobi" file, from a fixed-layout ePUB file. Voila!

EXCEPT, a) it doesn't work correctly on all devices in the Kindleverse, and, b) that will NOT PASS the intake inspection at the KDP, because quite bluntly, it isn't even remotely close to the coding that Amazon mandates, for their fixed-layout books.

(n.b.: I tested the MOBI that the young lady from Fiverr or wherever made. It did not function, at all, on my Fire device, period. The basic Fire I tested it on is First-Gen. I did not then test it on the others, because...what's the point? The Fire is the primary market for Fixed-layout.)

PERIOD. I am not saying, Bob, that someone can't find some way, using INDD or INDD-->ePUB--->MOBI (via Calibre--which is boggling), that wouldn't create a file that might somewhat function on an Android Fire device. Of course.

And, with a certain amount of effort, sewing, and tolerance to extreme pain, I might dress up my Maine Coon as an English Bulldog, and fool the nosy neighbor down the street. But, kids, that does not an English Bulldog make, firstly, and secondly, I'm pretty sure that the AKC wouldn't be fooled into listing Mr. Zep as an English Bulldog. Would they?


Now, obviously, in my fanciful scenario, Amazon = AKC.

There's a guy--he's referenced around here someplace--who hangs out in Nook territory, apparently a formatting expert of some kind, who persists in telling people that you CAN make a fixed-layout book for Nook. (There's a thread around here someplace.) YES, you can make a fixed-layout ePUB that will work on a Nook Device--somewhat.

What you CANNOT do, however, is make on that you can BLOODY SELL ON A NOOK DEVICE.

This entire conversation is starting to remind me of Jeff Goldblum's wonderful line, crafted by Crichton, in Jurassic Park. To paraphrase:

And that's relevant here. Why? Because while the book can be made, that doesn't mean that it can be SOLD. To me, given my line of work, that matters. Do we, at my wee shop, conduct experiments? Do I have media queries that we play with, that look like a map of Frodo's trek across Middle Earth? I do, bygod. However, 99% of my time is doing one thing: working on creating books that CAN. BE. SOLD.

Why? Because publishing is a bloody business. It's not a think-tank. (Lord, if there was ever any magical thinking in that vein, the past 6 years have most surely disabused even the most far-out magical thinker of any such notion.)

You, Bob, have already had your TOC revised AND moved to the rear of the book, being supplanted by Amazon's own efforts, because you went absolutely, positively, directly against their Publisher's Formatting Guidelines which expressly state:

You are thus already afoul of the Zon.

Unless the solution is something aside from the visible page numbers, I don't see Amazon biting on this. Not as an acceptable, to-be-sold book. Tex has listed all the various issues. Like your insistance that your index works--on ONE device. I promise you, it wouldn't work on all. That's why companies like mine, by and large, leave the index/indices in our eBooks, exactly as they existed in print, and we tell the readers to use the Search function, while being guided by the curation of the Index. We are thousands of books into this, and so far--nary a complaint about that.

But I can tell you without missing a beat that I've heard nearly endless complaints about how linked indices work--or don't. People do NOT like clicking, clicking, clicking to find "dog" on "page 23," which is 5 screens away from where they jumped. You didn't create your index like an index is created; you individually linked each word or sentence or paragraph to a specific page number in the index. That's not how 99.99% of all indices are created. Not at all. So, your solution, of linking to a specific WORD, isn't going to work for the business.

Moreover, how crisply does that "back" button methodology work, if the linked entry is 4,5, 6 pages of content, that the reader jumps to, consumes, page-flipping as she goes? I would promise you that the "back" button isn't going to work as advertised in that scenario.

So, sorry, gang. Didn't mean to go off on a tear. The bottom line is:

If you create a "fixed layout mobi" from a fixed-layout ePUB, made with InDesign, that eBook does NOT, and will not, MEET THE AMAZON QUALITY GUIDELINES. It is NOT formatted CORRECTLY. It will NOT be sold, by Amazon, at least, not for long before they remove it from sale and require you to fix it. It doesn't matter if the book did work. It doesn't, which is a whole other issue--but even if it did, you can't get there from here. (n.b.: and the book failed, utterly, to take advantage of the most fundamental features of fixed-layout--the RM!!!).

As far as the reflowable book, Bob, I've provided feedback both here and privately. I do not feel that the typed page number solution is elegant. I just don't.

I mean...how is that new? There's nothing revolutionary about that. That's what everybody was trying 6-7 years ago. If it works so well, then, aren't you asking yourself why absolutely none of the retailers have adopted that? Or why the ePUB standards aren't adopting that? I mean, it's tedium to do it that way, but it's not brain surgery. If that solution works so well, then why haven't all the retailers, etc., simply incorporated that into their guidelines and standards?

So, in closing, no ePUB template will help you. That's not how you get there from here. You know how we make eBooks, at my shop? Fixed-layout eBooks in MOBI format?

We code them by hand. Period. If that's the format you want, then you have to download Amazon's samples, the Guidelines, and do it up in good old HTML and CSS.

Bob said:
...the problem, Bob, is that you don't get to limit what device buys it. That's Amazon's wheelhouse. Once you put FXL up there--one made in accordance with the Amazon standards, that is--then anyone with one of the allowed devices or readers can buy it. Period.

BTW--fire the Indian "developer." CSS? Geeze, lady, try reading the damn manual.

There's no magic way to make a FXL MOBI from a FXL ePUB. I don't mean to sound terse or didactic, but I kind of feel like I'm saying the same things over and over, to no avail. Perhaps other folks' voices will be clearer.

Done now.




Hitch

Heh. Yeah, I don't know much about the selly selly, I just know about the converty converty! :rofl:

But I really don't touch designing Fixed Layout books with a ten-foot pole, I would shift all that pain and suffering onto you!

Does Kobo have their own brand of Fixed Layout EPUB? Is that actually sellable there or is it like B&N's mythical one? Or am I just going crazy again? Is this another case of only the Big Publishers get to do it and no one else?

Edit: I just went looking up some Kobo Fixed Layout Info and stumbled across this:

Me too. Bed time now! ... I should have just continued referencing the previous topic. I knew it was a bad idea getting me all riled up about "Real Page Numbers" again... :rofl:

Geeezee...it's 2:46 a.m., and I'm still doing this crap.

To answer your question(s);

1. There IS a real fxl format for B&N; it's essentially iBA (iBooksAuthor) wrapped up in a B&N wrapper, and it is used ONLY for books to be made and sold on the NookKids' platform. Not only do the publishers have to have a regular publishing contract with B&N (not a self-pubbing one, mind you), but you can't even OBTAIN the NookKids' software until you prove that you're competent to make the books. Which--wait for it--you do by providing them with sample NookKids' books that you've aleady made. Yes: you read that correctly.
2. IBooks has FXL for:
3. ePUB2 and
4. ePUB3.
5. Kobobooks will publish and sell ePUB3s made for iBooks. So, yes, that exists, but as you note--they are quite dissuasive about the idea, generally.
6. Amazon has their own, completely unique (to be redundant) set of criteria and standards for their FXL eBooks. Those are:
7. Kids' books, which can be handmade, like my shop does, or by using Kindle Kids' Book Creator;
8. Comic books (really only viable with the Kindle Comic Creator);
9. and Kindle Textbooks, which are the type of FXL that can zoom--but the font sizes cannot be changed, etc. This is the format to which I was referring in my various comments in this thred. This format has a number of good uses, but, IMHO, not on text-heavy pages. This is basically a PDF wrapped in a wrapper that functions (somewhat) in the MOBI environs.

Now: off to bed, dammit!

Hitch

Do you know that RPN does not stand for what you think it does but in fact means Reverse Polish Notation? See older HP calculators for RPN.

No you can't build a fixed layout Mobi file from any source. You can build a fixed layout KF8.

@Hitch: IMHO, the best format for Bob's purposes would be the Kindle Print Replica textbook format, i.e., an Amazon DRM-wrapped PDF file.

However, AFAIK, you can't publish Kindle Print Replica books via Amazon KDP. (AFAIK, Amazon CreateSpace will accept .pdf files, but only for print-on-demand books.)

Have you ever prepared a Kindle Print Replica textbook for a "well-known educational publisher" or have you ever heard of someone who managed to sell a CreateSpace print-on-demand book as a Kindle Print Replica textbook?

Hi Doitsu,

Thanks for the suggestion, but these Kindle textbooks lack the interactive index that my 2011 book had back in the day when KDP first announced "real page numbers."

I know that the KDP Simplified Formatting Guidelines for Word and Basic HTML Guidelines strongly recommend against, even may demand, no page numbers. And they say do not add an index!

This is unfortunate and speaks badly for the various Amazon formats and is even inconsistent with their section of their KDP guidelines on Page Numbers...

9.3.10 Page Number Guidelines
Kindle books do not always map directly to page numbers in physical editions of the book. Even if the Kindle Real Page Numbers feature is activated in the Go To menu, references within the eBook to page numbers should be handled as follows:

• Table of contents: If there are page numbers in the print source’s TOC, they should be removed in the digital conversion. The name of the section should be retained and hyperlinked to the relevant location in the eBook. For example, if a print source TOC displays the entry “Chapter 1 ... P. 36”, then the eBook should only display “Chapter 1” hyperlinked to the correct digital location.

• Internal links: If there is text that refers to another page in the eBook, such as “see page XX”, this text should be linked to the relevant paragraph within the eBook.

• Index: Every page number in the index should be linked to the relevant paragraph in the eBook (or the relevant illustration, table, or chart).

• Links within index: If there is an entry that references another section of the index, such as “see also XXX”, this text should be linked to the relevant section within the index.

I just went ahead five years ago and added an index (and a working ToC with page numbers, Go to Page in the Go to menu, etc.) to my first book in 2011. And I just did the same for my latest book. Both of these books are linked to the print edition with the same page numbers.

KDP support just told me that they will eventually get around to adding the Real Page Numbers features to my latest book. So go figure!

If anyone would like to see a Kindle MOBI reflowable book with my page numbers, I can "lend" you a copy, according to Amazon.

http://www.amazon.com/Free-Will-Phil...dp/B0055T8XY6/

http://www.amazon.com/Great-Problems.../dp/B01LZPICAL

Jon, sweetie, sitting on my desk--used constantly--is an HP 12C calculator, which, IIRC, is...31 years old, that I bought new, in 85 or so. Possibly a year earlier, but I don't think so. It was the version created for business (y'know, with ROI, payment calculations, amortization scheduling and so on). I'm quite familiar with RPN, and to this day, I have to stop and readjust my brain (and ordering) if I'm going to use a regular calculator. So, yes, I know that RPN stands for Reverse Polish Notation.

How about a compromise, then, so you don't go off on one of your tears? RP#s. Ta-da. Happy now, my resident curmudgeon?

Really? Well, gosh, sweetie, you're killin' me, because we build them here daily. Right there at the end of the filename, it says ".mobi." Can you kindly take this one up with Bezos, Wolfie Quixote, because I'm just all played out on doing battle on 50 different fronts. Thanks. I understand the distinction you are endeavoring to make; however, they kept the .mobi file extension, and that's that.

I'm sorry, I just bloody disagree. Not with your take on it--you are correct there in assessing "if you must have X, then you really have to use Y." It's just...we do a LOT of fixed-layout, compared to the average bear. It's fine for many books. It is, in my opinion, not fine for text-heavy books. To me, it's just not very usable or user-friendly.

Let me put it this way: if the publisher doesn't care about how much inconvenience the end buyer is put through (don't think for a second that Amazon will be that cavalier, however), then fine. Create a "PDF with a wrapper," which as you noted is fundamentally how KPR and KTextbook function. Take a PDF, and wrap it.

They (KPR) are supported on these devices:

• Fire tablets
• Kindle for PC
• Kindle for Mac
• Kindle for iPhone, iPad, & iPod touch
• Kindle for Android
• Kindle for Samsung

And on NO OTHERS.

Yes, we've done this.

For all intents and purposes, KPR is (as you noted, Doits) just like putting a PDF on your Kindle or other eReader, unconverted. You sit there, pan/scan around, use internal nav links. And so on. I cannot imagine having a book on Amazon, that someone has to pinch-zoom, pinch-zoom, flip, pinch-zoom, lather, rinse, repeat, for 400 or so pages. I get uber-irritated when I'm trying to read a PDF on iBooks, never mind trying to suffer through it on my PHONE.

We do this relatively often, BTW, for "coffee-table books." In that environment, I think it works well. (Although, without naming names, we once did a set of books for a certain museum. They were adamant that it just HAD TO BE fixed-layout, because they didn't want to lose the flavor, layout, yadda. They were speechless once we'd complied--of course--and then I sent them the reflowables for ePUB/MOBI. Couldn't believe how gorgeous they were. I'm not trying to be braggadocious; I'm just saying...a little creativity and elbow grease can do wonders in an eBook.)

There is nothing wrong with PDF, on a device, if it's something you're going to check here and there. Or a quick reference, cheat-sheet, etc. But try to read for hundreds of pages, particularly on, say, an iPhone or Droid phone? Moses on a Pony.

However, all that complaining aside, Doits, if Bob or some other publisher is bound and determined to have their pages have "R#s," then, yes, RPN is the only way to do that. Or, to be specific, to do that in a way that is intrinsicand organic to the format.

That's my $.02, FWIW.

Hitch

Bob:

Great--so your issue is resolved then, right? That's terrific. Best of luck with it.

Hitch

You can download KF8 sample files from the Amazon KF8 page.

IMHO, this recommendation makes perfect sense for reflowable Kindle books.

I looked at the Kindle Publishing Guidelines and didn't find recommendations to that effect. AFAIK you can add an index as long as you don't use page number references.

AFAIK, KDP support can only add Real Page Numbers support if the original epub contains page number targets and a page list or a page map.

No argument from my side! I have merely mentioned Kindle Print Replica books for the sake of completeness.