Warning: resource oebps/font/Agaramond-regular.otf cannot be decrypted

[prepress]

I'm getting a message like this from epubcheck 105:

Warning: resource oebps/font/Agaramond-regular.otf cannot be decrypted

Created the epub with Calibre 0.7, tested it with older versions and this error does not appear after converting in 0.6.40. To avoid this error we're now forced to use this 0.6.40 and we can't benefit from fixes and new features when new Calibre versions are released.

Does anyone have a clue how to get rid of this warning?

Thanks in advance!

[prepress]

We've found out that this warning didn't appear when converting a file in Calibre 0.6.40, but all newer versions after 0.6.40 produce this error in combination with epubcheck 105.

Since our customer uses epubcheck to validate the epubs and they don't want any warnings or errors in the final verdict of epubcheck, we're forced not to update calibre and stick with 0.6.40.

This is what epubcheck support says:

<<<<<<<
There is an embedded font in the package that is obfuscated using Adobe's method. I am not familiar with their font mangling algorithm but looking at the epubcheck source code I see that it is expecting the algorithm to be declared as "http://ns.adobe.com/digitaleditions/enc". The algorithm in the sample is declared as "http://ns.adobe.com/pdf/enc#RC".

Probably this font will not be displayable in any EPUB readers, but I am not convinced that the EPUB is invalid just because epubcheck can't decrypt the font.

Algorithm URL "http://ns.adobe.com/pdf/enc#RC" is correct for Adobe obfuscation. I think this warning is given any time we hit an encrypted resource, just to let users know that we did not validate that resource in any way. Being a warning, it does not mean that EPUB is invalid.
>>>>>>>>

Now my question is this:
Howcome new versions of calibre, after 0.6.40, have changed something so embedded fonts are decrypted? Is it possible to revert this so this warning won't show up again?

Thanks for your help.

[DoctorOhh]

Originally Posted by prepress

produce this error in combination with epubcheck 105.

I'm just curious, what did epub-fix say about the file when you ran it?

Originally Posted by prepress

Since our customer uses epubcheck to validate the epubs and they don't want any warnings or errors in the final verdict of epubcheck, we're forced not to update calibre and stick with 0.6.40.

Putting a little angry face is surely going to get you all the help you're looking for...

If you want help there are better ways to ask, but for Pete's sake quit whining about being "forced" not to update. No one is forcing you to use the program to begin with.

Hopefully someone with knowledge might stop by to help.

[kiklop74]

Originally Posted by prepress

We've found out that this warning didn't appear when converting a file in Calibre 0.6.40, but all newer versions after 0.6.40 produce this error in combination with epubcheck 105.

Since our customer uses epubcheck to validate the epubs and they don't want any warnings or errors in the final verdict of epubcheck, we're forced not to update calibre and stick with 0.6.40.

Just give a resonable donation to Kovid and he will probably fix it for you.

[prepress]

Well I apologize for using a bad tone in my message and for the whining about being forced, you're right about that.

epub-fix reports nothing about it:

C:\Program Files\Calibre2>epub-fix.exe --epubcheck test1867.epub
OPF contains date 2010-08-10 00:00:00+02:00 that epubcheck does not like
Replaced 2010-08-10 00:00:00+02:00 with 2010-08-09

C:\Program Files\Calibre2>


With regards,
prepress

[kovidgoyal]

There are two methods of encrypting fonts:

1) Adobe

2) IDPF

epubcheck will only accept the second. Actual EPUB readers usually only accept the first. So calibre uses the first. IMO epubcheck is an unmitigated disaster. Do you want an epub file that passes epubcheck or one that is actually likely to work on actual epub readers?

Versions of calibre prior to 0.6.41 did not obfuscate fonts, so you wouldn't get the error with epubs produced by them. But including un-obfuscated fonts in a epub file is a copyright violation for most fonts, which is why updated versions of calibre obfuscate fonts.

[Starson17]

Originally Posted by kovidgoyal

updated versions of calibre obfuscate fonts.

Are all fonts automatically obfuscated, or is there a flag that a font sets that says "I should be obfuscated"?

A related question: When a font is obfuscated (using the Adobe obfuscation), is the entire font table normally included, or are characters that are not actually used removed from the font table?

[kovidgoyal]

all fonts are obfuscated. All obfuscation does is change the first 1024 bytes of the font file. It is the most ridiculous thing I have ever seen, but that is hardly surprising given that it springs from copyright.

What you are asking about is subsetting, calibre doesn't do that.

[Starson17]

Originally Posted by kovidgoyal

all fonts are obfuscated. All obfuscation does is change the first 1024 bytes of the font file. It is the most ridiculous thing I have ever seen

It does seem ridiculous. If someone is knowledgeable enough to extract the font file, you'd think they'd be knowledgeable enough to un-obfuscate the 1024 bytes.

What you are asking about is subsetting, calibre doesn't do that.

Thanks.

[kmcchrystal]

So, if my open type fonts in my epub, created in InDesignCS5.5, don't validate via epubcheck, for this reason (listed for all my fonts):
resource OEBPS/fonts/ACaslonPro-Italic.otf cannot be decrypted, and you are saying epubcheck validation failure for this reason does not mean the epub isn't valid, what do you suggest I do? Just ask Kovid? or go through the process to convert to mobi and thence to kindle, and go through the nook conversion process for Barnes&Noble nook books and just see if they get accepted?

[Dopedangel]

Originally Posted by kmcchrystal

So, if my open type fonts in my epub, created in InDesignCS5.5, don't validate via epubcheck, for this reason (listed for all my fonts):
resource OEBPS/fonts/ACaslonPro-Italic.otf cannot be decrypted, and you are saying epubcheck validation failure for this reason does not mean the epub isn't valid, what do you suggest I do? Just ask Kovid? or go through the process to convert to mobi and thence to kindle, and go through the nook conversion process for Barnes&Noble nook books and just see if they get accepted?

If you are creating something for publishing my advice don't use internal fonts unless really necessary as most users prefer to use their own fonts and settings. And one of the major reasons they actually bought a reader is so they can change formatting and fonts. Hardcoding fonts will ruin the reading experience for many of these users.
If you are making it for personal use then I can't say much as you are using kindle and I don't know anything about it. Except it doesn't read epubs.

[charleski]

Originally Posted by kmcchrystal

So, if my open type fonts in my epub, created in InDesignCS5.5, don't validate via epubcheck, for this reason (listed for all my fonts):
resource OEBPS/fonts/ACaslonPro-Italic.otf cannot be decrypted, and you are saying epubcheck validation failure for this reason does not mean the epub isn't valid, what do you suggest I do?

Epubcheck creates a Warning on encountering ADE-obfuscated fonts, not an Error. Whoever uses epubcheck needs to know the difference between the two. An ePub is only invalid if it's generating errors. I think epubcheck could make this a little more clear, but if this is causing issues, then the problem lies with the system interpreting the epubcheck output.

Originally Posted by Dopedangel

If you are creating something for publishing my advice don't use internal fonts unless really necessary as most users prefer to use their own fonts and settings.

No.