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

[pdurrant]

Originally Posted by JSWolf

I would prefer if Mobi_Unpack put in the line endings where they should be even if the original file was garbage.

Though after unpacking a Mobi file, I think it's probably easier to convert to ePub, clean it up, make the changes and convert back.

Since it's a script, you're free to change it, although deciding where line endings 'should be' isn't trivial.

As for the simplest way to fix a Mobi, it depends on how much tweaking you want to do. Personally, I prefer to use MobiUnpack, tweak the code, and then run through KindleGen (& KindleStrip). That way my end result is as close as possible to the original.

[deleyd]

There's a separate program I use to "Beautify" HTML code that comes out all in one line.
http://prettydiff.com/
JavaScript is markup_beauty.js (I think)
which I run using this file named wsh.wsf (I'll attach it here. You'll need to rename it since forum didn't like my .wsf file but accepted a .txt file)

and the command line to run it is:

cscript wsh.wsf /source:"name_of_your_file.html" /html:true

(on Windows)

I'll attach the markup_beauty.js file too. (Again you'll have to rename it from .txt for the same reason.)

I'm not sure if markup_beauty.js relies on other files. If so they are at

http://prettydiff.com/documentation.php

[EDIT: It's not clear that the licences for wsh.wsf and markup_beauty.js allow redistribution. Attachments deleted. They can be download from the page linked above.

The Mods.]

[JSWolf]

Originally Posted by deleyd

There's a separate program I use to "Beautify" HTML code that comes out all in one line.
http://prettydiff.com/
JavaScript is markup_beauty.js (I think)
which I run using this file named wsh.wsf (I'll attach it here. You'll need to rename it since forum didn't like my .wsf file but accepted a .txt file)

and the command line to run it is:

cscript wsh.wsf /source:"name_of_your_file.html" /html:true

(on Windows)

I'll attach the markup_beauty.js file too. (Again you'll have to rename it from .txt for the same reason.)

I'm not sure if markup_beauty.js relies on other files. If so they are at

http://prettydiff.com/documentation.php

Thanks. But now I have an error...

E:\E-Books\Sorted\Kindle\wsh.wsf(292, 18) Microsoft JScript runtime error: 'undefined' is null or not an object

Any idea what to do to fix this?

[deleyd]

OK I gave it a test and found I need three files:

• markup_beauty.js
• markupmin.js
• wsh.wsf

All available from the website prettydiff.com

Then I used the command:

cscript wsh.wsf /source:"Hello.htm" /html:true > "HelloPretty.htm"

[Doitsu]

Originally Posted by pdurrant

Since it's a script, you're free to change it, although deciding where line endings 'should be' isn't trivial.

How about globally replacing >< with >\n< (i.e. inserting line-breaks between a sequence of closing and opening angle brackets? It's not a perfect solution, but it'd definitely improve the readability of the .html file.

@deleyd
I tested the prettydiff scripts and noticed that there seems to be a problem with accented characters, which are garbled in the output file. (English text should be fine, though.)
Babelpad also reported an error message when I tried to open the output file, which is usually an indicator of invalid Unicode sequences in a file.

[pdurrant]

Originally Posted by Doitsu

How about globally replacing >< with >\n< (i.e. inserting line-breaks between a sequence of closing and opening angle brackets? It's not a perfect solution, but it'd definitely improve the readability of the .html file.

I do just that in my text editor. I think it's best for the mobiunpack to do as little massaging of the HTML as possible.

[Jellby]

That might alter the meaning if the two consecutive brackets belong to inline tags, since the inserted linebreak equals a space.

I would insert a linebreak only before "<h", "<p" or "<div", for instance.

[pdurrant]

Originally Posted by Jellby

That might alter the meaning if the two consecutive brackets belong to inline tags, since the inserted linebreak equals a space.

I would insert a linebreak only before "<h", "<p" or "<div", for instance.

Good point.

[JSWolf]

Originally Posted by Jellby

That might alter the meaning if the two consecutive brackets belong to inline tags, since the inserted linebreak equals a space.

I would insert a linebreak only before "<h", "<p" or "<div", for instance.

You also could put a line end at </p> </h#> </div> and any other </ that's should be at the end of a line. Both ways would give most lines correctly separated.

[DiapDealer]

Both ways would give most lines correctly separated.

Tiny adjustment.

[JSWolf]

Originally Posted by DiapDealer

Tiny adjustment.

Regardless of how it's said, it would work and work well.

[dilo_sec]

I use a binary search (for "<p") and replace (with "\x0d\x0a<p") to prepare one-lined html files for viewing/correcting/editing in my favorite editor.

Originally Posted by Doitsu

I tested the prettydiff scripts and noticed that there seems to be a problem with accented characters, which are garbled in the output file. (English text should be fine, though.)

I've also had issues with ascii/unicode/utf-8 characters not being preserved across edits and producing the ebook - I now convert all utf-8 codes to html codes (e.g. e2809c and e2809d to &ldquo; and &rdquo; or c3a9 to &eacute; ) - it makes the html source a little bit harder to proofread.

[nleblanc88]

Has anybody had any trouble with the book covers? Upon unpacking a mobi file and packing it back using Kindlegen, the book cover is getting lost. Looking at the unpacked files, the cover is properly being extracted. Kindlegen is also throwing a warning saying no cover found.

I've had this problem on a few books now. Anybody have any ideas as to what could be going on?

[DiapDealer]

Originally Posted by nleblanc88

Has anybody had any trouble with the book covers? Upon unpacking a mobi file and packing it back using Kindlegen, the book cover is getting lost. Looking at the unpacked files, the cover is properly being extracted. Kindlegen is also throwing a warning saying no cover found.

I've had this problem on a few books now. Anybody have any ideas as to what could be going on?

The OPF file is what tells Kindlegen what/where the cover image is (as well as the inline ToC, the NCX file and the Start Reading point). When you say "packing it back using Kindlegen," I assume you're feeding the unpacked OPF file to Kindlegen. That's what you should be doing. If you're simply supplying the html file to Kindlegen, that would explain why there's no cover (or ToC, or other features).

[nleblanc88]

Originally Posted by DiapDealer

The OPF file is what tells Kindlegen what/where the cover image is (as well as the inline ToC, the NCX file and the Start Reading point). When you say "packing it back using Kindlegen," I assume you're feeding the unpacked OPF file to Kindlegen. That's what you should be doing. If you're simply supplying the html file to Kindlegen, that would explain why there's no cover (or ToC, or other features).

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.