Embedding fonts in AZW3/KF8

[NiLuJe]

@kovidgoyal: Okay, good news: the weird "let's delete the thumbnail" issue I encountered yesterday indeed seems to be a weird caching issue (I was swapping existing books by deleting them from calibre, and reupping the same books in the same session).

If I delete them from the Kindle UI, everything's peachy. (I imagine it would also work correctly If I had deleted them from calibre, unplugged, let the Kindle refresh it's thing, plug, reup).

And it of course works correctly when upping *new* books .

So, it doesn't hurt, the issue I had yesterday was unrelated .

And you were right, the placement has nothing to do with it (and it is indeed quite a mess depending on the KG version, it's even messier with AZW3 files from Amazon, where we usually end up finding an UINT32_MAX in exth 125 or 131, the thumbnails uri sometimes != thumboffset, and we have another copy of the ASIN in exth 504...). Anyyyway...

Good news N°2: It works! If I send a book from Calibre with the no_sync option (so it doesn't get an ASIN), the Kindle properly build its custom thumbnail with the dropshadow, like with KindleGen files. (The file ends up in system/thumbnails like the rest, but with a slightly different name format: thumbnail_XXXXXX.jpg for calibre files, where X is an alphanumeric character, and thumbnail_NNNN.jpg for KG files, where N is a digit).

On the other hand, when there's an ASIN set, we still need Calibre's thumbnail, and that's the one that's used. (If I sideload a calibre built KF8 with an ASIN *outside* of Calibre, it ends up doing the exact same thing as when we sideload an AZW3 straight from Amazon (outside of calibre, still): No thumbnail until/unless Wireless is on, in which case it seems to be downloaded one way or another by the OS... And horribly fails if that's not a proper Amazon ASIN.

[KevinH]

Hi,

Originally Posted by NiLuJe

@kovidgoyal: Happy to help .
On a sidenote: KindleGen seems to use KF8 resources (images/fonts) count (125) / KF8 unknown count (131) the other way around than Calibre... (say, 0 image/fonts & 10 unknown with Kindlegen vs. 10 image/fonts & 0 unkown with Calibre when converting the exact same thing). :?

Actually not quite. EXTH 125 is the number of images/fonts stored immediately after that particular header. So in a joint/dual Mobi, because all of the images and fonts are stored before the BOUNDARY, EXTH 125 in the older-style Mobi header will be their count, but that same EXTH 125 in the newer Mobi8 header (after the BOUNDARY) will be 0.

When an AZW3 is created (it only has one header) EXTH 125 will properly have the count of the images/fonts/resc.

So we are still stuck with not knowing what EXTH - 131 does?

In most cases under the previous version of Kinndlegen this was 0 for both headers but in the latest Kindlegen produced versions, I have seen other values (but still matching in each header) but from my testing these only happen to randomly match the number of fonts/images on occaission and therefore must be a count of something else. I am not sure what.

Also, I do not think EXTH 525 is related to fixed-layout. It appears to be the "TextDirection" instead. So we get "horizontal-lr" to mean text direction is horizontal left to right as opposed to "vertical-rl" which would mean vertical right to left, etc. That is jut a guess but I think an okay one.

I think this has been added to support Japanese ebooks which Amazon is now rolling out.

I will be updating Mobi_Unpack to version 0.53 to add these new EXTH values plus the Language code (524).

Also any idea what EXTH 528 is? I see mainly "true" as its value but I can not see anything in the Kindlegen documentation that supports that. Perhaps they updated the Kindlegen docs when they updated Kindlegen?

I will go and see just in case.

BTW: Very Nice Job with Identifying bit 12 0x1000 as being the bit that indicates embedded fonts or not!

I will add that to Mobi_Unpack as well.

Thanks!

KevinH

[NiLuJe]

@KevinH: Thanks for the details! (Sorry for the delayed response, I was away for a week ).

Nope, no idea on EXTH 131, but I think that's the one where I usually find an UINT32_MAX (4294967295) on AZW3 files from Amazon...

Yup, that makes sense for EXTH 525, I was mostly going from the log ouputs, which might not be related to this exact field .

I'm not sure I actually have something with EXTH 528 set (well, probably, since I found mentions of it it my logs, but I'll have to check)...