Over the last few days, I’ve been involved in an interesting conversation on MobileRead. It started when I posed the question why so many e-readers seem to ignore extra blank lines to separate sections in stories. I’ve complained about readers like Moon+ disregarding them before. When I generate EPUBs using Scrivener, it uses those extra blank lines—and likewise, so do many of the e-books I download from Baen. Trying to read those on a reader like Moon+ swiftly becomes an exercise in frustration, as there’s no visible sign of where one section ends and the next begins.
I reached out to Jim Chapman, developer of a Windows 10 e-reader app called Freda, about it. I really like everything else about Freda, and want to give it a good review for TeleRead, but the current version of it has that same annoying behavior and I asked if it could be fixed.
Jim took a look at the way the e-book file did things and determined that it used a paragraph with a non-breaking space character within it to create the blank line: <p> </p>. Some of the other participants in the thread said that they coded section breaks in their e-books in the same way. Effectively, this creates a paragraph comprised of nothing but a single non-breaking space character—a character that is invisible and can be represented by HTML code.
Jim said that he would put in a tweak in the next version of Freda, expected out in a couple of weeks, so that it would stop disregarding those non-breaking space paragraphs. (I’ll do a full review of that version for TeleRead.) However, he added:
Regarding the ‘right’ way to represent vertical space in epub files: It is pretty clear that using a p element containing only 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 😉
This sparked an interesting discussion about the “right” way to do such things. MobileRead user Toxaris put it eloquently when he replied:
I don’t agree. It is ugly, but it is not wrong even when considering web standards. After all, an e-book is not an webpage even if it uses web technology.
Like I said, the purists use margins to create the empty lines and they are of course correct. It is the ‘best’ way to do it. However, the sad part is that a lot of reading programs and even some readers ignore parts or even the complete stylesheet and overrule it with their own. This of course removes all the section breaks you had. Using the [noparse]<p> </p>[noparse] is a fail-safe method and completely legal/allowed. Empty paragraphs should be ignored according to the web-standards you mention and usually are. However, this is not an empty paragraph and should not be ignored according to the same standards.
So, unless all the readers/reading applications play ball, it is the only failsafe method. Personal feelings aside of course.
It doesn’t do much good to set margins in the CSS if the e-reading app ignores them—and many of them do. You can disable that on some of them, but not all of them. Furthermore, many commercial e-books (such as those I mentioned from Baen) use this non-breaking space technique to insert extra blank lines, too—and Scrivener, intended as a one-stop shop for e-book creation from manuscript to EPUB, does it too. (I posted an inquiry about this in the Scrivener technical support forum, but no one has replied yet.) MobileRead poster Ripplinger pointed out that even Calibre retains these non-breaking-space paragraphs when you tell it to remove all spaces between lines. “It’s a simple solution that just works, even if not an elegant solution or correct.”
Books created with that method 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. So if readers like Moon+ and the current version of Freda treat a non-breaking space paragraph as empty and skip it are supposedly honoring the XHTML standard for empty paragraphs, it seems this is one of those cases where adherence to the so-called “standard” is actually in the vast minority. (Just as EPUB is the “standard” for e-books, but the vast majority of commercial e-books actually sold are in Kindle format.)
I was discussing this with my friend and occasional TeleRead contributor Felix, and he pointed out that HTML actually has a semantic element for indicating a section break: <hr>, which by default produces a horizontal rule across the page, but can be defined to appear any way you want it to—including as a blank line. But from my point of view, you would run into the same problem as with using CSS to set an upper margin on your section: many e-readers simply ignore it.
It puts me in mind of the saying, “If it’s stupid but it works, then it isn’t stupid.” If <p> </p> is nonstandard and wrong, but it’s also simple to put in, and is likely to be honored even when the e-reading app throws CSS out the window, then is it really “nonstandard and wrong”? It’s like the “descriptivist” vs. “prescriptivist” debate about dictionaries: should they reflect the way people use the English language, or should they tell people how they should use the English language? If many more e-readers honor non-breaking space sections than not, it seems as though that is the new standard for separating sections.
So, the world of EPUB e-readers is kind of a mess when it comes to applying standards. Whether any given reader supports CSS at all is kind of a toss-up. When I look at all this, it just makes me wonder—if apps can’t even agree on simple matters like CSS and paragraph separation, how can they hope to tackle really big issues of support for multimedia, interactivity, and other ways to extend the format? Do we really even have an effective EPUB “standard” at all? Maybe all those people who worry about “improving” the next generation of e-book should set their sights a little lower and see if there’s a way to get the current generation of e-book readers to agree with each other first.