View Full Version : InDesign CS5.5, Embedded Fonts and Validation
07-17-2011, 08:40 PM
If you didn't know, InDesign CS5.5 can embed fonts and they work in Adobe Digital Editions and eReaders using Adobe technology such as the Nook. My question has to do with getting embedded fonts to validate.
Let me explain a bit more of a sample workflow:
1. Export from InDesign CS5.5 with embedded fonts. They work in ADE and Nook, great!
2. But the ePub doesn't validate. Someone told me that to get the fonts to validate, I have to edit the encryption.xml and
After I do this change, the ePub validates! Sounds great, but the fonts do NOT work any longer! They don't work in Digital Editions or on Nooks (where they did back in step one).
Any ideas? I've attached two ePubs:
1 is a straight export from InDesign with working fonts, but doesn't validate.
2 is the same file with the URL changed so it validates, but that stops the fonts from working.
So here are my questions:
#1: Is it possible to have an ePub with embedded fonts validate with the fonts still working?
#2: If I can't have them validate, does it matter for getting them accepted for sale on the Nook or iBooks stores?
Any help you can provide is greatly appreciated.
07-17-2011, 08:48 PM
I've had plenty of ePub with embedded fonts validate.
After seeing the first sample, I'm not sure I'd want it to validate. That is not a good font at all.
07-17-2011, 09:00 PM
That is just a test file, so let's not get hung up on the font choice OK? :)
You say it's possible, but offered no details on how to get it working. What's different? Do you have a sample ePub with working embedded fonts that validate? That way I could look at it and see what InDesign is doing differently.
I'm trying to figure out if InDesign is just doing something wacky, and if so, what do I need to do to fix it so I get the font working and validating. Beyond the question of can it work, I also want to know "how" to get it to work!
07-17-2011, 09:26 PM
OK, one thing I just tried is to delete the encryption.xml file that InDesign produces. If I re-zip the ePub the fonts still do not work. BUT if I swap out the fonts that InDesign puts into the ePub with the original font files, THEN I get an ePub with working fonts that DOES validate. Soo... that leaves me wondering:
Should the fonts in the ePub be:
A. the original font files
B. the ones InDesign adds (which are a smaller filesize than the original so they are obviously changed somehow, probably encrypted somehow)
C. something else. Is there some way to make a reduced filesize version of the font that I should be using in ePubs? If so how do I make that? I bring this up because I know websites like fontsquirrel.com have a font-face generator to make web optimized versions of the font files. Should I be using that for ePubs as well?
And lastly, is it OK to not have the encryption.xml file in commercially sold ePubs that contain embedded fonts?
07-17-2011, 09:42 PM
I managed to fix the code so it is valid. But the problem is the font. It is encrypted. If you have a non-encrypted font, the code will be fully valid.
The problem is that using ADE, the font encryption is non-standard and doesn't validate.
07-17-2011, 09:55 PM
I've replaced the font with a different non-encrypted font and now it passes the validation. Take a look at it and you can see what was done to fix it.
07-17-2011, 09:58 PM
So you're confirming part of what I wrote in my previous reply, but there are still some outstanding questions... It seems like I can use the regular font and that works, but is that what I "should" be doing? If so, why does InDesign encrypt the font when it can't validate?
Keep in mind I am not just trying to get this to work for myself, I am wondering what the professional answer is for companies and authors submitting ePubs for sale to Apple and Barnes & Noble.
- If the fonts should be encrypted and validation doesn't matter, I don't care as long as I know.
- If it's OK to use the regular font so it does validate fine, it's just weird that InDesign doesn't do that from the start, although not entirely surprising considering some of the other bad code things it does.
07-17-2011, 10:03 PM
One thing a lot of publishers do is use a Charis SIL which is a free font family. They embed that and all is well. No need to encrypt it. Why ID encrypts I have no idea. For example, the new Star Wars eBooks use Charis SIL.
07-17-2011, 10:56 PM
Embedding fonts with Adobe's "Embed Fonts" option never validated in CS5 so it probably never will in CS5.5. They compress the fonts. Adobe probably don't want fonts floating about in ePubs that can be easily removed and used for free.
07-18-2011, 01:41 AM
The big joke is the differences between these two methods are trivial: both generate a key from the epub's first UUID, Adobe uses a 16-bit key XORd over the first 1024 bytes and IDPF hashes the UUID to create a 20bit key XORd over the first 1040 bytes.
At its root, this issue dates back to the silly political squabbles that occurred a few years ago when the ePub standard was being formed. This has resulted in the present mess where there's a large installed base of ADE-compatible readers using one method of font mangling, and another large base consisting of one device (the iPad) which doesn't (or may use the IDPF method since Apple has recently started to allow font embedding). Nothing has changed in the ePub 3 standard, which makes me think the IDPF thinks they can win by rigidly sticking to their guns and sticking their heads in the sand.
If your licence obliges you to obfuscate the font in order to embed it then you'll need to prepare different versions. If you're mangling a font for a book to be sold on iTunes, then you'll need to follow the idpf specs (there's a script from pdurrant floating around on the forum that will do it for you). For everywhere else, the output from InDesign should be fine. I'm not entirely sure about B&N, but their system works with ADE DRM in general, so it should be fine.
As far as epubcheck goes, it only generates a warning when it finds an Adobe-mangled font, that doesn't mean the epub isn't valid, and whatever system interprets the results should be smart enough to recognise that.
07-18-2011, 01:52 AM
Thanks cheleski, that really helps explain things a lot!