![]() (Just as EPUB is the “standard” for e-books, but the vast majority of commercial e-books actually sold are in Kindle format.) 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. “It’s a simple solution that just works, even if not an elegant solution or correct.”īooks 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. (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. 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. You can disable that on some of them, but not all of them. It doesn’t do much good to set margins in the CSS if the e-reading app ignores them-and many of them do. So, unless all the readers/reading applications play ball, it is the only failsafe method. ![]() However, this is not an empty paragraph and should not be ignored according to the same standards. Empty paragraphs should be ignored according to the web-standards you mention and usually are. Using the is a fail-safe method and completely legal/allowed. This of course removes all the section breaks you had. 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. Like I said, the purists use margins to create the empty lines and they are of course correct. After all, an e-book is not an webpage even if it uses web technology. It is ugly, but it is not wrong even when considering web standards. ![]() MobileRead user Toxaris put it eloquently when he replied: This sparked an interesting discussion about the “right” way to do such things. I don’t feel especially proud of having changed Freda to fit in with their broken interpretation of the xhtml standard □ will get round to fixing their program at some point, to do the right thing. I’d hope that the implementers of Scrivener etc. The right thing is certainly to use CSS styles to add a margin of the appropriate size. 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 …-editor-or-not ). (I’ll do a full review of that version for TeleRead.) However, he added: 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. ![]() 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. Some of the other participants in the thread said that they coded section breaks in their e-books in the same way. 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. 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. I reached out to Jim Chapman, developer of a Windows 10 e-reader app called Freda, about it. 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. 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. I’ve complained about readers like Moon+ disregarding them before. It started when I posed the question why so many e-readers seem to ignore extra blank lines to separate sections in stories. Over the last few days, I’ve been involved in an interesting conversation on MobileRead.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |