How to display Adobe fonts in reflowable ePUB for end users in Kindle

[MissEloquent]

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.

1. Is there a way to display specialty (otf) fonts as they should correctly display in KDP? Removing obfuscation entirely seems to be the only way they show up in KDP (Adobe and IDPF's obfuscation does not work), and keeping obfuscation falls back to their Baskerville font.
2. Is de-obfuscating allowable if you have an Adobe Fonts account?
3. Is de-obfuscating end-user protected?
4. If keeping obfuscation is the only way to go about this, is it even possible to display the font at all? If so, what component am I missing? 

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. 

[James Gifford—NitroPress]

Okay, this is rather circular, but...

I pull out the source for a book that has been successfully published on KDP (and updated a few times).

I discard the elaborate CSS file completely, so that the output is InDesign's native/raw export. The only change I make is to check "Embed Fonts."

I run this file through the original, command-line EPUBcheck v5.10. I get six "Info" level warnings for the six font faces in use... nothing else. There should be no objection to this book from any EPUB vendor.

But... that's after I had one oddball font used in the layout pass on its own, but create a secondary error in the XML font listing, which qualified as an "Error," enough to disqualify the book for some vendors and archives. When I swapped to a more standard font, the Error went away and I got the above result.

If you're not seeing the raw line output from EPUBcheck, if you're using some secondary-source online version, it's being handled/processed/filtered by that provider's wrapper, and you can't really trust that the reporting is wholly accurate. (The entire EPUB world is filled with players who "know better" and bend all the rules and tools to suit their whims... that's problem #1 with the format.)

So whatever is telling you "Failure" or "Failed" (which are not native EPUBcheck responses) is a modified version, and if it's giving you a fail based on Info level results, it's... wrong. On the other hand, if it's giving you Error level results because you have a bogus or nonlicensed (for e-distribution, even if encrypted) font... that's exactly what it should be doing, but the problem has nothing to do with InDesign. But the only way to know is by seeing that actual line-by-line output from the EPUBcheck 'engine,' not the interpretation or summary provided by some other layer.

While it's possible to make structural mistakes in InDesign, and set export options that will cause downstream problems, and even more possible to write bad CSS styling that will cause problems (and, while we're at it, for an InDesign file to have corruption that causes bad code to be exported), InDesign exports perfectly standard EPUB code that will pass even the strictest validation. I do it every day, with complex books being managed in dual-format mode.

I can't remember the last time a validation or acceptance fault actually traced to a problem with InDesign's export, something unfixable because ID 'did it wrong.'

I'd suggest that you grab the real EPUBcheck from W3C, and learn the slightly arcane process of running it as a command-line checker so that you can see its "authorized" and valid output for yourself. If there's a fault with a font, it's probably because the font is faulty or not electronically tagged for output file embedding; the only solution is to use a font that is valid or licensed. And once again, the whole practice of spec'ing and embedding fonts in reflowable EPUB is problematic, outdated and simply ignored by most readers, including Kindle... so the realy solution here is to use simple fonts in your source doc and  either not embed them, or take the extra step of stripping them to CSS base types in the CSS file.

It's really, really, really easy to find ways to do things badly with EPUB creation. It's fairly tough to find the one path that consistently works, across tools and time and various vendors etc., and stick to it. But you can tell which method I encourage here. 🙂