View Full Version : Font mangling for fun and incompatibility


llasram
01-21-2009, 06:29 PM
Yesterday the IDPF published on their Website an "informational document" on Font Embedding for Open Container Format Files (http://www.openebook.org/doc_library/informationaldocs/FontManglingSpec.html). This document describes a font-obfuscation method which is similar to Adobe's, but incompatible. The format of META-INF/encryption.xml means there is no confusion about which method is used, but a single file can't be obfuscated with both methods.

Come on, IDPF -- so Adobe has gone unilateral in extending EPUB in directions they want, but does recommending an incompatible obfuscation method (which no one implements) really help anyone?

kovidgoyal
01-21-2009, 06:38 PM
:rofl: Why on earth have they picked 1040 instead of 1024

wallcraft
01-21-2009, 08:59 PM
Why on earth have they picked 1040 instead of 1024 Perhaps because 1040 bytes is a multiple of the 20 byte key.

kovidgoyal
01-21-2009, 09:10 PM
No need for that, since its an XOR key there's no reason for the message length to be a multiple of the key length

Peter Sorotokin
01-27-2009, 02:37 AM
Come on, IDPF -- so Adobe has gone unilateral in extending EPUB in directions they want, but does recommending an incompatible obfuscation method (which no one implements) really help anyone?

We will implement it. Actually, I think, everyone who does embedded fonts will implement it eventually. Of course, we'd rather everyone would just implement what we did, but converging on a solution acceptable to everyone was more important.

llasram
01-27-2009, 10:04 AM
We will implement it. Actually, I think, everyone who does embedded fonts will implement it eventually. Of course, we'd rather everyone would just implement what we did, but converging on a solution acceptable to everyone was more important.

Ah, cool. *relaxes* Did the IDPF not want to use your algorithm because they didn't want to "require" books to have a UUID <dc:identifier/>, or was there some other reason?

And because everyone always asks you semi-related questions every time you show up :), is that approach going to apply to e.g. /package/spine/@page-map vs. /ncx/pageList as well?

In any case, thanks for letting us know!

Peter Sorotokin
01-27-2009, 01:07 PM
Ah, cool. *relaxes* Did the IDPF not want to use your algorithm because they didn't want to "require" books to have a UUID <dc:identifier/>, or was there some other reason?

This was voiced, but there were other reasons as well.

It is fairly misleading to talk about an organization such as IDPF as if it were a person. There are many different people with different agendas and opinions. A person can endure pain in one body part for the pleasure of another. Standard-developing process mostly works through consensus, so a solution has to be found that satisfies everyone. Basically, once you commit to standartizing, you have to think in terms of what is acceptable, not in terms of what (you think) is the best. To a lesser extent that applies to working in any big organization or "you ain't gonna make it with anyone anyhow".

And because everyone always asks you semi-related questions every time you show up :), is that approach going to apply to e.g. /package/spine/@page-map vs. /ncx/pageList as well?

I think IDPF will explicitly "bless" NCX pageList to provide page map information. Only minor changes to the spec are needed (but changes are needed; contraty to what some people claim, this functionality is not in the spec right now).

BTW, the way I show up is mostly by searching for threads that have the word "epub" used.

Peter