View Single Post
Old 01-25-2012, 01:41 PM   #5
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,804
Karma: 6000000
Join Date: Nov 2009
Device: many
Hi,

I wrote a small bash script to caputre the old mobi and separate mobi8 pieces while running kindlegen just to see what they look like.

There are no images or fonts at all in the .mobi8 piece. There are references to them but they are not included. The .mobi8 is literally simply appended to the end of the original mobi after removing the end of section and adding a BOUNDARY section with no changes from what I can see.

So all of the smarts are in the part that creates the old mobi piece as it has to now collect all images and fonts and store those in the right (and known order) so that the mobi8 piece can be simply appended.

If we could determine the exact order of these resources that would help. For example: Do fonts always come first, are images intermixed with other non-image sections, what order do the FCIS, FLIS, DATP, FDST come in, does the content.opf determine the order of resources files like images and fonts or does something else.

If we knew all that then it might be possible to create a stub for the old mobi section.

I was kind of hoping the .mobi8 piece you described would be standalone and we could learn what a standalone mobi KF8 might look like, but instead it relies on all of those resources being stored in known sections in the older mobi part.

Perhaps if someone played around with the order of images in the content.opf and then looked at how they were stored in the old mobi, we could figure out what algorithm they used. If they instead the parse the html to determine order and links and things, it will be a lot harder and possibly impossible if you want images in different order between the old and the new sides.
KevinH is offline   Reply With Quote