Multiple renditions and obfuscation

[mattgarrish]

The document doesn't explain how obfuscation is supposed to work when there are multiple renditions.

Since unique identifiers are allowed per-Rendition, and there's also a unique identifier required in the metadata.xml file, which of these are supposed to be used? (Is obfuscation done per-Rendition?)

If the unique identifier is the one in the metadata.xml file, then that seemingly requires that the identifier be the same as the one in the first rendition for reading systems that don't process multiple renditions.

[dauwhe]

I wish we would hear from people who have implemented this.

It seems weird for the same package to contain both obfuscated and non-obfuscated fonts. It seems weird to have to use different keys to de-obfuscate fonts in the same package. It also seems weird to use the unique ID from metadata.xml, when that's not necessary for "ordinary" EPUBs. I don't have a good answer.

[mattgarrish]

It also seems weird to use the unique ID from metadata.xml, when that's not necessary for "ordinary" EPUBs.

The only answer seems to be that you must use the unique identifier in the metadata.xml file and that that identifier must be the same as the one in the first package document. It could also be that the unique identifier of the first package document is always used, but then that sort of undercuts the idea of pan-rendition metadata.

Having different keys for different packages makes resource sharing between renditions impossible. Having different IDs in the metadata.xml and first package document likewise makes for corrupt resources when the former is the key.

But do we even want to solve this now or should we just leave it with the other outstanding MR issues until some tangible amount interest is shown? This falls outside of strictly harmonizing with the 3.3 changes.

[murata2makoto]

@babatakao Does BPS uses obfuscation?

[babatakao]

No, we (BPS) don't use font obfuscation.

[murata2makoto]

Thanks, @babatakao. I now think that we should not try to solve this issue right now.

[iherman]

Thanks, @babatakao. I now think that we should not try to solve this issue right now.

If there is an ambiguity that is not covered by the spec then we are obligated to talk about it. I agree it is not necessary to do it right now, but we should solve this before we go to CR imho.

[murata2makoto]

@iherman Not an issue in the Core or RS specs. Will be an issue in the upcoming note for multiple renditions.