RE: DSIG and other issues

On Tuesday, May 20, 2014 10:17 PM Chris Lilley wrote:

On Wednesday, May 21, 2014, 12:33:06 AM, Vladimir wrote:

>  It is not
> clear whether only certain applications are affected, or any that use 
> the underlying Win API, but this is something we may need to 
> investigate because of the WOFF2 spec recommendation to remove DSIG 
> because it will be compromised  by pre-processing and reconstruction 
> steps. What we may consider instead (or in addition to) is to remove 
> the DSIG table while encoding a font and recreate a dummy DSIG (if the 
> original font had it) to preserve font compatibility with Win API.

That is a) gross and b) will be removed again by the font validators that are commonly used to check downloaded fonts.

Okay, I should have made myself clear and explain what I had in mind in more details. One possible way to remedy the problem is to:
- indicate whether the original font had DSIG table or not. If yes, the DSIG presence would be recorded by the encoder in the table directory but without the actual DSIG table present (which is similar to the way we treat the 'loca' table today);
- if DISG was present in the original font, the decoder would have to resign the font according to the algorithms specified by the DSIG table specification (http://www.microsoft.com/typography/otspec/dsig.htm).

I believe this approach should be perfectly compatible with the spec and with the current implementations.

Thank you
Vlad

Received on Wednesday, 21 May 2014 19:27:08 UTC