There are multiple layers to my question. I have scoured Google for this, but no clear answer has come up about my specific situation, as most answers pertain to fixed layout epubs—and Adobe Support is rather vague. I need this explained to me in layman's terms please.
I have seen multiple ebooks display featured fonts in Kindle without me having to download fonts to the device. Furthermore, I have seen other book formatting agencies use specialty fonts via Kindle. So, I'm wondering if leaving the font obfuscated strips the font on my end but maybe it will show in the published (purchased) version? This would be vital information to my clients, so any advice would help.
Some background: I format my work for my author clients with Adobe Fonts and use ID to convert my reflowable epubs to Sigil. Thank you in advance.
Copy link to clipboard
The short answer is that specifying/embedding fonts in reflowable EPUB (and thus Kindle) is a poor practice, and it often presents several technical hurdles, not all of which can be easily overcome.
That Adobe fonts are somewhat more tightly controlled than most, especially within the Adobe app ecosystem, doesn't help.
My sincere recommendation is that e-books, especially to the very closed and controlled Kindle platform, should not use specified fonts. The readers, again especially Kindle, really want full control of font, size, spacing etc. at the user's direction, and trying to impose a print-like format on this model is difficult, unreliable and contrary to the spirit of the medium.
Thanks for the advice! I am still left scratching my head, though, because it seems like it's possible, and I can't seem to find a clear-cut answer.
As far as I know, Adobe fonts are embedded in PDFs and EPUB s and saved on the computer in a hidden folder. They get encrypted names with a leading dot to make them invisible.
It's not that there is some secret only the pros or commercial houses know, other than an understanding of what's something of a tightrope walk to get the least-glitchy, most-compatible result. At a minimum, it's a careful adaptation of font use to the layout, limiting certain choices and compromising the result, just for the trivial win of using a specific font. And even then, any reader out there may decide its base system font is a better choice.
You can do amazing things with just a serif and sans-serif font, each with four faces, and judicious use of simple graphics and color. Getting bound up on the idea that a specific font or fonts are needed is just... the wrong road for e-books, and making the mistake of viewing a rich medium through the limitations of print.
If you must have a print layout, with fonts — use PDF. 🙂
You say there's a way to do it, and I don't mind learning to wrangle the fussy part if that means my client can feature a fancy chapter header in their epubs. I don't bother with main text, just the chapter headers.
Adobe Fonts - the subscription service - provide only activated fonts in Windows/Mac, and web fonts via specific HTML (and on Adobe's servers). Nothing else at all. You don't receive any font files (or if you happen to find them, doing anything with them is a breach of the license).
(I have no knowledge on the Kindle question, sorry).
The fonts are absolutely licensed to be embedded. Whether the reader app can take advantage of them is a whole different thing, I agree with @James Gifford—NitroPress on this...don't bother trying. Some apps may honor it for the initial display but ultimately it's the user that has control over it.
There are too many users that need to distance themselves from print and work within the rules and the spirit of the medium.
Copy link to clipboard
A shot in the dark, here, since you aren't very clear on where the problem occurs (or even exactly what the problem is).
When licensed fonts are embedded into a PDF or EPUB, they are encrypted and bound to that document so that they cannot be extracted and re-used. (Maybe this is what you mean by obfuscation.)
Since the encryption is tied to the document, it's possible that hacking at the doc in Sigil is breaking the connection and leaving the doc unable to decrypt the fonts on the fly, meaning it can't use them.
If that doesn't sound right, some more clarity on exactly what problem you're encountering, and at what point beween ID and Kindle, would help.
FWIW, I am strongly against editing EPUBs or workflows that depend on "fixing" an ID export using any post-export tools. If this is indeed Sigil mucking up the embedded fonts... another point to my dislike for the approach.
If you insist on specifying the fonts and don't want to try and fix this licensing/encryption issue at the export stage, you could substitute generic, free-license fonts in place of the Adobe ones. There are close analogues, if not more or less identical ones, for most of the common book fonts.
Just saw this! I just posted to your comment!
The issue: embedded, obfuscated fonts in the epub default to KDP's Bookerly font inside of Kindle Previewer. The only way those fonts show as they should is if I completely remove the obfuscation in Sigil and set it to none. Once I do that, the fonts show up beautifully in Kindle Previewer.
I have tested the files in Pagina's Epub Checker, and they all come out valid, even after I've de-obfuscated the featured font.
This is what leads me to question if removing obfuscation is okay to do and to then hand to my clients, since I'm not asking them to "move" or do anything with the font files themselves. I've read subsetting could be a good choice, since it removes unused characters from the file, therefore rendering it useless if the fonts are actually used outside of the epub after I've given it to my clients.
Adobe is not super clear on this, thus my four-layered question.
Sorry for the double comment. We can condense them into one next time you reply.
If everything works with the font encryption removed after export... it all comes down to whether you want to respect the Adobe licensing agreement for fonts, which I think most of us here would recommend, but is one solution.
Substituting free fonts for the Adobe ones would seem to solve both problems.
I've only done a little work in the direction of (1) embedding (2) Adobe fonts in EPUB, but have never run into the errors and problems you're reporting.
I still think the culprit is mucking with the EPUB file in Sigil, after export from InDesign. Try this: pass the unmodified export file to Kindle Previewer and see if the fonts work as intended, without errors, regardless of whether the book has the formatting you want.
You should always subset embedded fonts. It vastly reduces file size in most cases.
Thank you, James. No luck with your suggestion. Exporting to a reflowable epub and viewing it in Kindle just displays their Bookerly font. I see a ton of conflicting information on other forums, and they don't really ever come to a solid conclusion.
Upon doing more digging, I think I may have found my answer.
My current @Font-face coding looked like this with removing obfuscation in order for Kindle Previewer to display it:
src : url("../font/BreeSerif.otf");
However, when I changed it to (the single quotes vs the double quotes), it showed up in KP with only the IDPF method obfuscation, not Adobe's method:
src : url(../font/BreeSerif.otf);
All of this success made me want to jump with joy, BUT this method did not work with a different font my client bought and licensed, so I could not replicate the same outcome with her font. I wonder if it only pertains to Adobe fonts that I can use this way. So far, two of the fonts listed below meet my ultimate goal of 1) releasing the file without removing obfuscation (phew) and 2) displaying it in KP as it should. However, I also tried to subset the fonts, but only the client's would successfully subset and not Adobe's.
After all this is said and done, I did a test on the following fonts:
"Gonestone Signature" (client's licensed font)
"Bree Serif" (Adobe Cloud font)
"Chainprinter" (Adobe Cloud font)
It goes saying that I would love to also be able to successfully subset these fonts, but I feel like the universe hates me right now haha. I feel like all of this research and testing is two steps forward and three steps back.
I see a ton of conflicting information on other forums, and they don't really ever come to a solid conclusion.
Yes, well, there are reasons for that. But moving on...
About all I could say here is what I've already said — it's a fraught, uncertain process, the fixes are usually semi-hacks that may not be repeatable on other documents, and in the end, most EPUB readers and Kindle in spades do not like surrendering font and typography control, so the battle never ends.
Put another way, you can keep trying to find rational solutions, but it's not an entirely rational situation... so good luck. 🙂
Yeah. I clearly refuse to to give up haha! Thank you for your input. 🙂
I'll just point out that none of those fonts is distinctive enough not to consider reasonable substitutions, and all have free alternatives. (Gonestone is, in fact, a freebie version of the licensed Gunstone.)
So you may want to remove that brick from the wall to start with.