[GUI Plugin] KindleUnpack - The Plugin

[Thorns]

Originally Posted by jhowell

That error is most likely the result of a change to the array module in Python:




Added: I changed the name of that function in KindleUnpack and was able to unpack that dictionary without any further errors. I have attached a copy of the modified plugin in case anyone else needs to use it.

Hi, just wanted to say I had the exact same error and used this plugin which allowed me to extract the dictionary and use the mobi to startdict python script which allowed the dictionary to go straight to the KOreader. Many thanks for posting this!

[DiapDealer]

Updated the first post with version 0.83.7. Pulled in the latest changes from upstream (the standalone KindleUnpack), eliminated some warnings being generated and made sure the plugin would work with Python 3.13+

Note: v0.83.7 includes an upstream fix for the array module's tostring() method being renamed to tobytes() that jhowell kindly released a fix for in post #491.

[JSWolf]

I've found what I consider to be a bug.

Can we have the cover HTML be the first file in the manifest given that's how the cover is displayed with ePub? As it is, the cover is the last file in the list instead of being the first.

[DNSB]

Originally Posted by JSWolf

I've found what I consider to be a bug.

Can we have the cover HTML be the first file in the manifest given that's how the cover is displayed with ePub? As it is, the cover is the last file in the list instead of being the first.

What are you talking about? The cover image in the manifest is flagged with 'properties="cover-image"'. If no file with that property exists in the manifest, the first file in the ePub is used as the cover image.

[JSWolf]

Originally Posted by DNSB

What are you talking about? The cover image in the manifest is flagged with 'properties="cover-image"'. If no file with that property exists in the manifest, the first file in the ePub is used as the cover image.

I would prefer to have the files in the order they will be displayed. That means the cover HTML is first and not last.

[DNSB]

Originally Posted by JSWolf

I would prefer to have the files in the order they will be displayed. That means the cover HTML is first and not last.

Since the .opf file is not intended for human use, your desire to have the file list in order is a trifle risible at best and a fine example of OCD at worst. Have you used calibre's editor to look at the .opf file in a KF8 file?

Do you also realize that you are confounding an image file (i.e. cover.jpeg) with a HTML file (i.e. titlepage.xhtml)? The HTML file can not be given a cover-image property.

IMNSHO, I don't care what order the files are listed in the .opf file as long as the semantics are correct.

[JSWolf]

Originally Posted by DNSB

Since the .opf file is not intended for human use, your desire to have the file list in order is a trifle risible at best and a fine example of OCD at worst. Have you used calibre's editor to look at the .opf file in a KF8 file?

Do you also realize that you are confounding an image file (i.e. cover.jpeg) with a HTML file (i.e. titlepage.xhtml)? The HTML file can not be given a cover-image property.

IMNSHO, I don't care what order the files are listed in the .opf file as long as the semantics are correct.

I see the OPF file on every eBook. So it would be better to have the cover HTML first instead of last. I know it works and the cover is displayed, but that's not the point.

[DNSB]

As do I. OTOH, I am not asking for purely cosmetic changes in a file that is not intended for human use and that will have no effect on reading the ebook.

I think it's time to move this discussion elsewhere.

[DiapDealer]

Originally Posted by JSWolf

I've found what I consider to be a bug.

Can we have the cover HTML be the first file in the manifest given that's how the cover is displayed with ePub? As it is, the cover is the last file in the list instead of being the first.

Only you would present what amounts to a frivolous feature request as a bug.

The answer is no. Drop this nonsense, or I'll drop it for you.

Moderator Notice
The End

[texasnightowl]

I only recently added this plugin to Calibre. Simple question...should I be converting to epub2 or epub3? (I did try searching the thread using the term epub3 but didn't seem to see anything...but it may not have been obvious in the results.)

[DNSB]

My personal choice is Auto-detect. If KindleUnpack detects that the file was generated by an ePub3, the output will be ePub3. Otherwise, it defaults to ePub2.

[texasnightowl]

Originally Posted by DNSB

My personal choice is Auto-detect. If KindleUnpack detects that the file was generated by an ePub3, the output will be ePub3. Otherwise, it defaults to ePub2.

ah! ok! thanks! that is good to know!

[ayrlin]

All azw files are showing 'Unpack azw' as greyed out, can you offer any help?

[DiapDealer]

Originally Posted by ayrlin

All azw files are showing 'Unpack azw' as greyed out, can you offer any help?

That typically only happens when your files still have DRM (or the book has no kindle format). KindleUnpack only works on Kindlebooks that are already DRM-Free.

[m_pluto]

Feature request: With the new kepub support in calibre 8.0 release, would it be possible to add an option to add a kf8/azw3 unpack to kepubs in addition to the kf8/azw3 to epub?