Variations in epub output on different devices

Hi, I would like to know how to reconcile the difference I get between the viewing my output epub file on a desktop reader (for testing) and my Kobo reader (the only hardware reader I have)

My issue more specifically:
I am getting carriage returns between paragraphs in my text (as intended) when viewing the file on my desktop reader (for testing), but not on the Kobo H2O reader. These are the two output devices I am using to test formatting on.
btw. The carriage returns are inline in my text documents and not a setting in the compiler.

p.s. am still on the steep end of the learning curve with scrivener and compiling.

When you open your e-book in Sigil, what do these
Carriage Returns look like?

Is there a setting in your e-reader about paragraphs, <p></p> or <br /> tags that interferes?

Have you brought formatted text from Mac to Win? (which should’t matter, but anyway)

I am a noob to Scrivener, so your questions are beyond me.

What is Sigil (for)?
(I looked it up, but it seems to be a Scrivener replacement)

And: Is there a setting in your e-reader about paragraphs, <p></p> or <br /> tags that interferes?

Not 100% sure about this one. I do not think so.

I am using Sumatra as my epub reader on desktop, and Kobo H2O as the hardware book reader for testing.

Sigil is an e-book editor. It shows the XHTML-code that the e-book is constructed in.
Scrivener is for writing, but as you know for generatie e-books as well.

I’ve installed and tested Sumatra PDF-viewer and am not really impressed by its capacity to show e-books.
Maybe install Calibre and use Calibre’s E-book viewer?

I would definitely look into installing Adobe Digital Editions for desktop proofing. This is the ePub rendering engine that is used by the majority of epub-based ebook readers out there, including Kobo. There may be minor layout differences on account of the core engine being a different version on your device than what is latest from Adobe, but overall that should give you a very accurate preview. It won’t replace hardware testing, but it will shorten the amount of time involved in fine-tuning design, first.

But that aside, you really do need an actual ebook editor for most things involved in publication—even if you aren’t using it to edit the compiled result for fine-tuning. Not being able to view the source HTML and CSS directly is just flying blind. These are not replacements for Scrivener, they have almost no overlap in fact. Scrivener cannot directly edit ePub files, it only generates them. Meanwhile ePub editors would be a disappointing experience to use for actual writing, in my opinion.

For instance, there is no such thing as a “carriage return” having any meaningful result in an HTML file. You can have a thousand empty lines between paragraphs and it won’t show up in output. All that matters it the HTML markup itself. So when you say you have actual carriage returns in your ePub, I’m not sure what that means.

I get your explanation.

My understanding, as it stands now, is that Scrivener can compile ebook formats such as epub and “pdf”.
But it will never be able to bridge the ever changeing landscape of ebook readers, ebook reading apps on phones tablets and computers, or whatever other devices appear (vr?)

So there needs to be some bridging tools. This is where Sigil, Adobe Digital Editions, etc… come into play.

I have opened my book in Sigil and can see the XML or HTML and CSS files.
I am assuming that I can edit the HTML and CSS in these files and export from Sigil, then check the resulting epub in Adobe Digital Editions.

If this is all true, then I had better brush up on my HTML understanding.

@Mastercore: My understanding, as it stands now, is that Scrivener can compile ebook formats such as epub and “pdf”.

But it will never be able to bridge the ever changeing landscape of ebook readers, ebook reading apps on phones tablets and computers, or whatever other devices appear (vr?)

Mmm, maybe? I don’t know if I quite understand what is meant by “bridging”, in this sense. Perhaps you mean that successful book design as a concept rarely involves one single tool? If so I would agree with that.

Scrivener produces an .epub file at a level of sophistication that few writing tools can match; as such, with a refined workflow, one would be able to use it and only it. However to get to that level of refinement we often need to be able to develop our designs in tools that show us the actual inner workings of the ePub itself. A generator, like Scrivener, doesn’t do that. It takes source data and uses instructions to generate a book procedurally—in order to understand what it generates we need a tool that can more correctly examine it, rather than simple view it (in an often very opinionated fashion, as reader-focused software will tend to do, displaying special fonts, themes and so forth).

Not only is that more efficient for troubleshooting, but for design as well. Implementing a custom book design in Scrivener alone would entail dozens of wasted hours spent waiting for the compiler to finish, while in Sigil changes made to the CSS happen instantaneously, right in the preview pane as you type in formatting attributes.

Here’s the key though, once you figure out what needs to be adjusted, you can take those adjustments back into Scrivener—either at the data level (what you type in) or the instructions (compile settings, like pasting some custom CSS into the CSS compile format pane). Test that, and if the new compiled result looks the way you want now, you’re one step closer to not needing a “bridge”, as I interpret it. Thus Sigil is more like a tool to help us refine the compile settings toward a point where we no longer need the helper tool, and have a simple one-click workflow.

I am assuming that I can edit the HTML and CSS in these files and export from Sigil, then check the resulting epub in Adobe Digital Editions.

Almost! Since Sigil is an ePub editor there is no export. You just save the result right in place and then refresh your reader to see the changes.

If this is all true, then I had better brush up on my HTML understanding.

Yup! And that’s what I mean about not flying blind. A blank space might not even exist at all in the original HTML/CSS of the ePub—it might be something introduced by the layout choices of the book reader’s theme settings. You’ll never know until you’re looking at the reference copy itself.

2 Likes