MobileRead Forums - View Single Post - Adobe Fonts Not All Handled Properly by Calibre

mazdaspeed · 06-23-2022, 04:04 PM

It would be nice if Adobe, Amazon, Apple, IDPF, etc. would step-up and clarify these extremely important issues surrounding licensing EPUB fonts, and the hazards thereof. Across the EPUB creation community there is absolutely no consensus on the matter.

I've read everything from "don't mess with the encryption.xml", to "remove the encryption.xml" completely, to "just don't use Adobe or licensed fonts." Well, for one thing, most fonts are licensed in one way or another, and every place that is distributing them makes disclaimers about how they are not giving legal advice for their usage... This includes Google Fonts.

Adobe, for all their hyped inclusiveness for EPUB, doesn't specify precisely how to encrypt or obfuscate to their satisfaction -- as though there's any difference in that terminology. What I do know is that Adobe InDesign subsets and "encrypts" the fonts when exporting EPUBs, and it packages an encryption.xml into the EPUB file that KDP won't process to my satisfaction.

If I strip the encryption.xml file of everything but its header, then it does work for KDP. If this is not satisfactory to Adobe, then they need to speak up. I've done my part by paying the monthly subscription and following directions as closely as I can.

I read a 2015 post from Smashwords that said they reject anything with the encryption.xml file, and another that said Apple removes it themselves. What I think may be the case is that Amazon and the aggregators use its presence as a red flag against problematic EPUBs, as there are many who are not meticulous in what they are doing.

The encryption.xml file does not contain any encryption code, but is simply a list of encrypted, subset fonts that Adobe processed on export, and its data appears nowhere else in the EPUB package. The data looks something like this:

<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:conta iner" xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
<enc:EncryptedData>
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" />
<enc:CipherData>
<enc:CipherReference URI="OEBPS/font/ACaslonPro-Bold.otf" />
</enc:CipherData>
</enc:EncryptedData>
<enc:EncryptedData>
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" />
<enc:CipherData>
<enc:CipherReference URI="OEBPS/font/ACaslonPro-Semibold.otf" />
</enc:CipherData>
</enc:EncryptedData>

From what I've read in a couple other places, it is the Adobe-generated <dc:identifier> that contains the encryption keys, and that this should not be altered in any way, including the order it's placed in the content.opf file. Ex.:
<dc:identifier id="bookid">urn:uuid:628f239d4-1za5-4731-b227-ce1f89dc2e97</dc:identifier>

As such, I've been adding a second <dc:identifier> that uses the ISBN, like so:
<dc:identifier id="isbn">urn:isbn:9781548950752</dc:identifier>

Whether all that info is completely accurate, I don't know, but for now this is working for me. Again, I stress that I am trying to follow the rules, pay the fees, and not trying to circumvent costs. These costs should be easily recoverable for anyone serious about the business.

06-23-2022, 04:04 PM	#14
mazdaspeed Member Posts: 16 Karma: 10 Join Date: May 2018 Device: calibre	More follow-up on embedding fonts. It would be nice if Adobe, Amazon, Apple, IDPF, etc. would step-up and clarify these extremely important issues surrounding licensing EPUB fonts, and the hazards thereof. Across the EPUB creation community there is absolutely no consensus on the matter. I've read everything from "don't mess with the encryption.xml", to "remove the encryption.xml" completely, to "just don't use Adobe or licensed fonts." Well, for one thing, most fonts are licensed in one way or another, and every place that is distributing them makes disclaimers about how they are not giving legal advice for their usage... This includes Google Fonts. Adobe, for all their hyped inclusiveness for EPUB, doesn't specify precisely how to encrypt or obfuscate to their satisfaction -- as though there's any difference in that terminology. What I do know is that Adobe InDesign subsets and "encrypts" the fonts when exporting EPUBs, and it packages an encryption.xml into the EPUB file that KDP won't process to my satisfaction. If I strip the encryption.xml file of everything but its header, then it does work for KDP. If this is not satisfactory to Adobe, then they need to speak up. I've done my part by paying the monthly subscription and following directions as closely as I can. I read a 2015 post from Smashwords that said they reject anything with the encryption.xml file, and another that said Apple removes it themselves. What I think may be the case is that Amazon and the aggregators use its presence as a red flag against problematic EPUBs, as there are many who are not meticulous in what they are doing. The encryption.xml file does not contain any encryption code, but is simply a list of encrypted, subset fonts that Adobe processed on export, and its data appears nowhere else in the EPUB package. The data looks something like this: <encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:conta iner" xmlns:enc="http://www.w3.org/2001/04/xmlenc#"> <enc:EncryptedData> <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" /> <enc:CipherData> <enc:CipherReference URI="OEBPS/font/ACaslonPro-Bold.otf" /> </enc:CipherData> </enc:EncryptedData> <enc:EncryptedData> <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" /> <enc:CipherData> <enc:CipherReference URI="OEBPS/font/ACaslonPro-Semibold.otf" /> </enc:CipherData> </enc:EncryptedData> From what I've read in a couple other places, it is the Adobe-generated <dc:identifier> that contains the encryption keys, and that this should not be altered in any way, including the order it's placed in the content.opf file. Ex.: <dc:identifier id="bookid">urn:uuid:628f239d4-1za5-4731-b227-ce1f89dc2e97</dc:identifier> As such, I've been adding a second <dc:identifier> that uses the ISBN, like so: <dc:identifier id="isbn">urn:isbn:9781548950752</dc:identifier> Whether all that info is completely accurate, I don't know, but for now this is working for me. Again, I stress that I am trying to follow the rules, pay the fees, and not trying to circumvent costs. These costs should be easily recoverable for anyone serious about the business.