When I compile to epub, two things are not quite perfect. Text formatted as small caps comes out lowercase, and empty lines between text documents aren’t visible (they are in docx, and the compile settings include the same setting for compilation to epub). Is there a way to retain these details when compiling to epub?
That might be due to a setting in your ereader…
See if it has an option somewhere that says something the likes of “display in original/source formatting”.
If that ain’t the problem (I can’t know for sure, I never used small caps in an ebook), you might end up having to use real caps, but making them of a smaller font size, using a character attribute style.
Can’t have empty lines in an epub/ebook.
HTML doesn’t allow it.
You have to insert a non-break space in them, or use the proper space-after for the last paragraph of the document.
I by far prefer to use a non-break space.
If you want that “empty but not empty” line to be visible while working in Scrivener, rather insert a special character (one that you dedicate to that and only that), in the editor, on that line you wish to look empty (something funky and visible, like ֎), and have the compiler later replace it with a non-break space. 
That’ll allow you to quickly make sure you didn’t forget any, as non-break spaces are otherwise invisible. (Or even hard to see when showing invisibles.)
3 Likes
should use   and not because ePub3 doesn’t allow it. 
1 Like
To my recollection, Scrivener compiles non-break spaces to & #160;
So that should be OK.
But I guess that this would be true if using one of the two (rather than pasting a real non-break space, I mean the character) in the compiler’s replacements.
Thanks for the ideas. Thing is, though: the empty lines are before-section and between-sections items. They are scene separators; I write my scenes in separate documents. Manually adding paragraph spacing or a special character defeats the purpose of setting up the spacing in compile settings.
OTOH, if there’s a way to set a custom separator to HTML code 160, that would do the trick. I’m going to try that.
ETA: Using the 160 HTML code as custom separator inserts literally that into my epub as separator.
ETA: Same thing if I use a temporary special character as separator, and have the compiler replace that with   ; The separator is literally   ; in the epub in that case as well.
ETA: Things that don’t work either: using the Single Return separator, entering a space as custom separator, using a non-breaking space copied from Word as custom separator, using a non-breaking space copied from Scrivener itself as custom separator.
In all these cases, blank line scene separators are omitted in the epub, and text sections jammed together.
Which is odd, really, because the compiler does a good job of capitalizing the first three words of each section, which looks hideous with the sections jammed together, and would look great with the blank line above it.
So the question is: how do I enter HTML character codes into compiler fields?
And on a related note: if epub doesn’t allow empty lines, wouldn’t it be logical for Scrivener to always compile an Empty Line separator to character 160 when compiling to epub?
Try pasting the non-break space character as a separator.
[Edit] paste non-break space + carriage return, if it seems not to work at all.
But my initial recommendation was for you to paste the non-break space character in the compiler’s replacements, not   textually. You don’t seem to have tried that, and I believe that it would work.
(You have to insert it to the editor from the character map, then, showing invisibles, copy paste it from the editor to the compiler or compile format’s replacements.)
And I also meant for you to insert the special character (or the non-break space) at the end of your documents. Although it doesn’t actually matter that much : If the compiler was able to replace the special character (that you shouldn’t need, if using separators – it should work with the non-break space character and no replacements) with  , it should be able to do the same with a non-break space, which in turn the compiler should spit out as  .
I believe it would, yes.
1 Like
Yes! Non-breaking space + carriage return, copied from a Scrivener text file and pasted into the custom separator field, did the trick! Thanks a bundle, @Vincent_Vincent !
Diving into the small caps issue next.
1 Like
Have you tried without the carriage return ? (It might be adding an extra line. I am not sure.)
[EDIT] Ah! Nevermind : if it does, that line will end up empty and will disapear. 
But it will show when compiling to a format other than epub…
Perhaps you should test without the carriage return right away, and be done with it.
If it works without it, leave it out.
This way your compile format will work for both your compiles.
Tested. Doesn’t work, but it does work with the CR, and the separator settings for epub are separate from those for docx, so the CR is not an issue.
1 Like
Hm. No settings available on the Tolino device for original formatting or anything along those lines.
A different epub (the official epub edition of my first book) does show small caps as small caps, and the epub I’m testing does show small caps in the Calibre epub reader, just not on the Tolino.
Any other ideas?
And just to cover all bases: despite the fact that small caps look weird in the editor (I read somewhere that they’re simulated in the editor by displaying normal caps in a smaller font), I’m assuming they are supposed to compile to ‘real’ small caps?
1 Like
I just ran a test and indeed, they don’t compile as small caps.
I’ll let you know if I can figure out a fix.
(Other than the one I already suggested in my first reply. And that I’ll try right away.)
In that case, it’s odd that the Calibre reader does present them as such, isn’t it?
I made a mistake, I confused the chapter title from the toc (which had only one listing) with the content itself.
I am starting over.
. . . . . . .
Small caps work fine for me.
. . . . . . . . . . .
So you are saying that your small caps show fine in calibre reader ?
It that’s so, the issue can’t be with Scrivener…
It would then be more likely an “issue” where some ereader apps (mostly android ones) ditch the formatting altogether. They will however apply inline formatting (meaning whatever instructions they get from the code line), while ignoring the CSS style-sheet.
Perhaps the ebook you are comparing with was rather encoded like that. (?) – Did it come from Scrivener?
[EDIT] It should’ve worked even then…
This is what it looks like in HTML after compile:
. . . . . . .
At this point it is becoming confusing.
I need you to clarify whether your compiled epub shows right in some places and wrong in some others, or wrong everywhere, no matter the ereader… ?
The epub I compiled from Scrivener shows small caps perfectly in the Calibre Reader on my PC. When I send it to my Tolino e-reader device, all small-caps sections display as lowercase letters.
The epub that my publisher produced professionally for my previous book display small caps perfectly everywhere, in the Calibre Reader and on the Tolino.
You could see what he did different, using Sigil. Which is free.
Else, if you don’t have a problem with it, you could PM me that book, tell me which chapter and where to, and I’ll have a look at it for you if you are not comfortable with HTML.
I’m going to dig into that, either with Sigil or unzipping the epubs and diving into the HTML.
Once you’ve spotted what was done different, if it is only a matter of the language used inline, you’ll be able to auto-replace what Scrivener wrote as instructions for the small caps with whatever your publisher had.
Sigil screenshot :
Okay, looks like it’s a Tolino limitation.
Scrivener has compiled the small caps in my book to spans with font-variant:small-caps style, like you found.
My publisher, otoh, has created a custom CSS class for the small caps spans, and the style for that class does nothing but reduce font size to 80%. Apparently, they replace small caps by real caps for the epub version, and use this style to make them small.
So apparently. the Tolino device doesn’t support font-variant:small-caps, and my publisher fakes small caps for epub.
Okay.
If you really want it to work everywhere (or at least on your current device – see objection below), then I guess you’ll have to do it like that.
(You should survey and consider what % of ereaders it wouldn’t work for otherwise, then decide if it is worth the trouble or not…)
Not sure that I would, personally. – But then again, I did not survey the implications.
On the other hand, if you are accustomed to styles, it shouldn’t be too hard to do.
→ But: (and it is a big big but), since it’ll all then be controlled by the CSS stylesheet, you who wants it to work everywhere might end up with it working in even less places.
As I said, most of Android based ereaders ignore the stylesheet, and only respond to inline formatting.
On my end: I have to refresh my memory and run a test to see if character attributes styles end up in the stylesheet or rather inline.
1 Like