[Tex2002ans]

Originally Posted by ApK

Thinking about how frustrated I get when I type a whole two paragraphs and then lose it with an accidental keystroke, please tell me you compose in some other editor and then just paste all that into a forum message, right?

Yeah, I type everything up in Notepad++, and type it throughout the day over a few hours. Most of the time I just revisit the tab over the course of a day, and then continually reread/expand/rewrite it.

Then after I post, there is always a period of "oh crap, I could have said that better" or "oh crap, I forgot to discuss this little thing", so I reread/reedit the post for about an hour (if you take a look at the times, you can see I posted that last one at 06:37AM and didn't finish editing it until 08:14AM ).

I don't mind spending much time on these larger, more informative posts, because I find they are helpful... and if it doesn't help anyone else, I can always just reference it for myself in the future.

Originally Posted by Solitaire1

I usually just compose my posts within the reply window and then post it to the thread. I've not had a problem doing that but I have considered writing my long posts in my word processor and then copying and pasting it to the reply window since the forum sometimes times out before I can put my post on the forum.

I have lost too many posts over the years to typing directly into forum reply boxes, so now I make sure I save the text document, and copy/paste.

I used to post detailed debates on an old forum, and their server used to go down quite often (and it would eat your posts), so I got in the habit of keeping a copy saved for a few days just in case. And back then I used to write baby-sized posts.

Originally Posted by Solitaire1

Would a viable option be to include a marker (say a vertical bar on a line by itself) to indicate the top of a page, with everything between the bars considered one page regardless of the amount of text it contains (determined by the ebook formatting team)?

Something similar happens when you mark up your text with a page-map/page list file in certain readers (AZARDI for example).

In AZARDI, the page numbers could appear in the book along these lines (according to user preferences):

http://www.infogridpacific.com/blog/...ak2_online.png
http://www.infogridpacific.com/blog/...ak3_online.png

or potentially you can view page numbers in an alternate format like this:

http://www.infogridpacific.com/blog/...nav_online.png

It is up to the device/reader software to support this type of stuff (and then the people creating the files to insert the code... which we covered, is a giant pain in the ass to do).

And you have to think of the really hard edge cases.

One that comes to mind is footnotes in the physical book that reflow over multiple pages. There is no good way to mark this up properly in an ebook. In the ebook you may know that "Footnote 10 began on page 324", but you would have no clue that in the physical (hardcover) of the book, the footnote also travelled across the bottom of pages 325-326.

Or another one might be Newspaper or Magazine material where they may have multiple articles on a single page, and then the article splits and says "(Continued on Page A3)". It would be absolute MADNESS trying to force those spaghetti nest of page numbers onto the ebook.

Originally Posted by JSWolf

That is 100% incorrect that the file may change. The file is as it is unless it's changed by you. When have you ever had an eBook change without you changing it either downloading a newer version or making the changes yourself?

I thought I was clearer with a few examples at the very end of that last post under "Pitfall of Byte Counts", but perhaps not.

Let me add one more potential case of the actual backend code of the book changing:

A lot of the ebooks that I work on is cleaning up crappily converted EPUBs. I will go through and fix OCR errors, correct footnotes, change hideous JPGs of Greek letters to actual Unicode Greek characters, digitize formulas, change images of Tables -> HTML versions, clean the code itself in the backend, [...].

Then we (as publishers) rerelease an updated "version 2.0" of the ebook.

Depending on how extensive the code fixes are, you can imagine that this could drastically change the size of the HTML files (and would throw off the Byte Method page numbering).

As a real life example, back in 2013 I worked on The Great Austrian Economists by Randall Holcolmbe (Before/After pictures + some discussion posted here):

https://www.mobileread.com/forums/sho...06#post2672206

Here is a single set of example images if you are too lazy to click on the link:

Original PDF Scan: https://www.mobileread.com/forums/att...0&d=1383241259
Old EPUB: https://www.mobileread.com/forums/att...1&d=1383241259
New EPUB: https://www.mobileread.com/forums/att...5&d=1383241264

I just took a look at one of the largest EPUB redo projects I ever handled, and the ADE "pages" went from 3627 "pages" (Before) -> 3614 "pages" (After), just from the sheer amount of code cleanup + corrections. I also ran it through KindleGen and it went from 73190 "locations" (Before) -> 71266 "locations" (After).

I also tested the first version of A Dance With Dragons that I purchased from B&N, and it was 1100 ADE "pages", the later version was 1101 ADE "pages". Most of what changed was minor typo corrections + different code for lists (went from <li> to using <div>).

You can probably extrapolate the hideous InDesign/Quark code cleanup (I don't feel like hunting down one of those books right now), but you can see from my Example #1-#3 above how the Kindle "locations" could easily be thrown off (and ADE's algorithm too, although not as wildly).

In the future, maybe a lot of other ebooks will be changing images of formulas to MathML... that is also going to throw off the Byte Method of page numbers.

Originally Posted by eschwartz

You could have Amazon set to automatically update books when the publisher pushes a new version.

Or the simple fact that most people associate books with the words in them, not the specific file that contains them.

That is what I was trying to write... but perhaps I was trying to explain it too technically.