Compiling an epub in Scrivener

I am trying to compile an epub in Scrivener (3.2.2) MacOS (11.5.2) but when I adjust say, paragraph spacing or heading size, it doesn’t carry through to the new epub. Am I neglecting a necessary stage in compilation?

It’s very difficult to change the formatting in an ePub, because the reader software allows users to override most settings. Do you get the changes you want if you compile to another format?

I should have said that this problem is not a consistent one. Previous adjustments to spacing and heading size have actually transferred successfully sometimes in the past. I’m not sure if I am missing a stage in the compiling process. As for compiling to another format to see if the changes translate, the only other option in Scrivener I can find is .mobi which doesn’t function (plus, Amazon don’t accept .mobi format anymore). I compiled the same file to pdf and it works but that’s no good for a reflowable book. I am beginning to suspect that Scrivener is not a very friendly platform for producing ebooks.

Please open a support ticket, here:

I’ll need a bit more information to provide relevant suggestions.

Can you point me to an instructional video on how to create a reflowable .epub from Scrivener using MacOS?

Any compile to ePub is reflowable.

I know, but there are certain things like line spacing and heading size that don’t translate completely. I was wondering if there is a way to make certain these characteristics remain in the final .epub

Line spacing in particular is deliberately stripped from body text because that can get your book rejected from some vendors, and it rarely works anyway since most ereaders leave that particular setting up to the individual reader’s preference.

As for heading size, normally those would be added to chunks of text via section layouts, and those are all set up to work out of the box. If you’re typing them into your editor then you should be using styles to ensure the formatting that can be expressed into ebook formatting is retained. If you just change font settings, it’s possible to see them lost since Scrivener is going to be doing its best to make all of your paragraph text look uniform, and without a style it can’t know you meant anything special by changing the font size.

I always use styles, but not all are translated in the end. Thanks for the info. One more thing: Can you tell me what is the best application to preview the epub, so I can see if the contents links work?

I’d need a more specific example of a style that doesn’t preserve its settings to explain what happened, but a rule of thumb is that if you want a style to preserve a certain characteristic it needs to save that characteristic in its settings. If you don’t tick the Font size checkbox for example, then whatever font size you see in the editor is not a part of the style, and won’t be preserved, just like any other direct formatting changes made to the text on top of the style would be lost.

One more thing: Can you tell me what is the best application to preview the epub, so I can see if the contents links work?

I use Sigil because it not only displays the ebook but lets you see why it looks like it does, and lets you make modifications which are displayed in the preview in real time. It’s a great tool for coming up with adjustments that you can take back into your compile settings. Using a regular viewer is usually very opaque, and one can only guess as to why they are seeing what they are seeing.

But it’s not really a standard viewer, it is an editor first and foremost. What I use for simple previewing is Calibre’s ebook viewer.

I know my opinion on this is not shared by everyone, but I think it is confusing to use styles. In my manuscripts, there are only basic formats (bold, italic, standard). Any formatting that is to appear in the eBook I basically realise via the compiler and various sections. So I stick to the original idea of the developers to separate the content from the format. It is possible to use styles in the editor, but this confuses many users who then automatically expect the editor format to appear exactly like this in the ePub.
My wish would have been to dispense with the style system altogether and perhaps use a markup editor instead, which the compiler then outputs on the basis of the section layout. I can only strongly recommend familiarising yourself with the compiler functions and the principle, because the flexibility that the compiler gives us is ingenious.

1 Like

I have to agree with @anon91757562 in that styles, in the context of compilation, are confusing, especially as so many authors are accustomed to how they work in word processors such as Word. It wasn’t until I read a book on compiling, as opposed to using Scrivener in general, that I truly began to understand the flexibility Scrivener offers. (Sadly, that book has never been updated for Scrivener 3.)

I like Thomas’s suggestion of separating paragraphs that need a different paragraph style (e.g., block quotes) into separate texts, and applying section layouts. It would certainly reduce the number of times I sit wondering, “Now why did my style not come through? Did I forget to make a corresponding style in my compile format again?

2 Likes

The only point I would make to this is that styles do give you a way of defining structure in your text, by applying a class name to the paragraph or span—or as you say having content separate from format. You could try to put everything into Section Types, but that won’t always be practical, especially for span-level formatting—and I would argue that wouldn’t be good HTML practice either. There is a reason we can class and style down to the character level. Large div/section level elements (where Section Layouts shine) are not the only answer, and would be a non-standard way of formatting such things as block quotes (and in that case there is a dedicated element specifically for it, which the styles feature hooks into, rather than <p>).

Now, one can use the style mechanism to directly apply format as well since Scrivener will automatically generate CSS, but that’s a personal choice. You can also go into the CSS pane and override it completely, making such creative constructs as floating tip boxes, images that operate as full page, custom listing formats and so forth.

1 Like

Thanks everybody for your input. I am rapidly realising that I’m out of my depth here. I am coming from a traditional print publishing designer background (InDesign (MacOS) to pressready files). I have no coding skills and need to perhaps start at the beginning with ebook construction basics. I think I expected more similarities with control over design than Scrivener (or any other ebook prep software) offers. To be continued …

1 Like

From my perspective, the thing to remember is that EPUB gives more power to the reader to control how the document looks. Hence the publisher has less control over things that might be controllable in publishing to paper where the reader has no control–other than the reading light. :wink:

Yes, print and ebook publishing come from completely different worlds. One from a tradition that goes back centuries, with much of the software metaphor and capability surrounding it as echoes, if not direct implementations, of those traditions. The other was essentially invented by nerds that knew little of page layout, or the difference between a well-designed justified text, and a machine spreading letters and words apart haphazardly. Ebooks come from a web development background, and as such its conventions and metaphors are all new, and at times do things that don’t make sense for books, because the technology was aimed at making web sites originally. It has come a long ways, to be fair, and will continue to improve, but you will have to make compromises that may make you cringe. With InDesign you have a whole palette of options to fine-tune hyphenation policy, and can tweak individual lines to make them look better. With ebooks, you can choose whether or not to have hyphens, and hope for the best.

As a word of encouragement, and to extend a bit from what @rms had to say, along with the above, does mean it’s a lot easier to learn. As someone that has gone through the education phase of print design, ebooks should be a snap.

For one thing, there is no coding involved! I won’t blame you for thinking you’re looking at “source code” if you tried opening your book in Sigil. There are certain similarities in appearance when you look at CSS and C++. But both HTML and CSS are remarkably easy to learn once you get over the initial “what is this spray of punctuation I see” phase. I would even go so far as to say that how they work is logical and thus capable of deduction, past that point.

A couple of books or tutorials on the matter, and a weekend set aside, should be all you need to feel more confident when looking at an ebook internally, and if you enjoy it, it can be a rewarding skill as you’ll be able to create distinctive and well-designed ebooks that set you apart from the masses using template-drive software and default settings. (That screenshot by the way is 99% doable in Scrivener, with that 1% being a 5-second drag and drop operation in Sigil after compiling, to add the font file resources.)

3 Likes

Can anyone in this thread recommend good resources to this end? My tiny amount of web design experience goes back to when the web was very new and, well, things have changed.

Thanks!

Thanks for the encouragement. It sounds like you have a broad knowledge of the pitfalls of designers’ expectations in the crossover from print to web. Good to hear I’m not alone in my frustrations. I, like kewms, would like to be pointed in the direction of these “couple of books or tutorials on the matter.” As for Sigil, I have downloaded it to my mac it won’t install properly. Have followed installation instructions from Sigil site but won’t install.

I’m probably not the best person to ask, as the books I learned from are twenty years old now, and started with something along the lines of “First you will need to download Netscape Navigator”. :slight_smile: I’ve kept up by searching for things I need to do as I need to do them (so like, “css drop cap” and you get piles of articles on how to do it), so I’m not terribly out of date—but that in and of itself isn’t as important with ebooks since there is a wide gulf between web design and ebook design, in terms of how much technology you can use. It’s a lot more basic, and old school for that matter.