Yeah, I type everything up in Notepad++, and type it throughout the day over a few hours. Sometimes 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.
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.
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 devices/reader software to support this type of stuff (and then the people creating the files to insert the code... which we covered, is a slight 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. 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.
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 are 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 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" (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).
That is where I was trying to write... but perhaps I was trying to explain it too technically.
