AZW3 to EPUB conversion is split with one page per paragrah

[steinarb]

Calibre 2.15 on Windows 8.1.

No custom conversion settings.

The target reader is a Sony PRS-T1.

When converting an AZW3 file to EPUB the size increased from 0.6MB to 3MB.

The EPUB didn't contain any obviously large files, the cover image was 103kB and the OPF file was 600kB (but compressed well). However, the EPUB contained a lot of HTML files.

When reading the EPUB I discovered that the text had been split with one page per paragraph, and the page count was 4911 (the AZW3 original has 593 pages).

Is there a particular setting I should look at to make it not split on the paragraph level?

I added metadata from the internet before converting, keeping the original cover, but that hasn't contributed much to the OPF. Most of the OPF size is related to entries for each individual HTML file.

The conversion log is attached (with a lot of "Detected chapter" entries).

The file I'm trying to convert is copyrighted, but I can create a bug report with the input and output files attached if this is necessary (as described here https://www.mobileread.com/forums/sho...d.php?t=186697 ).

[steinarb]

I have found the culprit I think.

I took an edit book on the AZW3 original, and looked at a random HTML file.

Many, perhaps all, of the <p> elements look like this:

<p class="chapter">“Yes,” he said. “It is.”</p>

And that triggers the XPath structure detection

@class = 'chapter'

[steinarb]

What I did to fix this, was to:

• Start a conversion
• Select "None" in "Chapter Mark" (the original setting was "Pagebreak")
• Do the conversion

The resulting EPUB looks ok in Calibre's EPUB reader, the TOC points to the correct places and contains meaningful entries for the real chapters. The resulting epub also have a size of 0.6MB, instead of 3MB.

[theducks]

That is not a bug
By default, Calibre looks for certain words in the 'Structure Detection' section of Conversion, to split/make into headings, upon.

Were you expecting Calibre to count the results and go 'That is an absurd number of Chapters' ?

IMHO p class="chapter" was a weak choice for a pragraph selector name
One I have not seen used by common ebook publishers

[steinarb]

Originally Posted by theducks

That is not a bug

I know that. I never said it was.

Originally Posted by theducks

Were you expecting Calibre to count the results and go 'That is an absurd number of Chapters' ?

I had no expectations.

I had a problem.

I found a fix for the problem.

I posted my findings as responses to my original problem.

This makes it useful for someone who has the same problem and might google for a solution.

Originally Posted by theducks

IMHO p class="chapter" was a weak choice for a pragraph selector name
One I have not seen used by common ebook publishers

This was a very common ebook publisher/vendor.

The previous books of the same series had no such problem.

I would use "silly choice for a paragraph selector name", rather than a "weak choice for a paragraph selector name", but at least it made it pretty obvious what was happening when I found it.

I worried for a bit that I would have to XSLT or perl-modify the individual HTML files of the AZW3 file, or mess with the chapter detection XPath expression, but was relived when removing the chapter mark gave a satisfactory result.

[rashkae]

I find the default Calibre page splitting options to be a hindrance. They are no doubt great, (probably essential) when converting non e-book documents to e-book formats. However, E-book formats (epub, mobi, azw3, etc.) are probably already split (or at least have page breaks), and adding heuristics to create new splits can often muddle thing, so I change these defaults in my own config.:

Under Structure Detection, Chapter Mark setting is changed from "Page Break" to none,

Insert Page Breaks before Xpath: is disabled ( / )

Some books need to have page breaks removed from their CSS when used inappropriately.. (I've seen many books with a css page-break-before: always in their chapter headings, but also have some kind of graphic at the top of the page. When run through an e-book conversion, this causes the graphic to be put on a page by itself.)

[loadoutgreen75]

Thanks for posting how you fixed it, I had been stuck at this for a while with epub->epub, I didn't think to look at the raw text