Why is it so hard to preserve blank lines?

[Robotech_Master]

Originally Posted by RichL

In Moon reader 2.1 you can check/un-check use of CSS.

I've tried that. For some reason, when I uncheck "Disable CSS," it still strips out the blank lines, even if I leave the "strip extra blank lines" option unchecked as well.

But if I use the "Preview with publisher's settings" button, there the blank lines are—but it's also locked into a small sans serif font that I can't resize or change. Weird, huh?

Originally Posted by murg

I put in something like:

<p class="centre">* * *</p>
or
<p class="centre">&mdash;&mdash;&mdash;</p>

since this is targeted at an ereader, this covers the situation where the 'blank' line is at the top or bottom of the page.

The mdash method has the additional feature of not interfering with the existing asterisk scene breaks in the book.

That's a nice idea, but I don't think it should have to be incumbent on me to manually edit every e-book I make or download—books that work just fine in Adobe Digital Editions, Nook, Kobo, iBooks, Google Play Books, eReader Prestigio, Aldiko (with "Use Advanced Formatting" unchecked), UB Reader, Marvin, Gerty, and Bibliovore—just because they don't work properly on a couple of otherwise-excellent e-reader apps, Moon+ and Freda. I'd rather see those apps join the club and show the books with the formatting everybody else respects.

Originally Posted by Toxaris

It does not depend on Scrivener itself, but more how the blank line is coded into the ePUB. That can be done in various ways. The purists will insist you use margins to create a blank line and although they are correct, your reading program need to honor the stylesheet in order to represent it (btw, a reading program that does not honor stylesheets is a broken program in my book...). Another much used method is the empty paragraph. However, a lot of readers and reading programs will discard real empty paragraphs or paragraphs with only a space inside it (e.g. <br /> or <p> </p>. That is why you need to enter a special space inside it to work in all cases: <p>&nbsp;</p>.
So, perhaps Scrivener has an output option for this, otherwise you need to check how it is put in the code and correct it there.

Hmm, there's a thought. I'll post asking about that over on the forums on Scrivener's developer site, Literature & Latte.

Originally Posted by Jim Chapman

if you set Freda's 'remove blank lines' setting to yes, then blank lines will be removed everywhere, whether at the end of sections, or at the ends of paragraphs, or wherever. The best way to ensure that you get a blank line after some element in Freda is to set a margin below the element ("margin-below" in the CSS Style). Freda's parsing of CSS styles is a bit flakey, but it should be able to understand that (but make sure that the setting 'max margin' is set to some value other than zero - a zero value for that setting will mean that Freda suppresses all margins).

If you don't want to start messing about with margins, then probably your best bet is to use the Freda settings:
line break after para = no
force indent = yes
remove blank lines = no
This should mean that any place you actually insert a line break (element "<br>") in your file, you will see a line break. Paragraphs will not have space inserted between them, but the first line of each paragraph will be indented.

Do let me know how you get on, and by all means send me some sample files and style sheets, if you'd like me to check what exactly Freda is doing with them, and to fix the program in any places where it is doing the wrong thing.

Thanks for reaching out, and thanks for your willingness to look into fixing the program. I've emailed you one of my e-book files separately.

[GeoffR]

Using a single blank line to separate sections will not work in all situations, even if the ereader does respect the publisher's CSS styles.

For example, suppose that the reader has selected a font size and line spacing that results in a line height of 40px on their device, and has set the page margins to 30px. Because of things like superscripts, subscripts, images, headings, paragraph margins, etc. the position of the last line on the page is not always the same from page to page, resulting in a gap of 0px-39px in addition to the page margin, so during normal reading the reader could expect to see a gap at the bottom of the page of 30px-69px.

If you use a single blank line as a separator and that blank line happens to be the last line of the page, then the gap will be 40px + 0px-39px + 30px for a total of 70px-109px. That means in some situations the presence of the separator only results in a gap that is a few pixels larger than largest gap that can occur without a separator, and is likely to be invisible to the reader.

In a paper book or fixed-layout ebook the publisher knows in advance when a separator falls at the top or bottom of a page and can take special measures such as replacing it with a visible separator like an asterism, but in an ePub (ePub2 anyway) that is not possible. (Edit: I guess it is possible in a limited way using page-preak-after:avoid

So to ensure that the separator is visible in all situations you need to use at least two blank lines (not just 2em margin, that won't work because the margin can be supressed when it appears at the top or bottom of a page), or use a visible separator such as murg suggested, or else use a different style to start the new scene such as small-caps, italics, raised-cap, etc.

[JSWolf]

When blank space is used to denote a section break, I make sure it's at a size of 2em.

sectionbreak {
margin-top: 2em;
text-indent: 0
}

<p class="sectionbreak">First paragraph after the section break</p>

But, in order for this to actually work, you need to set a widow and orphan to 1.

body {
widow: 1
orphan: 1
{

Otherwise, you could get space at the bottom of the screen that looks like it could be a section break.

[GeoffR]

Ah yes I forgot about orphans and widows. Those used to reading with orphans:2;widows:2; are going to be quite used to seeing large gaps at the bottom of the page, and even though those gaps only happen when the page breaks within a paragraph, they are going to make it hard to notice a that a single blank line at the bottom of the page is actually a section break.

[Klecks]

Originally Posted by GeoffR

... not just 2em margin, that won't work because the margin can be supressed when it appears at the top or bottom of a page ...

I suggest using padding-top instead.
Padding-top is visible even if the scenebreak happens to sit on top of a new page.

And orphans can be useful for scenebreaks.
For example I don't like to have only one or two lines of a new scene on the bottom of a page. I prefer to have the new scene after a scenebreak pushed to the next page if the old page has only room for 1 or 2 lines.
With:

body
{text-indent:1.3em;
orphans:1;
widows:1;}

sectionbreak
{text-indent:0;
padding-top:2em;
orphans:3;}

and a scenebreak on the bottom of the page I get:

1. the scenebreak pushed to the next page and
2. starting with a 2 em visible gap on top.

[Jim Chapman]

Originally Posted by Robotech_Master

Thanks for reaching out, and thanks for your willingness to look into fixing the program. I've emailed you one of my e-book files separately.

OK I have fixed Freda so that it will insert a vertical break of one line height when it encounters a DIV or P consisting of only &nbsp; . That update will appear on the Windows 10 Store in the next couple of weeks (the delay is because the release also includes a bunch of other stuff, some of which could use some testing! ... notably the handling of right-to-left scripts).

Anyhow, if anyone out there has suggestions for other 'magic' character sequences that I ought to interpret as section breaks, please let me know, and I will test for them too in Freda's text-parser.

[HarryT]

Originally Posted by JSWolf

When blank space is used to denote a section break, I make sure it's at a size of 2em.

sectionbreak {
margin-top: 2em;
text-indent: 0
}

<p class="sectionbreak">First paragraph after the section break</p>

But, in order for this to actually work, you need to set a widow and orphan to 1.

body {
widow: 1
orphan: 1
{

Otherwise, you could get space at the bottom of the screen that looks like it could be a section break.

None of that will help on a reader which ignores the book's CSS, though, Jon, and that's what we're talking about here. Moon+ is a great reader in every other respect, but it completely ignores the CSS in the book and imposes its own.

[Ripplinger]

Originally Posted by HarryT

None of that will help on a reader which ignores the book's CSS, though, Jon, and that's what we're talking about here. Moon+ is a great reader in every other respect, but it completely ignores the CSS in the book and imposes its own.

Have you tried Moon+ with the setting to disable CSS unchecked though? I've never done a code-by-code comparison to see if it still ignores parts of the CSS, but books then really look the same as on my ereaders to me.

[HarryT]

Originally Posted by Ripplinger

Have you tried Moon+ with the setting to disable CSS unchecked though? I've never done a code-by-code comparison to see if it still ignores parts of the CSS, but books then really look the same as on my ereaders to me.

Yes. It's still very flaky. It seems to use some of the CSS, and ignore other parts. For example, I've been completely unable to get it to honour my paragraph style CSS which gives me no indent on an initial paragraph, and an indent on subsequent ones. It just imposes its own paragraph styles regardless of the setting of the CSS option.

It's really annoying that so many of the Android reading apps seem to be incapable of doing something as elementary as displaying a book in accordance with what the formatting in the book specifies, rather than thinking that they know better than the book's creator.

[Ripplinger]

Originally Posted by HarryT

Yes. It's still very flaky. It seems to use some of the CSS, and ignore other parts. For example, I've been completely unable to get it to honour my paragraph style CSS which gives me no indent on an initial paragraph, and an indent on subsequent ones.

That's really odd. I just checked a book I scanned that I know has the same, no indent on initial paragraph in a chapter, then indented on subsequent paragraphs, and Moon+ displays it exactly the same as my ereader does.

I'm wondering if the type of phone, or Android version on it, causes some differences in how Moon+ behaves? I'm using a Samsung Galaxy S4 with Kitkat (4.4.2), and Moon+ Reader Pro 3.5.0.

[Robotech_Master]

Originally Posted by Ripplinger

Have you tried Moon+ with the setting to disable CSS unchecked though? I've never done a code-by-code comparison to see if it still ignores parts of the CSS, but books then really look the same as on my ereaders to me.

As I stated in my previous message, I've tried that. For some reason, when I uncheck "Disable CSS," it still strips out the blank lines, even if I leave the "strip extra blank lines" option unchecked as well.

But if I use the "Preview with publisher's settings" button (which I had to enable in the settings), there those blank lines are—but it's also locked into a small sans serif font that I can't resize or change, and it scrolls instead of paginating. Weird, huh?

[Ripplinger]

That's why I'm thinking Moon+ must behave differently depending on phone and/or Android version. My blank spaces are still there on the phone with Moon+, but I always use <p>&nbsp;</p> wherever I want to ensure a blank space remains.

[Robotech_Master]

Originally Posted by Ripplinger

That's why I'm thinking Moon+ must behave differently depending on phone and/or Android version. My blank spaces are still there on the phone with Moon+, but I always use <p>&nbsp;</p> wherever I want to ensure a blank space remains.

From peeking into the innards of the EPUB files Scrivener generates, that's what it does, too. And apparently Freda wasn't honoring those—but Jim's post upthread indicates it soon will.

[jackie_w]

Originally Posted by HarryT

Yes. It's still very flaky. It seems to use some of the CSS, and ignore other parts.

That's my experience, too. Enabling Preview mode displays the css better but it has its own drawbacks, e.g. each chapter scrolls rather than pages, and unless you take precautions it's all in sans-serif.

Originally Posted by HarryT

For example, I've been completely unable to get it to honour my paragraph style CSS which gives me no indent on an initial paragraph, and an indent on subsequent ones. It just imposes its own paragraph styles regardless of the setting of the CSS option.

I've seen this problem when the epub has used <div> rather than <p> to tag the standard body paragraphs.

Originally Posted by HarryT

It's really annoying that so many of the Android reading apps seem to be incapable of doing something as elementary as displaying a book in accordance with what the formatting in the book specifies, rather than thinking that they know better than the book's creator.

In my experience the Android apps that use the ADE renderer seem to behave better css-wise than the ones that don't.

[Jim Chapman]

Regarding the 'right' way to represent vertical space in epub files: It is pretty clear that using a p element containing only &nbsp; is an ugly hack, and is the wrong thing to do, in terms of web standards (see for instance the discussion at http://stackoverflow.com/questions/1...-editor-or-not ). The right thing is certainly to use CSS styles to add a margin of the appropriate size. I'd hope that the implementers of Scrivener etc. will get round to fixing their program at some point, to do the right thing. I don't feel especially proud of having changed Freda to fit in with their broken interpretation of the xhtml standard ;-)