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

[pdurrant]

Originally Posted by nleblanc88

Nope, thats what I'm doing. The OPF file looks like this:

<meta name="EmbeddedCover" content="images/image00002.jpeg" />

When I compile it with Kindlgen, it gives me the following:

Warning(prcgen):W14016: Cover not specified

.

Other files have no mention of the cover in the OPF file, yet the original mobi file contains a cover which is being displayed properly in the reader.

It sounds like one of the recent updates has messed up the cover metadata. I'll take a look.

[DiapDealer]

I think it might actually be changes to Kindlegen that have broken the cover functionality. I don't think the EmbeddedCover meta-tag is valid any more.

The following quick mods (attached patch) to the mobi_opf.py file seems to get the cover functionality going again for unpacked MOBI6/7 files fed right back to the latest versions of Kindlegen ... but it's only intended as proof of concept, and could very well break something else.

Basically, instead of the EmbeddedCover meta tag pointing directly to the cover image file, it (Kindlegen) is expecting the format of:

<meta name="cover" content="cover_img" />

and then the standard matching, manifested image file in the spine:

<item id="cover_img" media-type="image/jpeg" href="images/image00001.jpeg" />

That might actually simplify some of the MOBI/KF8 logic in the mobi_opf.py file, I should think.

[pdurrant]

Originally Posted by DiapDealer

I think it might actually be changes to Kindlegen that have broken the cover functionality. I don't think the EmbeddedCover meta-tag is valid any more.

No, what's happened is that at some point the EmbeddedCover tag has been generated incorrectly. It ought to look like

<x-metadata><EmbeddedCover>Cove Image Name.jpg</EmbeddedCover></x-metadata>

And if changed to that, KindleGen handles it fine.

But that's unofficial support left over from Mobipocket Generator.

I think it's probably best if we drop support for Mobipocket Generator, and tweak things to work only with KindleGen.

There's another problem too - we're including the thumbnumber cover image in the manifest, which causes a cycle of Mobiunpack/Kindlegen to add an extra image - a new thumbnail each time.

Whether this is because the metadata is declared incorrectly, or because KindleGen can't handle being given an explicit thumbail image I'm not sure.

There's also a problem of empty anchors not being removed well enough, causing extra empty anchors to be added on each cycle through as well.

I'll work on a fix for all this over the weekend.

[DaleDe]

you might want to archive and mark the last version with Mobipocket Creator support.

Dale

[pdurrant]

Originally Posted by DaleDe

you might want to archive and mark the last version with Mobipocket Creator support.

Dale

A good point. I should have a copy here somewhere.

[pdurrant]

Version 0.52 now uploaded to the first post in this thread.
I've also uploaded the last "unified" version, 0.32, which was just before KF8 support got added, and Mobipocket Creator support got broken.

[KevinH]

Hi Paul,

I have added support for the new metadata items being used in the very latest version of Kindlegen as well as a fix for splitting joint mobis, that did not properly handle the header flag bit 12 (0x1000) which was recently found to indicate the presence of embedded fonts or not (see the Calibre thread on AZW3 and embedded fonts on KT).

Here is the Mobi_unpack_v053.zip. If you get a free moment would you update your first post with it.

Thanks,

KevinH

[pdurrant]

Originally Posted by KevinH

If you get a free moment would you update your first post with it.

Done. I've also updated the AppleScript.

[amarie0]

Paul, when I click either the python or the applescript link in the first post, I get an alert message "Invalid Attachment specified. If you followed a valid link, please notify the administrator"

That's where you've posted the latest versions, is that right?

[JSWolf]

Originally Posted by KevinH

Hi Paul,

I have added support for the new metadata items being used in the very latest version of Kindlegen as well as a fix for splitting joint mobis, that did not properly handle the header flag bit 12 (0x1000) which was recently found to indicate the presence of embedded fonts or not (see the Calibre thread on AZW3 and embedded fonts on KT).

Here is the Mobi_unpack_v053.zip. If you get a free moment would you update your first post with it.

Thanks,

KevinH

I've encountered a bug in the new version. The ePub it created from an Amazon downloaded KF8 (with embedded fonts) is invalid.

The problem is thus...

<dc:publisher>Simon & Schuster, Inc.</dc:publisher>

should have been converted to...

<dc:publisher>Simon &amp; Schuster, Inc.</dc:publisher>

After that is done, ADE does open the ePub even though there are still a few errors that are easily fixed.

[pdurrant]

Originally Posted by amarie0

Paul, when I click either the python or the applescript link in the first post, I get an alert message "Invalid Attachment specified. If you followed a valid link, please notify the administrator"

That's where you've posted the latest versions, is that right?

Whoops. Changed the attachments, but forgot to change the links in the post. Now fixed.

[pdurrant]

Originally Posted by JSWolf

IThe problem is thus...

<dc:publisher>Simon & Schuster, Inc.</dc:publisher>

should have been converted to...

<dc:publisher>Simon &amp; Schuster, Inc.</dc:publisher>

Thanks, Jon. it seems we should be making sure text is escaped, and we're not.

[JSWolf]

Originally Posted by pdurrant

Thanks, Jon. it seems we should be making sure text is escaped, and we're not.

Happy to help. Looking forward to 054.

[DiapDealer]

I made some modifications to two of the files in Mobi_Unpack: "mobi_unpack.py" and "mobi_opf.py".

The change to mobi_unpack.py is due to at least one report of complete failure because a font couldn't be properly extracted. I added some error-handling to accommodate the occasional wonky font without causing the entire process to bomb.

The change to mobi_opf.py is to simply entity escape the KF8 metadata so the resulting OPF is valid when the occasional special character is encountered (RE: Jon's next-to-last post).

@Pdurrant: if you (or anybody) wants to check it out and see if it makes sense... I've advanced the version to 0.54 if you want to update the first post. Feel free to change it all up (or ignore) if you have different plans or see a better way to accomplish the same goals.

Thanks!

[pdurrant]

Originally Posted by DiapDealer

@Pdurrant: if you (or anybody) wants to check it out and see if it makes sense... I've advanced the version to 0.54 if you want to update the first post. Feel free to change it all up (or ignore) if you have different plans or see a better way to accomplish the same goals.

Thanks!

It looks good to me. First post updated.