I’ve poked around for about an hour now and it seems Scriv 3 beta STILL does not preserve font face specified in the Style section. It works only in RTF and PDF. It doesn’t matter what I tell it to do with ePub–it just converts to Times New Roman. Either I’ve missed the setting to undo this, or the devs still haven’t given Windows users this simple thing.
This has happened to me as well, although a few RCs back, I WAS able to export epub with custom formatting.
Okay, I read on another post that Scrivener strips fonts from ePub compile because not all fonts are free to use and Scriv doesn’t want to be complicit in unintentional copyright infringement.
At least I can edit the final ePub compile with Calibre.
Another potential issue is that e-readers generally allow the user to specify their preferred font, overriding the author’s choice. It’s very difficult to force any kind of formatting in ePubs.
Katherine
Yeah, you definitely do not want to be overriding body text font family settings, and many readers won’t even let you try (you should be previewing your book formatting in end-user tools, rather than Calibre or Sigil, both of which use rather stock web rendering previews that are way more permissive, and powerful, than typical eInk or applet readers in phones and such). It’s in the guidelines for most vendors I’m sure, to never do that.
As for chapter headings, epigraphs and other special text, sure, it’s fine to embed fonts and in most readers that will work. We could add code that makes it possible to do that, but we don’t because this is the sort of thing that should have a little friction in it. The legal issues of embedding fonts are real, and it’s really expensive to do things legally, which is something the large majority are unaware of (even professional designers are often ignorant). For example, in our own user manual PDF we have a few fonts we selected, and we spent thousands for the rights to use them in the distributed PDF. That’s the kind of money you will be spending if you wish to embed fonts in your books, too.
So we’d either need to implement a lot of very complicated code to handle encryption (as is often your obligation) on a per vendor basis, and somehow verifying licensing rights, etc. It’s a mess, or we could just do the more sensible thing and deliberately strip out font family declarations (which are useless without embedding the fonts).
Yes, that is what we are doing. 
We have many lines of code that, on purpose, remove your font assignments from the automatically generated HTML that the text engine outputs. We do this on the Mac as well, so stating we haven’t “given Windows user this” is a misnomer as well.
If you really want to though, and you know what you are doing and have the right to distribute the font in your books—then go for it. There are tools for doing that. It’s a few seconds of effort after you’ve compiled. It’s really hardly worth talking about. I could have set up fifteen books in the time it took me to write this response.
Hi Amber,
does your warning “you definitely do not want to be overriding body text font family settings” also apply to such as:
body
{
font-family: serif;
}
or only for “named”/embedded fonts which are part of the EPUB file?
I think most e-readers would acknowledge this setting. They would use their default serif or sans-serif font.
1 Like
All of this is of course worth checking out with the individual vendors you upload to in their style guides and such. Some may have more flexibility than others.
That said, a general directive like that to use a class of font is fine, as far as I am aware; it will at most just be ignored by ebook readers (I tend to see ‘monospace’ respected more often). I was speaking mainly to overriding the body font with a font that is embedded in the ebook file, and that is generally discouraged by upload guidelines.
1 Like