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

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. 🙂

something about ID obfuscation isn't valid for the latest version of EPUBcheck

I'll experiment to see what my results are.

However, you're combining at least two situations here: Kindle and some other distributor, who I assume is EPUB-based. Whether the latter is fussy about passing EPUBcheck or not, it is extremely difficult to get designated fonts working in Kindle, regardless of EPUB source or validation. There's a whole chain of issues there, but it comes down to two things:

A professional publisher does not submit docs with unencrypted commercial fonts, no matter how small a technical violation it might seem;

an experienced publisher does not designate fonts in either Kindle or EPUB, since the only real result is to bloat the file sizes, cause all the problems you're seeing  and have the choices undone by various readers' programming. Trying to build e-book display around print concepts is an outdated model. Both the readers (hardware and apps) and the users can and will change the font, size, spacing etc. and trying to force their choices generally leads to problems.

E-books should use only the base CSS file designations  —serif, sans-serif, monospaced — and neither specify font names nor embed the files.

I'll stand by what I've said in every instance of this topic: don't spec or embed fonts in EPUB. It's counterproductive in all ways. (And fonts should never be, nor ever need to be, un-encrypted for validation reasons. The process encrypts them for a reason — a fairly weak, outdated reason, but for a reason.)

As for validators, there's only one validation that has any value: does the file work on either Kindle or a vanilla EPUB reader like Calibre? Everything else is pretty much irrelevant, of importance only when an EPUB is built by hand and all kinds of structural mistakes can be made. InDesign EPUBs can go straight to any but one or two oddball library/sellers without any errors, regardless of whether they tick every validation point. (And there's only one validator worth using for a technical check, EPUBchecker; most others are either that wrapped in a UI or, worse, EPUBchecker wrapped in a UI that then helpfully adds the developer's own notions of what's valid or not.) I don't think I've had a validation pass tell me anything useful, good or bad, with ID exports.

I'm curious where you're getting 'EPUB 5.0 standards' when the turtles on the EPUB commitee seem to think v3.3 is the latest.

Just saw this! I just posted to your comment!

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.

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.