Font mangling for fun and incompatibility

[llasram]

Yesterday the IDPF published on their Website an "informational document" on Font Embedding for Open Container Format Files. 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]

Why on earth have they picked 1040 instead of 1024

[wallcraft]

Originally Posted by kovidgoyal

Why on earth have they picked 1040 instead of 1024

Perhaps because 1040 bytes is a multiple of the 20 byte key.

[kovidgoyal]

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]

Originally Posted by llasram

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]

Originally Posted by Peter Sorotokin

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]

Originally Posted by llasram

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