Hi,
I have one other test case that has multiple css sheets and svg pieces and that grows the number of flow items and therefore the fdst count.
I will check to see what it puts for those 4 bytes in the older mobi header, to see if it clears up anything.
KevinH
Quote:
Originally Posted by nickredding
Kevin - I just looked at 2 different KF8 files and you are correct (I wondered why "first_content_index" in the KF8 header was zero instead of 1). For KF8 headers 0xC0 is an >L indicating the FDST record number and 0xC4 is an >L indicating the number of sections in the FDST record. I guess the kindle previewer and Fire just don't need first_content_index, assuming it's 1.
Quite strange that Amazon is formatting the header differently for KF8--most software people would agree that's a dumb thing to do because it's error-prone.
One thing that's still not clear is what (if any) is the significance of the >L at 0xC4 in the mobi7 header? There is no doubt that for these headers the first and last content indexes are two >H starting at 0xC0 but the following 4 bytes are 0x1 for a kindlegen2-generated file and 0x2 for Jerome.prc.
Do you want to fix the mobi-split code or shall I?
|