Thread: Embedding fonts in AZW3/KF8
View Single Post
Old 07-16-2012, 05:02 PM   #47
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,810
Karma: 6000000
Join Date: Nov 2009
Device: many
Hi,

Quote:
Originally Posted by NiLuJe View Post
@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
KevinH is online now   Reply With Quote