Chapter Headings Issue

[TheSmitty]

I have a book I loaded into Calibre from my Amazon library. When i put the book on my kobo using Calibre (KoboTouchExtended installed, set to 'Send books as kepubs') I notice the chapter headers are broken apart onto separate pages in the kobo.

For instance, looking at the book on Kindle the following is centered and bolded:
-----------------------------------
1
A Header
another minor header

text of the book
-----------------------------------

On the Kobo it becomes (where <next page> means swipe to next page on device):

1
<next page>
A Header
<next page>
another minor header

text of the book
------------------------------------

I hope my example makes sense, It does this for several that I have noticed.
There is a TON of great information here but I tried search and could not find help although I am sure it exists somewhere. I am hoping someone reading this sees it and has a easy answer.

[Karellen]

Maybe you can scramble the book and upload it here so we can check the coding.

[JSWolf]

In calibre under Preferences > Common options > Structure detection, the Detect chapters XPath is

//*[((name()='h1' or name()='h2') and re:test(., '\s*((chapter|book|section|part)\s+)|((prolog|prologue|epilogue)(\s+|$))', 'i')) or @class = 'chapter']

When calibre detects what it thinks is a chapter header, it splits the page at that point. So what's happening is the Kindle eBook is using headers tags for each line. Either h1 and/or h2. So calibre is splitting it as it should.

In order to fix that, you'll have to edit either the XPath or the Kindle eBook. YOu could delete the XPath code, sent the eBook to your Kobo and then put it back.

[JSWolf]

Originally Posted by Karellen

Maybe you can scramble the book and upload it here so we can check the coding.

No need to see the eBook. I just gave the reason why it was split.

[TheSmitty]

Originally Posted by JSWolf

In calibre under Preferences > Common options > Structure detection, the Detect chapters XPath is

//*[((name()='h1' or name()='h2') and re:test(., '\s*((chapter|book|section|part)\s+)|((prolog|prologue|epilogue)(\s+|$))', 'i')) or @class = 'chapter']

When calibre detects what it thinks is a chapter header, it splits the page at that point. So what's happening is the Kindle eBook is using headers tags for each line. Either h1 and/or h2. So calibre is splitting it as it should.

In order to fix that, you'll have to edit either the XPath or the Kindle eBook. YOu could delete the XPath code, sent the eBook to your Kobo and then put it back.

What you say makes sense. Just so I am clear, you say remove all the code from the 'Detect chapters at (XPath expression)' setting within common options of Calibre, Apply, Convert to EPub, then paste the code back, Apply?

Isn't this a problem for pretty much any ebook? Do people generally remove the code and leave it at that?

I did stumble upon the plug-in KindleUnpack. To use it after I installed it, I had to delete the epub that Calibre created, then click on the menu icon the plugin added, select AZW3 then select 'KF8 to ePub' option. This created a new epub which then when sent to the kobo, it passed through the touchextended which put a kepub on the device that looks proper. I am unsure if this plugin is considered viable.

[JSWolf]

Originally Posted by TheSmitty

What you say makes sense. Just so I am clear, you say remove all the code from the 'Detect chapters at (XPath expression)' setting within common options of Calibre, Apply, Convert to EPub, then paste the code back, Apply?

Isn't this a problem for pretty much any ebook? Do people generally remove the code and leave it at that?

I did stumble upon the plug-in KindleUnpack. To use it after I installed it, I had to delete the epub that Calibre created, then click on the menu icon the plugin added, select AZW3 then select 'KF8 to ePub' option. This created a new epub which then when sent to the kobo, it passed through the touchextended which put a kepub on the device that looks proper. I am unsure if this plugin is considered viable.

Most chapter header do not use multiple header tags. So it's not an issue in most cases. I would remove the XPath code, do your conversion and then put it back. Actually, most use just p instead of a proper header tag

[Sirtel]

I've had that code disabled for many years now, precisely because of this problem.

[JSWolf]

I have not does a conversion from an eBook I have not seen the code in a very long time. So I know that code is not going to be an issue.

[Quoth]

I've seen div, span and p used rather than hx for headings!
I've had each paragraph be a new page due to a either a mad tag used for body text, or every regular body text paragraph starting
<p class="chapter">
There is a lot of madness out there!

[BetterRed]

Originally Posted by Quoth

. . .

There is a lot of madness out there!

Here too

BR

[Quoth]

Tears in the rain

[JSWolf]

Originally Posted by Quoth

I've seen div, span and p used rather than hx for headings!
I've had each paragraph be a new page due to a either a mad tag used for body text, or every regular body text paragraph starting
<p class="chapter">
There is a lot of madness out there!

That a good reason to make most paragraphs be <p>.

[theducks]

Sorry Jon,
That is a good reason for book so called code wranglers to LEARN the craft .
<p class="chapter"> for a regular (content) paragraph is just stupid naming. (I am not much of a fan of the insanely long
<p class="describe-everything-possible-about-the-styling">
either.
Gimme old school UNIX style names
TX, FP, CN, CT

[Quoth]

Originally Posted by theducks

<p class="chapter"> for a regular (content) paragraph is just stupid naming. (I am not much of a fan of the insanely long
<p class="describe-everything-possible-about-the-styling">
either.

Yes, agree totally.

I guess they were thinking "body of the chapter". It was one of the big publishers.

When i'm fixing mad ebook I use <p class="indent"> for ordinary body text and <p class="no-indent"> for a first paragraph after anything centred.

The way "zip" works means it's no bloat at all.