KindleUnpack (MobiUnpack): Extracts text, images and metadata from Kindle/Mobi files

[wallcraft]

Originally Posted by ATimson

I think the "problem" here is that the Kindle app will display the cover image specified in the cover <meta> tag when you open a book. With an ePub, you need to specifically include a separate HTML page with the cover in the spine in order for it to appear when you open the book in most readers.

That said, my understanding of ePub cover best practices is that you shouldn't be showing the cover when you open the book - tell the reading software how to find the cover, but let it decide whether or not to display it.

What the threepress link says is:

Ensuring the widest interoperability for your cover means including an XHTML cover page (as the first “flow”), a cover image, and bits of OPF metadata to refer to these items using consistent names.

Which agrees with your original point, that for an ePub the "cover" needs to be the first item in the flow. When Calibre converts a MOBI to ePub, for example, the MOBI cover is put on the 1st page of the ePub.

[ATimson]

Originally Posted by wallcraft

Which agrees with your original point, that for an ePub the "cover" needs to be the first item in the flow.

Yes, but they also set linear="no". Which means that ADE will see it & pull a cover from it, but you won't actually see it when you open the book - which wouldn't address jhowell's complaint.

[Jellby]

Originally Posted by ATimson

Yes, but they also set linear="no". Which means that ADE will see it & pull a cover from it, but you won't actually see it when you open the book - which wouldn't address jhowell's complaint.

Which means that ADE could do it (not show it when you open the book), but as far as I know, ADE just ignores linear="no", i.e., it displays it as anything else.

[DiapDealer]

To be fair, I think if Mobi_Unpack were to generate an initial (manifested) XHTML page with the cover image in it, it would be making assumptions about the original source that it couldn't possibly know. The only thing certain that can be ascertained from reading ePub specs is that there is no official way to handle cover images/pages in an ePub. So the bare minimum of properly manifesting the image and adding the <meta name="cover" content="blah"/> tag seems appropriate to me, in this light.

[jhowell]

I agree that it would not be appropriate for an unpack tool to generate new xhtml for the cover and handling it via metadata is the most sensible thing to do. That said, the full-size cover images in the KF8 files I have unpacked to EPUB are manifested, but not explicitly indicated as being a cover in the OPF. I suggest adding a name=”cover” meta tag (as per Amazon) and/or cover-image property (as per EPUB-3).

ETA: Ooops, my bad.. The cover meta tag IS present in the unpacked files. Never mind.

[xxy]

Great job, Kevin. It's just getting better and better. I have previously generated a mobi file with embedded fonts using kindlegen 2.4. Now there seems a problem after unpacking and splitting into a mobi7 and a azw3 (KF8) file. The azw3 file can be opened by Kindle Touch but there's no embedded fonts any more. It might due to the lack of declaration of the fonts information in the manifest section of opf, I guess.

[KevinH]

Hi,

Simply run Mobi_Unpack on the split .azw3 file and examine the Log to see if the fonts were properly included or not. Perhaps the fonts were encrypted? Either way, unpack it and look to see what is up. If there is a bug, let me know here.

ps.
I can not recreate this issue ... I have tried it with various kindlgen generated sample files that have fonts and all of the fonts were properly included in the split version of the file.

So I need more here if you wan to get this bug fixed.

Originally Posted by xxy

Great job, Kevin. It's just getting better and better. I have previously generated a mobi file with embedded fonts using kindlegen 2.4. Now there seems a problem after unpacking and splitting into a mobi7 and a azw3 (KF8) file. The azw3 file can be opened by Kindle Touch but there's no embedded fonts any more. It might due to the lack of declaration of the fonts information in the manifest section of opf, I guess.

[KevinH]

Hi All,

Here is Mobi_Unpack_v050 which is a pure bug fix release. Both bugs were detected and fixed by Kovid (Thank you Kovid)

- fixed bug with unreliable decoding of zlib header by letting zlib handle it

- fixed bug with images stored in urls in the style= attributes in tags in the main xhtml files

Please post any bug reports here.

Hope this helps,

KevinH

[xxy]

Originally Posted by KevinH

Hi,

Simply run Mobi_Unpack on the split .azw3 file and examine the Log to see if the fonts were properly included or not. Perhaps the fonts were encrypted? Either way, unpack it and look to see what is up. If there is a bug, let me know here.

ps.
I can not recreate this issue ... I have tried it with various kindlgen generated sample files that have fonts and all of the fonts were properly included in the split version of the file.

So I need more here if you wan to get this bug fixed.

Thank you for your prompt reply. I have tried to unpack the split .azw3 file and found, just as I presumed, the fonts are included but no references in the .opf file. (I have also tried the newly released 0.50. Same thing).

Curiously enough, if you check one step back, the .opf in the mobi8 folder is perfectly right (with fonts references and everything) when unpacking and splitting the original mobi. So I think this is a fixable bug.

To make your debug easier, I will upload a test mobi file later on. Thanks again.

[DiapDealer]

I've created several combination MOBI/KF8 ebooks containing embedded fonts using kindlegen, and the azw3 file produced with Mobi_Unpack's splitter utility always performs exactly as expected. The embedded fonts work fine in the .azw3 files (just as they did in their respective combo file). Unpacking those .azw3 files results in ePubs in which the fonts are properly manifested in the OPF, and the embedded fonts are displayed properly when using ADE.

If you do upload a test file, be sure to upload a kindlegen-produced, combination MOBI in which embedded fonts are working the way they should (in the KF8 portion) before splitting.

[xxy]

Attached are the original .mobi file and the split .azw3 file.
mobi8-content_nodrm.azw3.zip
Please also check the 2 pictures captured from my Kindle Touch screen and you will know what the problem is.

[DiapDealer]

I couldn't say what might be going on with your Touch, but I assure you that the AZW3 file you uploaded has working embedded fonts and unpacking that same AZW3 file shows that the font-files are indeed properly manifested in the OPF file. The embedded fonts work as they should in the KindlePreviewer (and the Kindle for PC app), but perhaps there is something different about the Touch.

See if giving the file an AZW or MOBI extension (instead of AZW3) makes any difference.

[xxy]

Thanks. I have re-checked the .opf unpacked from .azw3 and the fonts information ARE there. My bad, sorry about that. Looks like it's a Kindle Touch rendering problem now. Let's wait for Amazon's next firmware update then.

[jhowell]

I’m not sure what tool produced or manipulated it, but I recently came across a mobi7 file that contains several FONT sections with no data in them. This book is viewable in Calibre and Amazon applications, but caused mobi-unpack to fail. I mention this as a “heads up” in case others come across this sort of malformed file.

FYI: The error occurs in the struct.unpack_from call following elif type == "FONT" in mobi_unpack.py. I patched my copy to skip it if the data length is too short.

[xxy]

Looks like it's not only a problem with the sideloaded "homemade" KF8 files, but also the purchased "legal" ones (https://www.mobileread.com/forums/sho...d.php?t=175999) on the Kindle Touch. Amazon really needs to address this issue sooner.