Epub obfuscated resource

Report · Jan 30, 2024

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

Report · Jan 30, 2024

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

Report · Feb 07, 2024

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?

Report · Feb 07, 2024

This may well be something between a bug and an aspect of updating ID's EPUB export.

The pattern I see is that at least one font generates that "non-standard font" message, which at an Info level should not mean a validation fail.

However, when listed in the XML summary doc, it generates an Error. At a guess, the faulty font does not result in a legitimate entry there, and so — boom. Error.

The solution is to fix the font, one way or the other (replace, get a better font file/version, etc.) It may be that InDesign was glossing over this mismatch/error until v19, and now processes the XML summary properly, so the doc "works" but fails strict validation. I don't really know who to point a finger at here; I'd be surprised if the same font did not cause an encryuption.xml error using old 'build it" tools as well. That is, the fault here may have been that ID was allowing the error to pass. But I really don't know.

Fix the font involved if you need clean validation.

Report · Feb 07, 2024

This line, though:

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").

...doesn't tell what font is causing the error. By the way, there are two fonts here: RooneySans and SF Pro (which I could convert to outline, since it's just icons from the SFSymbols app). Even assuming I find the culprit, how does one fix a font? What error is actually there?

For now, the path is "do nothing, just do not upload to Apple Books".

I wonder what one needs to study to learn how to diagnose, spot, and fix these errors... is really Computer Science needed for everything?

Report · Feb 07, 2024

I'm going to dig into the actual files here and see if there's useful information, but it's basically simple: if you have an Info note for any "non standard font," it results in an Error for the encryption.xml file. I have tested enough to know that when all fonts that spawn that warning are removed, the error goes away. So it's not one or the other of those fonts in your case, but both/either.

Again, I don't know if this is a mistake/fault on ID's part, or simply something that's been brought into more rigid conformance and is thus creating an error with elements that formerly passed. Experimenting now. 🙂

Report · Feb 07, 2024

Just throwing this out there: True Type fonts are not supported by epub 3, and that (probably) throws the validation errors.

Replace all your ttf font files with either OpenType or WOFF.

https://idpf.org/epub/30/spec/epub30-changes.html#sec-new-changed-embedded-fonts

Report · Feb 08, 2024

This would explain quite a bit, but how can I know if RooneySans is TrueType or OpenType?

In the CreativeCloud app this is not shown (or I was unable to find it).

Report · Feb 08, 2024

If you are on Windows, open the Fonts settings and look for your fonts in the list. Click to inspect.

On Mac look for the Fonts folder. It should list the installed fonts and show what kind of font file format they are in.

TTF is an older format, and OTF is preferred nowadays (not only for epubs where it is deprecated since V3). Best to replace your TTF with OTF versions in this case, because

refers to TTF as the culprit ("non-standard font type"), i.e. only OTF or WOFF will validate in an epub v3 and later.

Report · Feb 08, 2024

I dunno, here. My test file (from one of my tutorial essays) uses Calibri and Cambria, the vanilla Windows/Office fonts. All the Calibri fonts are flagged by EPUBcheck as "encrypted" with an Info note. Cambria is the one that throws the "nonstandard font" notice — also an Info-level note — but then chokes the overall validation with that "Font Core blah blah" notice that ranks as an Error, and thus validation failure.

All the Calibri fonts are TTF. The Cambria is a TTC, a combined TTF font.

So I am not much enlightened by the validation results, even in light of your comments. 😛

Report · Feb 08, 2024

Yeah, I agree: it's all a bit vague. What the OP could try: open the file in Sigil and right-mouse click the offending obsfucated fonts, then either turn that off or use the alternative obsfucation method. Then try again.

Nonetheless, according to the epub 3 standard TTF fonts ought to be avoided if we care about validating the font files. TTC would fall in the same category of non-validating font file formats.

Report · Feb 08, 2024

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.

Report · Feb 08, 2024

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

Report · Feb 08, 2024

Thanks James! 🙂

Report · Feb 08, 2024

It is actually quite simple: open the generated epub file in Sigil (an open source & free epub editor).

https://sigil-ebook.com/sigil/

Sigil allows you to inspect and work with epub files directly.

Once open, locate the fonts folder in the left outliner panel. Check the fonts one by one. Right-mouse click each font to either remove or change the encryption (obfuscation). Try removing the obsfucation and save the file for testing.

In any case if you want your epub to validate as epub 3.X: replace the ttf files with otf or woff font files.

Report · Feb 08, 2024

PS replacing the font files is directly possible in Sigil, but you would have to edit the code manually everywhere these files are referenced in the epub. Usually there are only a few files here and there with a few references for your fonts.

A search and replace is possible in Sigil.

That or uninstall the TTF versions of your installed fonts and replace with OTF ones.

If these are unavailable, you may have to either pick different fonts, or convert the TTF fonts to OTF (both online and offline tools are available for this).

I am aware this is treading into more technical territory. As @James Gifford—NitroPress writes: the decrepit epub standard is to blame.

Ideally we wouldn't want to embed any fonts in our epub files, btw. We ought to leave the font choice to the reader and the user's reader font settings. Same for font sizes (never use PX, always use relative units such as EM) and line height (leading). eReader devices allow the user to customize these to their liking, and by setting hard absolute px/pt units it often becomes impossible for the user to adjust these.

I know: I am regularly forced to literally hack my purchased epub files and open these in Sigil to remove these hard-set font settings in order to control the reader settings on my Kobo.

Incredibly frustrating, to say the very least.

Report · Feb 08, 2024

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

Report · Feb 08, 2024

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.

Report · Feb 09, 2024

Well, input's always welcome on the book (and essays); I don't claim to be a last-word expert on any of it and I update both as my understanding improves. (Mostly the hard way: there is SO little valid information promoted about EPUB as a general topic!)

My comments here are strictly gated to the ID community: if you have ID, you don't have to bother with about 95% of the rest of the e-book universe's amateur, outdated and frustrating tools. If this were a general EPUB forum (if there were one such, that is, that isn't all but useless), the consideration of users who don't have ID or ID skills would be much greater.

That said, let me know how you're getting from Word to EPUB. The MS converter is... nothing to write home about, to the point where (as you know) I recommend going Word to HTML for submission to Kindle. And no, I don't consider online coversion sites any more suitable than I do for QR code creation, for much the same reasons.

Yes, the EPUB tools like Sigil and Calibre (the editor/tool, not the reader) are useful, but for me, so is just dumping the EPUB into a folder and opening the files I need to see. Maybe I'm just too primitive on that level. 🙂

Report · Feb 10, 2024

It is actually quite simple: open the generated epub file in Sigil (an open source & free epub editor).
https://sigil-ebook.com/sigil/

Sigil allows you to inspect and work with epub files directly.

Once open, locate the fonts folder in the left outliner panel. Check the fonts one by one. Right-mouse click each font to either remove or change the encryption (obfuscation). Try removing the obsfucation and save the file for testing.

In any case if you want your epub to validate as epub 3.X: replace the ttf files with otf or woff font files.

By @rayek.elfin

Ok, I have downloaded Sigil. It appears not to be a notarised app, but ok...

I cannot find, in the EPUB structure, the METAINF folder which is throwing the error

ERROR(PKG-026): Dotzauer_Pearls_of_Wisdom_Fixed_v1.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").

Regarding TTF: since they are encrypted, they simply through a warning, not an error. It is curious, though, that the Adobe version of RooneySans is TTF, and the freely downloadable version is OTF. Why would that be?

Could I also attach here a link for you to check the EPUB directly, after this step?

In the end, I export EPUBs only for Apple Books, and I do not even have 1% of my downloads coming from there, so whenever there is an issue like this, I simply do not publish there and don't care too much.

One way that has helped, but which goes against the idea of EPUB itself, is to export SVG from the PDF, create a new InDesign document only with SVGs, and publish that. Sad? Yes. It works? Yes! *facepalm*

Report · Feb 10, 2024

Update: I've uncompressed the folder manually, found the folder, and found the culprit line:

SFPro is an Apple-made font that, at least in theory, should be used in apps and may not be used in text that is not directly related to Apple. I will make some trials to substitute it with something else, or with images, since they are icons.

Report · Feb 10, 2024

First — having found the file, what made this line stand out among the other font resources listed? I've found no difference in the line items of encryption.xml between valid and rejected fonts.

Second — if Sigil hides the metadata folder, I find that the kind of exasperatinng "I know better" app approach that underlies my rejection of the entire spectrum of EPUB tools. It's one thing to organize the presentation for (old-school) editing and modification, and try to clarify structure and interconnection between the EPUB components, but if essential files are kept hidden or not viewable, it's just one more argument against all these tools, at least as they've evolved for the largely amateur author/publisher/e-book collector user base.

I find it trivial to just open an EPUB with an archive manager and either grab a file I need (usually ID's initial CSS file), look for structural faults (such as embedded fonts) or just unzip the whole thing into a folder for any more advanced inspection or (very rarely) changes. I know not every designer/developer is comfortable with XML files, and thus appreciates the help of an environment tool like Sigil, but... sooner or later, the training wheels have to come off if you're going to get serious about EPUB/Kindle quality, and it's just not helpful to have tools simplify the content.

/rant over

...but just once, I'd like to be pleasantly surprised by something in the larger/existing EPUB development world.

Report · Feb 10, 2024

Ok, I have downloaded Sigil. It appears not to be a notarised app, but ok...

I know of no EPUB/e-book tools that are NOT created by... let's call them solo developers, or a few slightly larger entities who tend to be trying to corner a part of the user base/market to their particular view and approach. So if there is a truly commercial-grade, formally-released, validated-install tool out there, it's escaped me. It is resolutely a world of amateurs reinforcing amateur approaches, and I find it frustrating not only that it has failed to evolve, but that so many participants have a vested interest in keeping it from evolving. Arrgh!

In the end, I export EPUBs only for Apple Books, and I do not even have 1% of my downloads coming from there, so whenever there is an issue like this, I simply do not publish there and don't care too much.

I'm not following. You upload only to Apple (I'm aware of that from prior discussions)... but you only sell 1% of your wares there? Or did you mean something else? We've established that you're in a narrow niche of requirements for sheet music that needs to be scalable, high-res and still get from ID to Apple's demanding requirements. But if you sell elsewhere successfully, it seems as if you could concentrate on better general-reader EPUBs (and PDFs) rather than spend so much time and effort getting stuff to Apple's shelves. But I trust you know your market and aims. 🙂

Report · Feb 10, 2024

There is close to no market for sheet music on Apple Books, because it is not a good reader for that purpose. I use to only publish full scores because they can come in handy for conductors to study while travelling, for example. But again, that's nothing that they couldn't do with a good PDF and a good reader (plenty, really!).

So yes, less than 1% of my sales are from Apple Books, but I'm not sure I trust myself in knowing my market. The best adjective I could define the sheet music market with would be... obfuscate!

I agree with you: what makes that line non valid? No idea...

Report · Feb 10, 2024

Again, it's my understanding that there's nothing wrong wtih encryption.xml or any line within it — that the error, although pointing to this summary, is actually triggered by the "unknown file type" associated with that font file elsewhere. It's that kind of indirect reference, which I'm sure makes all the sense in the world to the EPUB standards committee, that drives me batty.