Calibre Won't Convert This Book

[DNSB]

For what it's worth, I prefer using the output of the KindleUnpack plugin instead of using calibre's convert ebook when converting azw3/KF8 to epub. If nothing else, KindleUnpack will do much less modification on the output file and comes a lot closer to duplicating the input epub (quite a few books are supplied to Amazon in epub format). I saw too many issues with calibre's convert ebook which does not remove epub3 bits and bobs when converting to epub2 and gets very enthused about splitting files (take a look at the footnotes files in the KindleUnpack version compared to the calibre conversion version).

I tried opening your scrambled azw3 with calibre's editor and it came up with multiple errors when I ran the editor's built-in check.

Also, it took ~3 seconds to convert your scrambled azw3 on my system.

[enuddleyarbl]

As several people suggested, I turned off Heuristic Processing. The conversion worked fine that way. Since this is the first time I've run into such a problem, I've got to wonder what this book is doing that's different enough to cause problems (of course, a hint might be that EpubCheck even fails to run on it at all). I guess I'll work my way through the list of heuristics and see if any individual one causes a problem. Of course, it's not vital to do that since I was able to get and edit the book as an epub3 via KindleUnpack. But, it might be interesting.

[enuddleyarbl]

Interesting. The heuristic option causing the problem is "Ensure scene breaks are consistently formatted" (from the manual -- "With this option calibre will attempt to detect common scene-break markers and ensure that they are center aligned. ‘Soft’ scene break markers, i.e. scene breaks only defined by extra white space, are styled to ensure that they will not be displayed in conjunction with page breaks."). If I turn that option off, the AZW3 converts fine. With it on, regardless of the other options, it doesn't convert.

[Karellen]

A bit late to the party, but I gave the conversion a try with Heuristics enabled (which I have never used)

I seem to have got stuck on 1% using about 10% of my i7-10700 cpu.

This is my log... https://paste.kodi.tv/ovameledid

Once I disabled heuristics, it coverted in about 3 seconds.

Trying to run EpubCheck on the azw3 version, I get an "AttributeError"...

Spoiler:

calibre, version 6.9.0
ERROR: Unhandled exception: <b>AttributeError</b>:'OptionValues' object has no attribute 'dont_compress'

calibre 6.9  embedded-python: True
Windows-10-10.0.19044-SP0 Windows ('64bit', 'WindowsPE')
('Windows', '10', '10.0.19044')
Python 3.10.1
Windows: ('10', '10.0.19044', 'SP0', 'Multiprocessor Free')
Interface language: None
Successfully initialized third party plugins: Gather KFX-ZIP (from KFX Input) (1, 50, 0) && DeDRM (10, 0, 2) && Package KFX (from KFX Input) (1, 50, 0) && EpubCheck (0, 2, 4) && KFX metadata reader (from KFX Input) (1, 50, 0) && KFX Input (1, 50, 0) && Set KFX metadata (from KFX Output) (1, 65, 0) && KFX Output (1, 65, 0) && Kindle Collections (1, 7, 29) && KindleUnpack - The Plugin (0, 83, 1) && Kobo Utilities (2, 16, 6) && Manage Series (1, 5, 0) && ScrambleEbook (0, 6, 0) && Sum Column (0, 3, 3) && View Manager (1, 10, 2) && WordDumb (3, 28, 0)
Traceback (most recent call last):
  File "calibre_plugins.epub_check.main", line 221, in ask_user
  File "calibre\ebooks\oeb\polish\container.py", line 1543, in commit
  File "calibre\ebooks\oeb\polish\container.py", line 1470, in opf_to_azw3
  File "calibre\ebooks\conversion\plugins\mobi_output.py", line 328, in convert
  File "calibre\ebooks\mobi\writer8\main.py", line 496, in create_kf8_book
  File "calibre\ebooks\mobi\writer8\main.py", line 45, in __init__
AttributeError: 'OptionValues' object has no attribute 'dont_compress'

.
.

[Karellen]

Strangely, I was able to make a minor edit to the book that fixes the hang.

If you go to part0035.html lines 234, 236 and 238

You will see...

<p class="Text-Standard-Space-Before--tx" style="text-indent:3%"><span class="ePub-I">*********************************************xncq</span></p>

The large space being full of no-break spaces.

Move the Italic span to avoid the no-break spaces and the conversion then works.

<p class="Text-Standard-Space-Before--tx" style="text-indent:3%">*************************************** ******<span class="ePub-I">xncq</span></p>

Sorry if that has been figured out already, I didn't read every post in the thread. (my bad)

[enuddleyarbl]

Your line numbers are different from mine, but I'm almost positive those are the nbsp things I had wondered about earlier. Interesting that simply removing the italic formatting from them would allow the book to convert properly. Searching through the book, even though that code for an nbsp is used a LOT througout the book, that clump in part0035 seem to be the only ones that are styled with an italic.

EDIT: I also confirm your finding. I removed all five (?) italic-based spans around those nbsps in part0035 and the resulting AZW3 converts to EPUB3 without problem (even with heuristic processing on and doing the "Ensure scene breaks are consistently formatted" option). Good catch.

[JSWolf]

Originally Posted by enuddleyarbl

As several people suggested, I turned off Heuristic Processing. The conversion worked fine that way. Since this is the first time I've run into such a problem, I've got to wonder what this book is doing that's different enough to cause problems (of course, a hint might be that EpubCheck even fails to run on it at all). I guess I'll work my way through the list of heuristics and see if any individual one causes a problem. Of course, it's not vital to do that since I was able to get and edit the book as an epub3 via KindleUnpack. But, it might be interesting.

So why did it only take me 3 seconds to convert when heuristic processing was on?

[Quoth]

Originally Posted by enuddleyarbl

EDIT: I also confirm your finding. I removed all five (?) italic-based spans around those nbsps in part0035

Something that shouldn't exist.

No document should have more than one consecutive space (of any kind). That's what CSS Is for.

[Quoth]

Originally Posted by JSWolf

So why did it only take me 3 seconds to convert when heuristic processing was on?

Likely some other setting interacts. Certainly the document has stupid things in it.

[JSWolf]

Originally Posted by Quoth

Likely some other setting interacts. Certainly the document has stupid things in it.

It's KF8. Of course it won't validate with epubcheck.

After conversion, then check and fix any errors.

[kovidgoyal]

heuristics work using regexps and these sometimes become very slow depending on markup. In this case it will be the detect_soft_breaks() function whose regex is

(?P<initline><(?P<outer>p|div)[^>]*>\s*(<(?P<inner1>font|span|[ibu])[^>]*>)?\s*(<(?P<inner2>font|span|[ibu])[^>]*>)?\s*(<(?P<inner3>font|span|[ibu])[^>]*>)?\s*\s*(?P<init_content>.*?)(</(?P=inner3)>)?\s*(</(?P=inner2)>)?\s*(</(?P=inner1)>)?\s*</(?P=outer)>)\s*<div[^>]*>\s*</div>\s*(?P<line_two><(?P<linetwo_ter>p|div)[^>]*>\s*(<(?P<linetwo_ner1>font|span|[ibu])[^>]*>)?\s*(<(?P<linetwo_ner2>font|span|[ibu])[^>]*>)?\s*(<(?P<linetwo_ner3>font|span|[ibu])[^>]*>)?\s*\s*(?P<line_two_content>.*?)(</(?P=linetwo_ner3)>)?\s*(</(?P=linetwo_ner2)>)?\s*(</(?P=linetwo_ner1)>)?\s*</(?P=linetwo_ter)>)