Embedding Typekit Fonts in EPUB

[victoriar83987860]

Hello,

I'm working on a reflowable EPUB 3 and am having trouble with properly embedding Typekit fonts.

I'm using three typefaces (Adobe Caslon Pro [OTF], Korolev [OTF], and Montserrat [TTF]). All three exported from InDesign CC 2020 with no errors or warnings. Their files appeared in the fonts folder, as did the encyrption file in the META-INF folder.

Initially, all three fonts render correctly when the epub is viewed in iBooks, Adobe Digital Editions, and Chrome, but when I move the epub off my desktop to a mobile device (iPad), the fonts do not display. If I disable these fonts in Typekit, the fonts no longer display on my desktop in iBooks, ADE, or Chrome, leading me to believe that these platforms were drawing on the system font files (synced from Typekit) instead of the obfuscated fonts in the fonts folder.

To make sure the @Font-face in my CSS was correct, I cut-and-pasted a non-obfuscated font file directly from my Mac's local fonts folder into the fonts folder in the EPUB and adjusted the CSS to point to it. This font displayed without a problem in Chrome, iBooks, and ADE on desktop, as well as iBooks on iPad. This indicates that the XHTML and CSS files are set up properly.

This has led me to conclude that the error must lie with either 1) Typekit's or InDesign's obfuscation/subsetting export or 2) the encryption file or encryption/decryption process.

Any insight or help is appreciated!

Edit: Attaching the epub file for reference. This is from a version I exported straight out of InDesign, and then went through and tore out all of the actual content of the ebook to get the file size down. Because of this, the .opf file, etc. is a mess, but the font files are just as InDesign exported them, and you can open the text.xhtml file in a browser and take a look.

And for further clarity, this is what the test.xhtml file looks like (with Korolev and Caslon specified in the CSS, but Typekit syncing is turned off, so they default to the obnoxious fallbacks Impact and Papyrus):

If I turn on Typekit syncing, the fonts magically work again:

...but Chrome is only drawing on the system fonts and not the obfuscated files in the font folder of the epub.

[Derek Cross]

I would suggest you change the TT font to an OTF one, and experiment with some other fonts --i.e. simpler typography. Consider checking the ePub with a validator, such as Flightdeck https://ebookflightdeck.com $15 for one month.

[victoriar83987860]

Hi Derek. Since I'm working with two OTF fonts and one TTF, this problem doesn't seem to be specific to TTF fonts. Furthermore, I can manually embed both OTF and TTF unobfuscated/subset font files into the epub without any problems.

I have run the epub (which is finished apart from these typography issues) through EPUB-Checker and Ace by Daisy (it's accessible as well) and have not encountered any issues. And Adobe Caslon Pro is one of Adobe's oldest fonts (not exotic by any means), so I doubt this issue is limited to new or unusual Typekit fonts.

As for "simpler typography," I've enlisted several fallback typefaces for each of my CSS classes, but it's more the principle of the thing. I don't remember ever having been able to properly embed Typekit fonts in an epub (it just irked me more this time), so if I can't the problem sorted out now I'll make a habit of avoiding Typekit fonts altogther and pre-empt the problem.

[victoriar83987860 · Accepted solution]

So after trying to reproduce the problem again with a fresh file, I was finally able to track down what was causing the trouble. 

Turns out that some part of the font fetching/de-encrypting/rendering process relies on the InDesign-auto-generated dc:identifier in the metadata of the .opf file. Since the main dc:identifier needs to be unique, I'd changed this to the ebook's ISBN, and this had (somehow) broken the font rendering. By restoring the identifier to the original (a long alphanumerical string beginning with "urn:uuid:"), the link to the fonts was restored as well.

[defaultbo2p9wf5vd1w]

Thank you! This was super helpful. Annoying that we cannot input ISBN into metadata as well as the unique code when initially exporting the data. I use flightdeck to add it and re-export after running the platform checks. It's brilliant.