Quote:
Originally Posted by NullNix
That makes it sound much smarter than it is. The design is clearly aimed at sheer implementation simplicity over everything else. A single location value is 128 bytes long, with a new location starting at every offset through the book's text divisible by 128 bytes (not Unicode codepoints, not characters-not-counting-spaces, bytes): in MOBI and AZW this counts the (invisible) markup, in KFX it seemingly does not (so you can get different location counts and total lengths by switching from a AZW to a KFX version of the same book. As an aside, I wonder if this suggests that in KFX the markup is out-of-band somehow and points into the text from "outside", and both location implementations are just counting bytes in a byte stream).
|
That is not quite true. There are two ways that content is referenced in Kindle formats, "locations" and "positions".
Position numbers each refer to a single exact point within the e-book content. Each Kindle format has its own way of handling positions. For MOBI and KF8 formats position numbers count bytes of raw HTML content. For KFX position numbers count Unicode characters of visible text. For a single book the same position number will refer to different content depending of the format in which it was delivered.
Locations refer to an approximate place within the e-book content, independent of the actual Kindle format in which the book was delivered. Each location occupies 150 bytes of the raw html of the book in MOBI format. So each location occupies 150 positions in MOBI. That was the original simple implementation of locations.
The newer Kindle formats use mapping tables that translate between location and position numbers so that each location points to the same place within the book as it does in MOBI format. The position number corresponding to each location will be different for each Kindle format.