keeping lines together?

angharad09 · 08-06-2020, 09:56 PM

Apologies if this is a really basic question, but I've been looking and I haven't been able to figure it out.

Is there a way to keep lines together -- for example, a heading with the next few lines of text, or a figure with its caption, or an endnote number with the corresponding endnote?

I'm very rusty in Calibre (and never was a power user). When I import a Word (.docx) file and convert it to .epub, these types of paired items don't stick together. Is there some way to make it happen? Would it work better if I imported an .html file instead of .docx?

Thanks for any clues!

hobnail · 08-06-2020, 10:36 PM

If your chapters are each in separate files then you won't get page breaks after the chapter title since it will be at the top of the page. But if you have subsections within a chapter, for example, chapters use h2 and subsections use h3, then it's not so easy to fix. You could try the following:

Code:

h1, h2, h3, h4 {
    break-after: avoid;
    break-inside: avoid;
    page-break-after: avoid;
    page-break-inside: avoid;
}

For a figure with its caption, you could wrap the figure and its caption in a div and then use the above 2 break-inside avoid on the div. And maybe a break-after avoid on the img. Similarly for endnotes, although I've used ol for those.

Those who know more than me also say that it's better to use margin-top instead of margin-bottom for spacing between things. It could be that margin-bottom gives the rendering engine more wiggle and allows a page break there.

hobnail · 08-06-2020, 10:42 PM

I should also say that in fiction I despise endnotes and when reformatting a book from Project Gutenberg I convert them into a parenthetical remark either after the sentence or at the end of the paragraph. If it's really short it may go where the endnote number appears in the sentence.

Even in nonfiction I find endnotes tiresome. They're ok for bibliographic references in scholarly stuff.

angharad09 · 08-07-2020, 11:57 AM

Thanks very much, hobnail.
So basically, if it can't be done that way, it can't be done. (And presumably, people who have e-readers that can't pick up that formatting are already used to awkward breaks.) ...right?

(I don't want to be a control freak about the layout, just want to make sure I've made it as put-together and reader-friendly as possible.)

hobnail · 08-07-2020, 01:29 PM

Quote:

Originally Posted by angharad09

Thanks very much, hobnail.
So basically, if it can't be done that way, it can't be done. (And presumably, people who have e-readers that can't pick up that formatting are already used to awkward breaks.) ...right?

(I don't want to be a control freak about the layout, just want to make sure I've made it as put-together and reader-friendly as possible.)

There might be better ways, I'm no expert.

angharad09 · 08-08-2020, 06:57 AM

Just in case it's helpful to someone down the line ... I think I have sorted the endnotes.
(If a CSS guru sees a potential problem here, please sing out!) Here goes:

Calibre treats each note like a dl (descriptive list), with dt for the endnote number and dd for the text.
If you set ...
the dt to page-break-after: avoid
the dd to page-break-before: avoid
the dl to page-break-inside: avoid
... the endnotes behave.
(I'm not sure whether the first two are essential; it was the third one that did the trick.)

I also took "page-break-inside: avoid" off of the dd (because I'd rather see an endnote break in the middle of the text than between the number and the text).

It makes me nervous to make any changes to the endnote coding for fear of breaking the complicated links between the note and the text. But I think these should be safe changes because I didn't touch the HTML ... right?

It took me awhile to start to "get" Calibre-produced coding, but the Edit Book screen is super helpful for seeing what code is attached to what and how the different codes compare.

The other related problems were more straightforward and/or related to bad formatting in the original Word document, so not too interesting to discuss here further, but I thought I'd mention the endnotes. Again, big caveat, not a power user here, use with caution -- but it seems like it ought to work.

angharad09 · 08-13-2020, 03:30 PM

So the more I look into this, the more it looks like it's almost impossible to prevent all breaks after subheadings, even with "break-after: avoid" and the like.

I'm seeing one solution recommended, which is to wrap the heading and the first paragraph in a <div> with the appropriate CSS. But that seems like a lot of manual interventions and thus a lot of opportunity for error.

And I'm wondering how bad it would be to just insert a really small <p> (maybe line-height 0.15 or the like) before the headings, so that if a break had to happen it would happen there? Because the <p> would be self-contained, it seems a little less likely than a <div> to mess up the "real" text, and it would be easier to get rid of if for some reason it wasn't needed anymore.

It's not beautiful and it seems a bit like cheating, but would it actually break anything? If yes, please sing out and save me from myself!

hobnail · 08-13-2020, 04:44 PM

Quote:

Originally Posted by angharad09

I'm seeing one solution recommended, which is to wrap the heading and the first paragraph in a <div> with the appropriate CSS. But that seems like a lot of manual interventions and thus a lot of opportunity for error.

And I'm wondering how bad it would be to just insert a really small <p> (maybe line-height 0.15 or the like) before the headings, so that if a break had to happen it would happen there?

Those both strike me as ugly kludges. The first one, with the div, would probably push the header and first paragraph onto the next page. Since you're somewhat amenable to having a page break before the subheading maybe it's time to start thinking about forcing a page break before each subheading. (Every morning when you wake up tell yourself it wouldn't be that bad and maybe eventually you'll accept it. Heh.)

hobnail · 08-13-2020, 04:53 PM

I'm also wondering if there isn't some crap css in your files since you're using Word .docx files. Whenever I open an epub that was created in Word I'm always rolling my eyes at all of the crud that is in them.

A possibly interesting/informative exercise would be to remove the .css files that you get after calibre converts them and see how things come out on the ereader. Also then use calibre's thing to remove all unused css and classes from the html. At that point you can start working forward and add enough css to make it look reasonable.

angharad09 · 08-13-2020, 05:28 PM

Unfortunately, forced page breaks before the subheadings would create more problems than they would solve, in this case.

The CSS looks pretty clean to me (I'm still working my way through the file, but I've looked at all the HTML and CSS related to the headings and text immediately before and after. From what I can see (after spending the better part of the day) online, this is a pretty well known problem. Alas, I haven't seen any good solutions (at least, any I could understand). But I don't remember ever seeing a straggling heading in a commercially produced ebook. It seems like there must be a fix for this ... somewhere!

I imagine with Word files, it's a question of crud in, crud out. The questionable Calibre code that I've seen so far in this file seems like it probably comes from places where I missed some manual formatting when I was cleaning up the .docx. Lord knows there are 1001 ways to mess up a Word file. It's definitely worth a hard-core cleanup before importing.

Hitch · 08-13-2020, 05:34 PM

Quote:

Originally Posted by hobnail

Those both strike me as ugly kludges. The first one, with the div, would probably push the header and first paragraph onto the next page. Since you're somewhat amenable to having a page break before the subheading maybe it's time to start thinking about forcing a page break before each subheading. (Every morning when you wake up tell yourself it wouldn't be that bad and maybe eventually you'll accept it. Heh.)

OMG, forcing page breaks before subheadings?

NON! Jeeze, Louise, you'd have breaks all over the damned place. That would drive me nuts as a reader. It's bad enough that this bloody widows-orphans stuff has started to kick in, so you're CONSTANTLY seeing shortened pages and thinking that the next page is the start of a new chapter--and it's not--but to do this now for a subhead?

I would probably end up throwing a device across the room if that happened.

FWIW, we've made well over 5,000 ebook files at my shop, and we've never found a remotely viable, decent, reliable, attractive way to force PRINT convention layout elements, like headings and the first paragraph, to remain together.

A better approach is to realize that it's not in print--it's an eBook. The more you try to force it to emulate print and follow those conventions, the more kludgey and fugly and not-user-friendly the resulting book will be.

That's my $.02 and most of it is entirely my opinion. The part about never having found a better way is fact.

Hitch

hobnail · 08-13-2020, 06:10 PM

Listen to Hitch, our resident expert (and a very experienced one at that).

JSWolf · 08-13-2020, 07:10 PM

Quote:

Originally Posted by Hitch

OMG, forcing page breaks before subheadings?

NON! Jeeze, Louise, you'd have breaks all over the damned place. That would drive me nuts as a reader. It's bad enough that this bloody widows-orphans stuff has started to kick in, so you're CONSTANTLY seeing shortened pages and thinking that the next page is the start of a new chapter--and it's not--but to do this now for a subhead?

I would probably end up throwing a device across the room if that happened.

FWIW, we've made well over 5,000 ebook files at my shop, and we've never found a remotely viable, decent, reliable, attractive way to force PRINT convention layout elements, like headings and the first paragraph, to remain together.

A better approach is to realize that it's not in print--it's an eBook. The more you try to force it to emulate print and follow those conventions, the more kludgey and fugly and not-user-friendly the resulting book will be.

That's my $.02 and most of it is entirely my opinion. The part about never having found a better way is fact.

Hitch

Well said. I've been saying something similar for some time. I agree that you do what works for an eBook and do not treat it like it's a pBook.

Notjohn · 08-18-2020, 03:53 PM

Too many authors think as book designers instead of as readers. Anyone who consumes many ebooks is quite used to these breaks, and likely be more annoyed at a likely outcome such as having a couple lines at the top of the "page" because the author put in a page break before the sub-head.

If it really bothers you, better I think just to get rid of the sub-heads.

When it comes time for the print edition, sure, deploy your design talents to get rid of the breakhead toward the bottom of the printed page followed by one line of type.

08-06-2020, 09:56 PM	#1
angharad09 Enthusiast Posts: 30 Karma: 10 Join Date: Aug 2011 Device: none	keeping lines together? Apologies if this is a really basic question, but I've been looking and I haven't been able to figure it out. Is there a way to keep lines together -- for example, a heading with the next few lines of text, or a figure with its caption, or an endnote number with the corresponding endnote? I'm very rusty in Calibre (and never was a power user). When I import a Word (.docx) file and convert it to .epub, these types of paired items don't stick together. Is there some way to make it happen? Would it work better if I imported an .html file instead of .docx? Thanks for any clues!

08-06-2020, 10:36 PM	#2
hobnail Running with scissors Posts: 1,584 Karma: 14328510 Join Date: Nov 2019 Device: none	If your chapters are each in separate files then you won't get page breaks after the chapter title since it will be at the top of the page. But if you have subsections within a chapter, for example, chapters use h2 and subsections use h3, then it's not so easy to fix. You could try the following: Code: h1, h2, h3, h4 { break-after: avoid; break-inside: avoid; page-break-after: avoid; page-break-inside: avoid; } For a figure with its caption, you could wrap the figure and its caption in a div and then use the above 2 break-inside avoid on the div. And maybe a break-after avoid on the img. Similarly for endnotes, although I've used ol for those. Those who know more than me also say that it's better to use margin-top instead of margin-bottom for spacing between things. It could be that margin-bottom gives the rendering engine more wiggle and allows a page break there. Last edited by hobnail; 08-06-2020 at 10:38 PM.

08-06-2020, 10:42 PM	#3
hobnail Running with scissors Posts: 1,584 Karma: 14328510 Join Date: Nov 2019 Device: none	I should also say that in fiction I despise endnotes and when reformatting a book from Project Gutenberg I convert them into a parenthetical remark either after the sentence or at the end of the paragraph. If it's really short it may go where the endnote number appears in the sentence. Even in nonfiction I find endnotes tiresome. They're ok for bibliographic references in scholarly stuff. Last edited by hobnail; 08-06-2020 at 10:45 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
auto_cleanup_keep keeping too much	ireadtheinternet	Recipes	2	10-31-2014 07:59 AM
Keeping stuff together	MrB	Sigil	12	09-05-2012 09:25 AM
Touch Dark lines between lines of text	taming	Kobo Reader	12	06-13-2011 07:20 PM

08-07-2020, 11:57 AM	#4
angharad09 Enthusiast Posts: 30 Karma: 10 Join Date: Aug 2011 Device: none	Thanks very much, hobnail. So basically, if it can't be done that way, it can't be done. (And presumably, people who have e-readers that can't pick up that formatting are already used to awkward breaks.) ...right? (I don't want to be a control freak about the layout, just want to make sure I've made it as put-together and reader-friendly as possible.)

08-08-2020, 06:57 AM	#6
angharad09 Enthusiast Posts: 30 Karma: 10 Join Date: Aug 2011 Device: none	Just in case it's helpful to someone down the line ... I think I have sorted the endnotes. (If a CSS guru sees a potential problem here, please sing out!) Here goes: Calibre treats each note like a dl (descriptive list), with dt for the endnote number and dd for the text. If you set ... the dt to page-break-after: avoid the dd to page-break-before: avoid the dl to page-break-inside: avoid ... the endnotes behave. (I'm not sure whether the first two are essential; it was the third one that did the trick.) I also took "page-break-inside: avoid" off of the dd (because I'd rather see an endnote break in the middle of the text than between the number and the text). It makes me nervous to make any changes to the endnote coding for fear of breaking the complicated links between the note and the text. But I think these should be safe changes because I didn't touch the HTML ... right? It took me awhile to start to "get" Calibre-produced coding, but the Edit Book screen is super helpful for seeing what code is attached to what and how the different codes compare. The other related problems were more straightforward and/or related to bad formatting in the original Word document, so not too interesting to discuss here further, but I thought I'd mention the endnotes. Again, big caveat, not a power user here, use with caution -- but it seems like it ought to work.

08-13-2020, 03:30 PM	#7
angharad09 Enthusiast Posts: 30 Karma: 10 Join Date: Aug 2011 Device: none	So the more I look into this, the more it looks like it's almost impossible to prevent all breaks after subheadings, even with "break-after: avoid" and the like. I'm seeing one solution recommended, which is to wrap the heading and the first paragraph in a <div> with the appropriate CSS. But that seems like a lot of manual interventions and thus a lot of opportunity for error. And I'm wondering how bad it would be to just insert a really small <p> (maybe line-height 0.15 or the like) before the headings, so that if a break had to happen it would happen there? Because the <p> would be self-contained, it seems a little less likely than a <div> to mess up the "real" text, and it would be easier to get rid of if for some reason it wasn't needed anymore. It's not beautiful and it seems a bit like cheating, but would it actually break anything? If yes, please sing out and save me from myself!

08-13-2020, 04:53 PM	#9
hobnail Running with scissors Posts: 1,584 Karma: 14328510 Join Date: Nov 2019 Device: none	I'm also wondering if there isn't some crap css in your files since you're using Word .docx files. Whenever I open an epub that was created in Word I'm always rolling my eyes at all of the crud that is in them. A possibly interesting/informative exercise would be to remove the .css files that you get after calibre converts them and see how things come out on the ereader. Also then use calibre's thing to remove all unused css and classes from the html. At that point you can start working forward and add enough css to make it look reasonable.

08-13-2020, 05:28 PM	#10
angharad09 Enthusiast Posts: 30 Karma: 10 Join Date: Aug 2011 Device: none	Unfortunately, forced page breaks before the subheadings would create more problems than they would solve, in this case. The CSS looks pretty clean to me (I'm still working my way through the file, but I've looked at all the HTML and CSS related to the headings and text immediately before and after. From what I can see (after spending the better part of the day) online, this is a pretty well known problem. Alas, I haven't seen any good solutions (at least, any I could understand). But I don't remember ever seeing a straggling heading in a commercially produced ebook. It seems like there must be a fix for this ... somewhere! I imagine with Word files, it's a question of crud in, crud out. The questionable Calibre code that I've seen so far in this file seems like it probably comes from places where I missed some manual formatting when I was cleaning up the .docx. Lord knows there are 1001 ways to mess up a Word file. It's definitely worth a hard-core cleanup before importing.

08-13-2020, 06:10 PM	#12
hobnail Running with scissors Posts: 1,584 Karma: 14328510 Join Date: Nov 2019 Device: none	Listen to Hitch, our resident expert (and a very experienced one at that).

08-18-2020, 03:53 PM	#14
Notjohn mostly an observer Posts: 1,518 Karma: 987654 Join Date: Dec 2012 Device: Kindle	Too many authors think as book designers instead of as readers. Anyone who consumes many ebooks is quite used to these breaks, and likely be more annoyed at a likely outcome such as having a couple lines at the top of the "page" because the author put in a page break before the sub-head. If it really bothers you, better I think just to get rid of the sub-heads. When it comes time for the print edition, sure, deploy your design talents to get rid of the breakhead toward the bottom of the printed page followed by one line of type.

Advert

Advert