I’ve searched the forum but can’t seem to find any information on this.
I’m pulling my hair out trying to retain font information after compiling to MOBI. The font size etc is all kept in the final MOBI file, but there is no reference to the names of the individual fonts I am using.
If I use KindleUnpack to look inside the MOBI file I can see that the Font folder is empty, so it is not embedding the fonts. Not only that, it doesn’t even remember the font I have set for it.
Surely I’m missing something simple, as it seems crazy I can spend so long perfecting the format of my documents only to have this information stripped out on compile? How do I embed fonts in a compiled Mobi through Scrivener?
(I am using freeware licensed fonts that I am able to distribute, of course! Though if I get it working I may license another, but it’s not worth doing that unless I can actually get my custom fonts actually into the file)
Help would be very much appreciated.
E-readers use the font that the reader wants to use, and the reader can only choose from the limited number of fonts supported by the device. You can’t fix the font.
I am aware of this, but it is possible to embed fonts in e-reader formats and I’d like to know how to keep this information from being stripped by a Scrivener compile, or if I have to do it manually after. The e-reader I am using is capable of respecting a font embedded in the file, and that’s all that matters for my purposes.
If I have to do it manually it looks like it’ll be a right mess as Scrivener appears to be a little arbitrary in how it defines the CSS classes it generates during compile, so the same format across different documents in the same project get different classes.
In which case I don’t know if anyone knows if it’s possible to flag areas of text with metadata that will survive the compile process, so I could at least script the fixes to the file after compiling?
But hopefully there’ll be an answer to the original question. Thanks anyway
Hopefully I won’t have to abandon Scrivener for the final stages of creating the files, it had been so convenient up to now
Perhaps this still holds in terms of Scrivener…
If readers can (and do) choose their own fonts and scaling …
No, you didn’t err at all, and I’m sorry if your embarrassed emoji is genuine - you have no reason to be embarrassed, I’m grateful you’re trying to help
Thanks for that post… The quoted Keith there is partly right - you need a licence to distribute a font, which is why I said I’m using freeware fonts, and just working on my own e-reader (though for many freeware fonts I could distribute more widely if I wished!)
I fear he may unfortunately be totally right that Scrivener simply doesn’t support it when compiling an e-book, which is a massive shame and makes the compile process a complete pain for me.
I suspect in that case I’ll have to compile to HTML, and write a script to edit the CSS manually, then use some other software to embed the font into a recompiled EPUB or MOBI. Luckily I have found since my last post that exporting to HTML doesn’t strip the font metadata so I can work with that, probably. Although whether or not it’s easier just to abandon Scrivener and work entirely elsewhere from this point I’m not yet sure.
Ah, wait, I’ve just looked at the post again… Keith is the actual developer of Scrivener. So unless things have changed a lot in three years it’s likely that Scrivener simply doesn’t support this and I’ll have to roll my own export/compile process.
Thanks again Briar
Scrivener does not support embedding fonts, so you’ll need to do this post-compile, however you choose. Sigil is a great ePUB editing tool, and you could work with the CSS and XHTML there; I’ve never tried, but I imagine you could handle the font embedding with that. From the ePUB you can use KindleGen to create the Amazon-approved .mobi file. Alternatively you could compile to RTF and do the formatting in Word with whatever macros you’ve got, if you already have a method from Word that works well for your ebook publishing. Again, I don’t know how to embed fonts directly using that, but I’m sure a Google search will turn up some help if it’s not something you’ve done before.
Thanks MM, I appreciate it
It’s a shame that even if it doesn’t support embedding fonts, it doesn’t just leave in the font metadata (i.e. “this bit is in XYZ font”) - would make life a lot easier later.
I have many hours of HTML/CSS work in other contexts, and it appears that the various ebook formats are simple to work with if you already know CSS. Would have been nice to avoid the need for it but such is life.
Have a nice weekend and thanks for the help, all
Defining a font without actually including the embedded font produces problematic results on a lot of e-readers, most importantly the Kindle Paperwhite where if it finds a font definition and doesn’t have a font to match it, it defaults to Helvetica and cannot be changed by the reader.
That’s useful to know, thanks klambert