Participant

Question

Epub obfuscated resource

Forum|Forum|2 years ago
January 30, 2024
4 replies
15118 views

Hi there,

novice here trying to get a book file out of indesign as an epub. But when validating the file I receive this message, can anyone help me get out of the weeds:

Obfuscated resource must be a Font Core Media Type (was declared as "application/x-font-ttf" in "OEBPS/content.opf").

Look at line 5 in this file: META-INF/encryption.xml

M

mlemgan

Participant

@James Gifford—NitroPress

The correct choice, though, is not to use FXL — it's an obsolete approach with many and increasing problems, and should be used only for "picture page" books like graphic novels and children's books. It should never be used for what are largely text-content books: that's what reflowable is best at.

Currently, I'm working on a sort of archival reprint art book with lots of text (basically, we're reprinting magazines). We are going with FXL because the designs are complicated and we want the reader to view the page as is, so reflowable doesn't seem to suit this book's purpose.

Right now, Courier Prime is giving me this error message because it's a TTF font—even though I installed it via Adobe Fonts. I could just download the TTF font on the original github website and convert it to OTF to resolve this issue. But out of curiosity, I have a few questions:

- The other fonts that were giving me error messages were Arial, Impact, aka the typical system fonts that come with every computer. Is this error message basically saying that there is a problem with encrypting these TTF fonts?

- On a different thread, you wrote that these validation errors are of little meaning if these EPUBs display fine. Will there be significant issues if I were to ignore the error message for Courier?

- How is it that Adobe stated that they will no longer support TTF fonts in 2023, and yet Courier Prime shows up as a TTF font? Should I be worried about the legacy of using Courier in this book?

Thanks in advance for your responses! I've seen your responses across different threads and wanted to say I appreciate them 🙂

James Gifford—NitroPress

Legend

(Thanks.)

None of this is simple. FXL has its place when fixed page content is truly needed, but that doesn't really resolve any of its problems at either the creation or viewing end. If what you have is page images, FXL is your only good choice to display them, but (as you're finding) it doesn't support things like TOCs and live text very well. This is all compounded by InDesign's flaws at producing it. And then that's all compounded by the slow shift to better accessibility, which is an uneven movement across the standards, tools, resale vendors and readers.

Fonts — Adobe didn't deprecate TTF fonts, but T1 fonts, the very, very old font format that originated in the 1980s, IIRC. They gave years of warning about it but the change still caught quite a few legacy designers and shops by surprise.

The font fault you're seeing is that ID doesn't handle the export well and doesn't write structural code that is compliant with the shifting models. The only fixes are to switch to a modern OTF version of the font (or any common OTF font, when the face doesn't really matter), which still generates some errors but often passes the vendor validation steps. Or, edit the header code of the EPUB file, which I strongly deprecate as an outmoded approach. As you don't actually need any display text in this book, just text links for the TOC, switching to any modern (file format) font should see you clear. If the validation has changed yet again and calls out InDesign's poor management of embedded fonts... you may have to look up the header editing steps. (It's trivial, as I recall — moving the font listing from one section to another, or renaming a header section. The problem is that you have to make that edit every time you re-export the book.)

K

Kev5C3A

Participant

I had this error come up in IngramSpark.

I ran the ebook through Caliber, converting the epub into an epub (yes, the same file format) and it fixed the problem.

V

victoriar83987860

Participant

I had this same problem and found a solution on another site:

Obfuscation can only be done on core media type fonts but you're using a non-standard media type to declare your TTF fonts. To fix the errors, change the media types of the fonts in the package document manifest from "application/x-font-ttf" to either "font/ttf" or "application/font-sfnt". Those are the only media types epub recognizes for TTF.

So, go into the content.opf file inside the EPUB and search for the manifest item(s) for your TrueType font(s). It will look something like this:

<item id="CrimsonText-Bold.ttf" href="font/CrimsonText-Bold.ttf" media-type="application/x-font-ttf" />

And then change to:

<item id="CrimsonText-Bold.ttf" href="font/CrimsonText-Bold.ttf" media-type="font/ttf" />

H

Hal37868325hvkx

Participant

This appears to have fixed the error for me! Thanks!

James Gifford—NitroPress

Legend

Well, this is fixing things by painting over them, more or less.

First, EPUB surgery/editing is an obsolete practice. If you have to hack the exported file, you've done something wrong upstream.

Unchecking the box noted above will eliminate the embedded fonts and the problem; CSS style adjustments will take named fonts out of the picture entirely, as they should be for reflowable EPUB.

James Gifford—NitroPress

Legend

There are a couple of layers of issues here.

First, as you probably know, fonts are encrypted so that they cannot be extracted from an EPUB and reused. Only some fonts are licensed/allowed to be used in this fashion, so any font that does not have the right license encoding will be rejected by the export, or (when stuck in the middle) result in errors. The very short answer here is that you'll need to replace that font (face) with one that is compatible with encrypted EPUB export.

It is, however, a deprecated practice to embed fonts, or to designate specific fonts at all. Modern practice is to use generic font definitions (serif, sans-serif, monospaced) and let the reader (app or device) and user choose and optimize the actual fonts used.

You don't say whether you're exporting to reflowable or fixed-page (FXL). Fonts are optional/deprecated for reflowable, but more or less mandatory for fixed pages, so you may not have an easy choice. The correct choice, though, is not to use FXL — it's an obsolete approach with many and increasing problems, and should be used only for "picture page" books like graphic novels and children's books. It should never be used for what are largely text-content books: that's what reflowable is best at. It often seems like the right and simple and obvious choice, but all that "simplicity" hides a host of structural and practical faults. If you want fixed pages, use PDF. If you want a (text) e-book, use reflowable.

So... if you're using FXL, consider changing to reflowable layout and not spec'ing or embedding fonts. But if you don't want to make any of those changes, you need to find an alternate, technically compatible font for the one that's being rejected.

We won't go into how validation is largely an obsolete practice, for now. 🙂

I

Inélsòre

Inspiring

I'm having the same error in both Fixed and Reflowable exports.

This is what the validation has to say:

Validating using EPUB version 3.3 rules.
INFO(CSS-007): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/OEBPS/css/idGeneratedStyles.css(29,2): Font-face reference "https://b247adac-4f4a-4232-b255-4d63426351e3.epubcheck.w3c.org/OEBPS/font/SFPro-Regular.ttf" refers to non-standard font type "application/x-font-ttf".
INFO(RSC-004): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/OEBPS/font/RooneySans-Bold.ttf(-1,-1): File "OEBPS/font/RooneySans-Bold.ttf" is encrypted, its content will not be checked.
INFO(RSC-004): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/OEBPS/font/RooneySans-Regular.ttf(-1,-1): File "OEBPS/font/RooneySans-Regular.ttf" is encrypted, its content will not be checked.
INFO(RSC-004): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/OEBPS/font/RooneySans-RegularItalic.ttf(-1,-1): File "OEBPS/font/RooneySans-RegularItalic.ttf" is encrypted, its content will not be checked.
INFO(RSC-004): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/OEBPS/font/SFPro-Regular.ttf(-1,-1): File "OEBPS/font/SFPro-Regular.ttf" is encrypted, its content will not be checked.
ERROR(PKG-026): Dotzauer_Pearls_of_Wisdom_Reflowable.epub/META-INF/encryption.xml(23,62): Obfuscated resource must be a Font Core Media Type (was declared as "application/x-font-ttf" in "OEBPS/content.opf").

Check finished with errors
Messages: 0 fatals / 1 error / 0 warnings / 5 infos

EPUBCheck completed

What is this "Obfuscated resource" that is mentioned?

In this case I will probably not upload this to Apple Books, but I would like to know what is wrong and how to fix it. The font used is RooneySans, which is an Adobe font! Am I making a bad choice during the export phase, in the export epub dialog?

How do you avoid spec'ing and/or embedding fonts?

James Gifford—NitroPress

Legend

From the error line I got, it is not clear what font caused the issue. How can I know what font is obfuscated (whatever that means, I have no idea!)? What is the alternative obfuscation method?

On the Fonts folder: Adobe fonts are not listed there. I've lost track of the method to find them, and to identify them, since Adobe masks them with numbers.

Thought I answered this... maybe not. The answer is that you can't identify any one font among the culprits if you have more than one "nonstandard font" warning. Any one or more of those will cause the "Font Core" error in response. ALL of those fonts have to be replaced.

I'm not sure this is a much a general "Computer Science" knowledge issue as it is just another fault of EPUB: it's excessively complex, it's fussy about far too many things and there's no documentation in between the standards declaration and something comprehensible. The details of this issue could be resolved by laborious code-tracing and standards-reading (bring aspirin), but in the end, it will be just one niche issue resolved, and likely to no useful end. Validation won't accept those nonstandard fonts; period. There's no fix but to replace them with compliant fonts, no matter what the technical/structual reasons and algorithms are.

It'd be nice if we had a choice of e-formats. 😞

"Obfuscated" is XML-speak for "encrypted," more or less. It's a method to protect stuff in completely open ASCII code by using substitute characters (such as the ASCII codes for spaces and line returns), then tangling up the code so that only an expert with a great deal of patience can turn it back into understandable, modifiable, steal-able code. It's common in all web sites build using commercial tools and libraries, since otherwise anyone who can view the site can review the code and copy those advanced features. Here, it's extended to the fonts being encrypted, a super-form of "obfuscation" but this world only knows its own terms. 🙂

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded