Participant

Question

Epub obfuscated resource

Forum|Forum|2 years ago
January 30, 2024
4 replies
15149 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?

rayek.elfin

Legend

Well, I've made it pretty clear in my postings here (and elsewhere) that I think the days of post-creation surgery on EPUB are over and done. Sigil, BBedit, all those tools are relics of a past when you built your e-book (of any format) from handmade scraps and files, or you didn't do it at all. But just as we don't post-process PDFs any more, or fix printouts with wite-out and a pen, it's outdated and misdirected to have to overhaul EPUBs after every single export attempt.

Fonts are also encrypted for reasons that should be respected by professional publishers, regardless of how casually fonts are handed around and available from shady websites these days.

I concede being rigid and a bit extreme on the point — even in this thread, I noted it was useful to dig into the EPUB structure for information — but I believe the only valid modern practice is to get the EPUB right or fix what's not making it right... don't mod, paint and buff it afterwards, since that isn't just time wasted once, but every single time you do a new export — which for me, is frequently.

The real solution here is don't embed the damn fonts in the first place, as it's contrary to modern e-book design... another point on which I maintain an inflexible viewpoint. Respect the medium, don't try to drag lead-type notions into it. If all e-publishers followed that one practice, e-book aficionados wouldn't need to keep a repair and hot-rodding tool set around. That so many people are willing to put up with this nonsense (and often crappy book design to boot) just to use this reader or that for everything kinda boggles me.

This has been one man's opinion. We now return you to your own notions of what works best. 🙂

I agree, actually. 😉

We shouldn't be editing epubs manually that are published from tools such as InDesign (it is a different context when Sigil is used as the initial epub creation tool, of course). And as I stated earlier in this thread: we shouldn't be embedding fonts in the first place.

InDesign is not the only valid tool to create good reflowable quality epubs, of course. We can do those in InDesign, LibreOffice Writer, MS Word, Sigil, and other tools. When we have to crack open a published epub post-publishing to manually fix things, I absolutely agree it means something's amiss in our epub publishing pipeline or workflow. Just as you say.

The reason why I mention Sigil here is merely to figure out where exactly the workflow could be improved. To debug, as it were 🙂 And as far as I can tell: TTF fonts should be avoided. Hard to say for certain without access to the original epub file.

PS @James Gifford—NitroPress I purchased and read your book. The only part where we differ in opinion somewhat is about images and the resolution settings used in InDesign, ha ha. 😄 But that is a conversation for another time.

PPS Mucking with an epub's font obfuscation via Sigil I only mentioned within the scope of debugging and figuring out the validation errors. If a font is a licensed one, we'd actually be breaking the license if we remove one such font file's encryption.

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