[Plugin] KindleImport Sigil plugin

[KevinH]

Hi JSWolf,

I decided it was better to fix this in mobi_header.py alongside where we fixed the same problem with CoverOffset values.

So I have attached a new mobi_header.py.zip. Use it to replace its namesake in kindleunpack/lib/ inside KindleImport and in KindleUnpack_v0.75/lib/ as well. Be careful to zip up the KindleImport zip exactly as it had been so that it still works as a plugin.

If it works, please let me know and I will add it for the next KindleUnpack release.

Thanks,

Kevin

Originally Posted by JSWolf

Yes, you are correct about ThumbOffset being 0xffffffff. I'm ready to run your test version of mobi_opf.py when you are ready to get it to me.

[JSWolf]

OK, I've tried the test version of mobi_header.py and it didn't work. Different error this time.

Status: failed

Traceback (most recent call last):
  File "C:\Program Files\Sigil\plugin_launchers\\python\launcher.py", line 137, in launch
    self.exitcode = target_script.run(container)
  File "C:\Users\Jon\AppData\Local\sigil-ebook\sigil\plugins\KindleImport\plugin.py", line 113, in run
    epub = qe.makeEPUB()
  File "C:\Users\Jon\AppData\Local\sigil-ebook\sigil\plugins\KindleImport\quickepub.py", line 51, in makeEPUB
    xhtmlstr, css, cssname = ml2html.processml()
  File "C:\Users\Jon\AppData\Local\sigil-ebook\sigil\plugins\KindleImport\mobiml2xhtml.py", line 219, in processml
    htmlstr += self.processtag(taginfo)
  File "C:\Users\Jon\AppData\Local\sigil-ebook\sigil\plugins\KindleImport\mobiml2xhtml.py", line 445, in processtag
    styles.append('font-size: %s' % size_to_em_map[sz])
KeyError: 'normal'
Error: 'normal'

[DiapDealer]

Actually, it looks like Kevin's fix worked on the KindleUnpack side of things. Your new error is squarely back in the hands of my KindleImport plugin. I'll try to take a peek tomorrow. I know I should stop being surprised by what finds its way into mobi markup, but ... dang! A font size attribute value of "normal"? That's a new one on me.

[poxalew]

Ugh. It's most likely produced by CSS flattening tools--I've seen many big-name publisher stylesheets sporting "font-size: normal;" stanzas. And since some seem to run a preprocessor on the source markup before feeding it to kindlegen, it infects the output as well. kindlegen does warn about this, but allows it through regardless, and people ignore warnings when they seem to cause no ill effects at first. Arguably a kindlegen bug, but, well...

Incidentally, you might want to prepare yourself for "vertical-align: sup" instead of "super" as well

[DiapDealer]

Originally Posted by poxalew

Incidentally, you might want to prepare yourself for "vertical-align: sup" instead of "super" as well

"Invalid" attributes won't disturb me that much, most of the time. That one won't "break" the import.

I'm not trying to fix everything prior to opening in Sigil. But the <font> tags (in mobi-only, html 3.2ish markup) were one thing I wanted to try to "fix up" (since it's so prevalent). I'll just have to make allowances for size attribute values other than [+/-]1-7, and x[x[x]]-small|medium|large.

Getting some of those messy mobis (non-KF8) open in Sigil isn't going to be doing users any huge favors in some cases. They're still going to have their work cut out for them getting them cleaned up.

[DiapDealer]

@KevinH

Unrelated to (and regardless of) what I decide to do for the newly opened epub's temporary name, I think we need to examine KindleUnpack's file naming methods for mobi-only kindlebooks. We're technically creating invalid OPF/NCX files whenever the original file name has an ampersand in it. Which means I'm, in turn, creating an invalid container.xml file when trying to man-handle KindleUnpack's output into an epub structure with this plugin.

It's either that, or I need to sanitize all filenames with my plugin (when unpacking mobi-only kindlebooks) and replace all references to them in all the KindelUnpack-produced files with those sanitized versions. A thought I don't really relish, needless to say.

The KF8 portions of Kindlebooks, don't suffer this file naming "problem."

[KevinH]

Hi DiapDealer's,

Yes, I am never a fan of using titles as file names because of all that nonsense. I will go grab a file name sanitizer routine. Also, I agree with you in changing the base name of the file to match what we do with KF8 to prevent these difficulties in the first place.

Feel free to fix those in KindleUnpack any way you like (as well as any other related changes you need) and I will add them to the next KindleUnpack release to keep things in sync.

Thanks,

KevinH

Originally Posted by DiapDealer

@KevinH

Unrelated to (and regardless of) what I decide to do for the newly opened epub's temporary name, I think we need to examine KindleUnpack's file naming methods for mobi-only kindlebooks. We're technically creating invalid OPF/NCX files whenever the original file name has an ampersand in it. Which means I'm, in turn, creating an invalid container.xml file when trying to man-handle KindleUnpack's output into an epub structure with this plugin.

It's either that, or I need to sanitize all filenames with my plugin (when unpacking mobi-only kindlebooks) and replace all references to them in all the KindelUnpack-produced files with those sanitized versions. A thought I don't really relish, needless to say.

The KF8 portions of Kindlebooks, don't suffer this file naming "problem."

[varlog]

Originally Posted by KevinH

You do realize that you are talking about naming a temporary file that will be needed to have save-as done on it once it makes it to Sigil, right?

Yes, I do. I even wrote patch to make Sigil propose "Save As" instead of "Save" in those cases - alas: user-none didn't like it .

Yes, running it through a file cleaning routine is indeed possible and KindleUnpack has one I think. Giving it the same basename as the original file might in fact be easier to do since no file name cleaning routine would be needed at all since a valid base name has to exist.

I would just like to get meaningful file name proposed by Sigil on the fly.
Original file name would be second choice for me. This would be in most cases unique but not necessarily meaningful. Both of them would be optimal but, as I've mentioned, somehow overkill.

[JSWolf]

Before you get your proper filename, I'd just like to get the eBook.

[varlog]

Originally Posted by JSWolf

Before you get your proper filename, I'd just like to get the eBook.

I think you have your ebook already - you just want to have it proper

[DiapDealer]

Originally Posted by JSWolf

Before you get your proper filename, I'd just like to get the eBook.

See if the attached beta version gives you any joy, Jon.

@varlog
I'm not convinced that something might not break with the filename experimentation I've done (it's actually incomplete on the KF8 side of things in this beta), but let me know what you think.

[user_none]

Originally Posted by varlog

Yes, I do. I even wrote patch to make Sigil propose "Save As" instead of "Save" in those cases - alas: user-none didn't like it .

That is correct. You should have been clearer about the reason for the patch. The patch itself would still have been rejected. You shouldn't check for special dir names in the path. The proper solution is to expose a clear_save_name function from MainWindow and have plugin runner call this after loading the book.

[JSWolf]

Originally Posted by DiapDealer

See if the attached beta version gives you any joy, Jon.

@varlog
I'm not convinced that something might not break with the filename experimentation I've done (it's actually incomplete on the KF8 side of things in this beta), but let me know what you think.

Yes it worked. Now, would it be possible to split the HTML at the chapter stops? That would make things much easier to deal with. With the entire eBook as a single HTML males Sigil very slow.

[KevinH]

Hi,
I think you can insert Sigil split markers using Sigil's find and replace regular expressions and then split the file into all chapters at one time. Since chapter starting points may change formats across ebooks, using a custom regular expression in Sigil is probably the best approach.
KevinH

Originally Posted by JSWolf

Yes it worked. Now, would it be possible to split the HTML at the chapter stops? That would make things much easier to deal with. With the entire eBook as a single HTML males Sigil very slow.

[DiapDealer]

Originally Posted by KevinH

Hi,
I think you can insert Sigil split markers using Sigil's find and replace regular expressions and then split the file into all chapters at one time. Since chapter starting points may change formats across ebooks, using a custom regular expression in Sigil is probably the best approach.
KevinH

I agree. My approach with these mobi files is basically doing the bare minimum to get it in an epub-like state (and approximate xhtml-ness wherever possible). There's no getting around the fact that if you want mobis turned into "pretty," well-behaved epubs, you're going to have to get your hands dirty regardless. But if you want something that you can give a quick tweak and then feed right back to kindlegen, this might be the ticket. I'm not trying to make something that can take every ugly-assed mobi anyone throws at it and turn it into a sleek, shiny new epub. I'm trying to make something that can take every ugly-assed mobi thrown at it and not barf on your shoes.