Thank you jhowell for responding, I really appreciate it.
Quote:
Originally Posted by jhowell
Yes. But it is an offset into the unpacked raw HTML content of the MOBI.
|
What I'm not sure about is, I don't have much experience with MOBI but with EPUB for example when I've unpacked them I've noticed that they sometimes (often? always?) contain multiple HTML files. If that can be true for MOBI as well, and you say that this is an offset into the unpacked raw HTML, then that implies that there is some defined order so that it is well-define where an offset enters into if it goes past the "first" file (not to mention it would also determine what the first file would be), does that make sense? If so, what determines this order? Would it be some metadata file contained within the MOBI that defines the book-order of the pages, which is itself the order of the files that the offset offsets into?
Put another way, if the offset is 700 but the "first file" (again, I'd need to know what the first file even is) only goes up to 500, then I'd need to know what second file to offset 200 into, correct? What defines that order?
Also, just to be sure, you're saying that a Kindle "Position"
is just that "raw byte offset" right? So using the formula mentioned in this thread I could go from that raw byte offset to a Kindle "Location" and vice versa.
I suppose that if the location I arrive at is not exact, I can at least use it to determine what html file to search for the highlighted text within/around so as to drastically reduce the search space.
Thanks for the link to that thread! It definitely seems useful.