View Full Version : fontencrypt.py - Add Adobe encryption to fonts in ePub


pdurrant
09-19-2009, 06:47 PM
Here is my python script for encoding the fonts found in an ePub file. And also, for those on Mac OS X 10.5 (& probably 10.6), an AppleScript that turns using the python script into a drag&drop experience.

This script encodes the fonts according to the method Adobe uses in ADE. It does not use the IDPF method, as ADE doesn't seem to support than encoding method yet. EPubs with fonts encoded with the script /do/ work on the Sony PRS-505

Fonts must be declared in the manifest (in content.opf) of the ePub
The metadata element in content.opf must have contain a dc:identifier
The text of that element must start with the characters "urn:uuid:" or must have an ofp:scheme="UUID" attribute
The text of the dc:identifier (apart from any "urn:uuid:" prefix) must be at least 16 (preferably 32) hexadecimal digits, optionally spaced by dashes, and no other characters.

The first dc:identifier in the file meeting the above requirements is used, as per the Adobe spec.

Also attached is a sample content.opf showing the above requirements.

usage:
python fontencrypt.py infile.epub outfile.epub

(or just drag&drop an ePub onto the AppleScript)

Feedback welcome.

[Update: Now version 1.1 that correctly selects the first appropriate dc:identifier as per the adobe spec.]

[Update: Now version 1.2 that handles that case of a dc:identifier with both a UUID attribute and a urn:uuid: prefix.]

Jellby
09-24-2009, 01:22 PM
The package element in content.opf must have a unique-identifier attribute
The metadata element in content.opf must have contain a dc:identifier with an id equal to the value of the unique-identifier's value
The text of that element must start with the characters "urn:uuid:" and must continue with with at least 16 (preferably 32) hexadecimal digits, optionally spaced by dashes, and no other characters.

If I read the Adobe document (http://www.adobe.com/devnet/digitalpublishing/pdfs/content_protection.pdf) and the OPF spec (http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html#Section2.2.10) correctly, the OPF can have several <dc:identifier> elements, at least one must have an id, but having an id is not necessary for all of them. The "encryption" will use the first UUID URN-based identifier, which does not necessarily have an id, and if it has, it does not necessarily match the unique-identifier attribute.

What I'm trying to understand is what requirements are needed for the scheme to work in ADE and what are needed only for your script...

pdurrant
09-25-2009, 12:58 AM
You know - you're completely right. I got this wrong because the IDPF method is to identify the dc:identifier by id, and the one sample I had of the Adobe version also worked like this (but also did the urn:uuid: on the same dc_identifier)

So yes, it's possible for my script to not work if the ePub contains /two/ dc:identifier elements, both with urn:uuid:, and the second linked from the unique id attribute.

And it would also fail if there was no unique id attribute.

I'll fix it and upload a new version.

Thanks!

If I read the Adobe document (http://www.adobe.com/devnet/digitalpublishing/pdfs/content_protection.pdf) and the OPF spec (http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html#Section2.2.10) correctly, the OPF can have several <dc:identifier> elements, at least one must have an id, but having an id is not necessary for all of them. The "encryption" will use the first UUID URN-based identifier, which does not necessarily have an id, and if it has, it does not necessarily match the unique-identifier attribute.

What I'm trying to understand is what requirements are needed for the scheme to work in ADE and what are needed only for your script...

pdurrant
10-20-2009, 02:36 PM
And I now upload version 1.2, which fixes bugs in the identification of the UUID that I introduced in 1.1!



I'll fix it and upload a new version.

brewt
02-09-2010, 01:51 PM
Does the latest version of ADE break this? I thought I had this working until I upgraded to 1.7.2, now the epubs I had before with embedded/encrypted fonts don't show the fonts - they revert to system fonts. To say nothing about fresh ones.

Not to say I'm doing everything right; it just seemed odd.

-bjc

pdurrant
02-09-2010, 04:16 PM
Does the latest version of ADE break this? I thought I had this working until I upgraded to 1.7.2, now the epubs I had before with embedded/encrypted fonts don't show the fonts - they revert to system fonts. To say nothing about fresh ones.

Not to say I'm doing everything right; it just seemed odd.


Hmm... I don't know. I haven't upgraded to 1.7.2 yet. It certainly shouldn't break it - as far as I know the script processes everything to spec.

JSWolf
02-14-2010, 02:16 PM
Hmm... I don't know. I haven't upgraded to 1.7.2 yet. It certainly shouldn't break it - as far as I know the script processes everything to spec.

What the latest ADE (1.7.2) breaks is the key getting process. But I have a way around it that now works using a beta version of the key getter. But you may need to edit it to get it to work. What we need to do is get it so it just runs as is without needing to be edited.

pdurrant
02-14-2010, 02:47 PM
What the latest ADE (1.7.2) breaks is the key getting process. But I have a way around it that now works using a beta version of the key getter. But you may need to edit it to get it to work. What we need to do is get it so it just runs as is without needing to be edited.

This thread is about ePubs when only the fonts are encrypted, rather than the entire ePub being encrypted.

brewt
02-14-2010, 03:23 PM
What the latest ADE (1.7.2) breaks is the key getting process. .... What we need to do is get it so it just runs as is without needing to be edited.

As scripting = not allowed, and multiple encryption schemes can't possibly work, this should mean that formerly encrypted fonts now no longer work, but only somethimes? Which means re-doing formerly built font-encrypted books needing to be rebuilt to support the new process. Until the old version 1.7.1 actually completely expires, does this mean 2 versions of books are now needed? And what about devices?

Dagnab you adobe, making it all hard and all.

-bjc

pdurrant
02-14-2010, 04:20 PM
Hmm... I'll try updating to 1.7.2 and see if I can spot the problem. But not tonight.

As scripting = not allowed, and multiple encryption schemes can't possibly work, this should mean that formerly encrypted fonts now no longer work, but only somethimes? Which means re-doing formerly built font-encrypted books needing to be rebuilt to support the new process. Until the old version 1.7.1 actually completely expires, does this mean 2 versions of books are now needed? And what about devices?

Dagnab you adobe, making it all hard and all.

-bjc

brewt
02-14-2010, 10:12 PM
Indesign-embedded fonts still seem to work in 1.7.2. Embedded font tests from indesign in
http://www.mobileread.com/forums/showthread.php?t=66594

-bjc

pdurrant
02-15-2010, 11:06 AM
Does the latest version of ADE break this? I thought I had this working until I upgraded to 1.7.2, now the epubs I had before with embedded/encrypted fonts don't show the fonts - they revert to system fonts. To say nothing about fresh ones.

Not to say I'm doing everything right; it just seemed odd.

-bjc

I've just upgraded to 1.7.2 on Mac OS X. I'm still seeing my embedded encrypted fonts. (i.e. fonts encrypted with the script linked from this thread.)

If you upload a sample ePub that's failing for you, perhaps I can spot the difference that's causing the problem.

pdurrant
04-06-2010, 06:38 AM
I've just upgraded to 1.7.2 on Mac OS X. I'm still seeing my embedded encrypted fonts. (i.e. fonts encrypted with the script linked from this thread.)

If you upload a sample ePub that's failing for you, perhaps I can spot the difference that's causing the problem.

I have no experienced this problem. I no longer have an earlier version of ADE, so I'm guessing, but it seems that previous versions accepted opf:scheme="UUID" as identifying a valid uuid identifier, e.g.

<dc:identifier id="BookID" opf:scheme="UUID">c2ff824c-f984-4efc-844d-47875c302ba5</dc:identifier>

I'm certainly now seeing that the encryption key is only read if the urn:uuid: prefix is applied, and whether there's an opf:scheme="UUID" is unimportant.

So: make sure your have that urn:uuid: prefix on the identifier.

mmdigitalconnect
10-15-2013, 10:12 AM
Hi pdurrent

Do you have script using IDPF encryption method or advise me where to find?

pdurrant
10-15-2013, 10:16 AM
Hi pdurrent

Do you have script using IDPF encryption method or advise me where to find?

I do have one, but since at the time I wrote it nothing would render IDPF obfuscated fonts, it hasn't had final testing.