Those who use Adobe InDesign to create ePubs will know you have the option to embed fonts in your ePub document. What you may not know is that Adobe are encrypting most embedded fonts, creating an “encryption.xml” file in the META-INF folder that can cause your ePub to be rejected by some retailers and may make it fail validation.
I first discovered this problem when my latest ebook, the second edition of The Global Indie Author, was rejected by Barnes & Noble for containing an encrypted file. Huh? I thought. The file had been passed by three validation programs including ePubCheck; what on earth was B&N going on about?
Unpacking the ePub in 7-Zip revealed the culprit: the encryption.xml file. When opened in Dreamweaver, the xml file looked like this:
So now I knew the encryption was font-related. Further research, however, revealed an apparent contradiction: Courier New is owned by Monotype Corporation and licensed by Microsoft. According to the Microsoft webpage on font permissions, “Most fonts distributed with Microsoft products allow embedding.” A check of the font in my Windows font folder lists Courier New as “editable”; according to Microsoft, “ ‘[e]ditable’ fonts can be embedded within content that can be edited by the user.” So why was Courier New encrypted by InDesign?
Similarly, Adobe’s Font Permission List provides a guide to which of their fonts are covered by which level of licensing permission; fonts listed as “embeddable” are embeddable in digital documents:
Fonts with an editable embedding permission can be embedded in electronic documents, and the embedded font can then be used by the recipient of the electronic document to view, print and further edit or modify the text and structure of the document in which it is embedded.
Again, then, why is a font classified as “editable” or “embeddable” in my fonts folder being encrypted in an ePub book? And why only Courier New and not Georgia?
According to the International Digital Publishing Forum, which governs the development of the ePub format,
[m]any commercial fonts allow embedding, but embedding a font implies making it an integral part of the publication, not providing the original font file along with the content. Since integrated zip support is so ubiquitous in modern operating systems, simply placing the font in the zip archive is insufficient to signify that the font is not intended to be reused in other contexts.
However, neither Adobe nor Microsoft make this distinction in their documentation. Only Monotype Corporation state on their website that “…embedding fonts into any documents sold commercially, such as e-books, e-magazines, e-reports, etc. requires an additional licence.” But how valid is this demand? Many ePubs are sold DRMed; this prevents the file from being legally opened by an extraction program and therefore the font from being copied. Does this not itself imply the content, including the font, is not intended for reuse? And couldn’t authors who elect not to use DRM (and even those who do) simply include on their copyright page that the font is copyrighted by the copyright holder, is used by permission, and is not intended for reuse?
And considering the ubiquity of the Windows operating system, who would bother trying to steal something they already have? I can understand this issue arising from the use of a custom font in a fixed layout ebook, but how much of an issue is this, really, for the typical ePub novel written using a standard websafe font, and where the reader has the option to ignore publisher embedded fonts and use a font included with the ereader instead? And does the average ebook consumer even care to steal fonts? Fonts are really the domain of designers who, let us be honest here, can easily procure a coveted font from a fellow designer or off a peer-to-peer site; they certainly do not have to buy the ebook.
Moreover, other behaviour of Adobe with regards to fonts is blatantly contradictory: graphic designers using InDesign can “package” a document for transfer to another designer or to a printer, and this package includes the fonts used in the document. Doing so allows the printer or other designer to install the fonts on their system and continue to use them without permission. So why are ebooks being singled out?
In other words, is this a legitimate copyright claim or just another money grab?
According to both Adobe and the IDPF, the solution to this (manufactured?) dilemma is to “obfuscate” (encrypt) a portion of the font to prevent a user from opening up an ePub and extracting the font for their own use. But three issues arise from this:
1. The rejection by retailers of an ePub with any encrypted files embedded within, as was evidenced by B&N’s rejection of my initial file.
2. Conflict between two encryption methods, Adobe’s and the IDPF’s. Instead of moving toward a single, open-source method in keeping with the spirit of the open-source ePub format, Adobe are eschewing the encryption algorithm published by the IDPF and are instead barging ahead with their own proprietary method and making it mandatory for users of their software. This proprietary encryption method is unreadable by some ereaders and can render the file unusable. Where are Adobe going with this? I infer an intention to license the encryption key to ereader manufacturers, which deepens my suspicion that this is just another money grab.
3. Encrypting the font to prevent piracy, and requiring the purchase of a separate licence to use for digital documents, are two separate issues. Monotype want the publisher to pay a separate royalty for digital use, while Adobe have not specified any such demand; neither have Microsoft, even though they license fonts from Monotype. However, by claiming that embedding fonts is “distribution,” both Adobe and Microsoft imply that such use is not covered by the terms of their current licences. And while Monotype want the publisher to pay and make no mention of encryption, even though paying a separate fee does not prevent piracy, Adobe and Microsoft imply that font encryption alone addresses their concerns. This creates confusion for publishers: can one legally use a Windows font even if it were licensed from Monotype, and if not are Microsoft going to make public the terms of their licence with Monotype in order to provide clarification? And since neither Adobe nor Microsoft are specifying terms for “distribution,” what are the potential penalties for embedding a font but not encrypting it, especially if there is no evidence that font piracy has taken place as a result?
Thus, the real solution for indie authors is not to embed any fonts into your ePubs. However, in the case of a book like The Global Indie Author, which requires the use of a Courier-like font to mimic HTML code and differentiate that text from the surrounding text, or for fixed layout ebooks where the font may be integral to the design, authors can instead use open-source fonts and embed these in their ebooks without the need for encryption. Websites such as The League of Movable Type and the Open Font Library offer several options, and Liberation Fonts closely resemble Monotype Corporation’s Arial, Arial Narrow, Times New Roman, and Courier New, the four most widely used fonts by Windows users.
For Kindle books, the InDesign plug-in now allows for embedded fonts, but Amazon do not encrypt them; instead, Amazon merely warn designers to ensure they possess the appropriate permissions. Also, embedding fonts significantly adds to file size, which will add to your delivery costs. Only embed fonts, then, when absolutely necessary and when the font you are using is not already included in the Kindle readers’ font library.
By the way, the answer to my question as to why InDesign encrypted Courier New and not Georgia is this: complete inconsistency in the program’s design: when tested further, on some occasions InDesign encrypted both fonts while in others (like my original file) InDesign encrypted only the one font. Go figure.
I am using CS5.5. In my research I did not find anything to suggest that Adobe are now using a non-proprietary algorithm; in fact, everything I have read suggests otherwise. Also, Sigil offers the option to encrypt fonts and the latest version (October 2012) still gives users the option to select the IDPF’s or Adobe’s, again suggesting two different formats still exist.
I don’t see how you say that Adobe’s (“Adobe Digital Editions”) encryption was a legitimate vendor extension and then say the existence of two flavours is not Adobe’s fault: they chose to modify the open-source code to make it proprietary when they had the option from the start to use the coding developed by the IDPF as is. That the IDPF has now mandated its code for ePub3 suggests to me that Adobe have been reigned in.
More importantly, not all ePubs require the use of ePub3 formatting and the format is not yet standard across the industry; many if not most ePubs are still using ePub2. So how does making the IDPF standard only for ePub3 solve the problem with ePub2?
If the use of the IDPF standard is mandated for ePub3, then Adobe should be updating previous versions of InDesign and sending out a fix, not expecting publishers to upgrade to CS6. This has not been done. Perhaps the IDPF needs to have another word with Adobe.
Whether B&N have a bug in their system does not change the fact that they are rejecting files with any form of encryption in it and that affects publishers’ bottom lines. The reason, my research suggests, is that older ereaders cannot read the encryption file; why would B&N want to alienate their consumers by accepting and selling such ebooks? Perhaps it is for the IDPF to work with B&N and figure out a solution.
And lastly, this only addresses the technical issues; the larger issue, that of why font encryption is suddenly deemed essential for ebooks, and the confusion over what licence governs what, is unanswered by technical updates.
Hi,
What version of ID are you using and did you select the right font embedding option? Adobe’s original scheme for font obfuscation (encryption) was a vendor extension (legit, since EPUB allows custom encryption) that predated standardization by IDPF. The later standardized version adjusted the algorithm slightly for unknown reasons (so the existence of two flavors is not Adobe’s fault). I believe Adobe’s approach is now obsoleted by them, and that if you are using CS6 with default options you should get the IDPF standard, particularly if you select EPUB 3 output for which this is mandated. If not, that’s an ID bug. If B&N rejects that, that’s a bug on their part.