[mpeg-OTspec] Re: factual error in the DSIG description in the OT spec.

[Hin-Tak Leung]

Dear Vlad,

I did not mean to say we should deprecate DSIG as the current ballot comments. And perhaps not in the mid-future either. So let me rewrite my earlier post to make it clearer:

- near future (ballot comments): correcting the spec so that it matches the most widely used implementation, by rubbing out one step in the description.
Perhaps it is easier to see it in the slide of my talk over last weekend - http://htl10.users.sf.net/tmp/FontVal-LG2016.pdf - if you flip between the last two slides, you can see that step 4 near the top is rubbed out. That's the change I am proposing (plus re-numbering step 5 afterwards) for now.

- mid-future: clarifying and scoping when DSIG is not useful, and what should be done. We know that DSIG is invalidated for any operation that involves subsetting and modification; and subsetting is increasingly common, it would be nice to explicitly say something along the line of 'for this usage and after this operation, it is recommended that the (now invalidated) DSIG table not to be included in the new font outcome'. 

- for the long term future: come up with a new signing algorithm/procedure that's compatible with contemporary need of distributing a modified version of the font. i.e. a new way of signing that is kept intact and still offers some degree of authenticity. A very naive and quick way of thinking in that direction, might be just signing and ascertaining the 'name' table part of a font with one's digital certificate, since it contains copyright declarations.   

I hope this is clearer.

Regards,
Hin-Tak


--------------------------------------------
On Tue, 19/4/16, Levantovsky, Vladimir 
<Vladimir.Levantovsky at monotype.com> wrote:

 Dear Hin-Tak,
 
 Thank you for your
 contributions and active participation in OFF-related
 discussions. While I agree with you that DSIG table
 hasn't seen much use and often comes in the way when
 webfonts need to be altered (e.g. subsetted for a particular
 content) - the deprecation of the table shouldn’t be taken
 lightly and we should definitely consider implications of
 doing so _if_ there are certain contingencies where various
 implementations might rely on presence of certain tables to
 enable advanced layout functionality. 
 
 I consider any changes to DSIG table (either
 editorial or functional or deprecation) to be a major change
 that is definitely needed and is likely to be a benefit but
 I am not sure if we can do so within a scope of the current
 ballot comments and definitely not until we have heard from
 MS and other major stakeholders. The change like this might
 be much more suitable as part of the next major revision of
 the spec that is expected to be initiated later this
 year.
 
 I'd like to ask
 all interested parties to express their views on the DSIG
 table functionality and share their experiences (either
 negative or positive) with using it.
 
 Thank you,
 Vladimir
 
 
 -----Original
 Message-----
 From: Hin-Tak Leung [mailto:htl10 at users.sourceforge.net]
 
 Sent: Thursday, April 14, 2016 6:01 PM
 To: mpeg-OTspec at yahoogroups.com;
 opentype-list at indx.co.uk;
 mstwsite at microsoft.com;
 Levantovsky, Vladimir
 Subject: RE:
 [mpeg-OTspec] Re: factual error in the DSIG description in
 the OT spec.
 
 Dear Vlad,
 
 For the mid-term future,
 seeing as DSIG is little used, and not useful for web fonts
 which are seen as increasingly important, it would be nice
 to explicitly deprecating DSIG tables (that some vintage of
 MS Windows' rendering behavior depends on its presence
 is a bit unfortunate - perhaps a paragraph about 'if the
 font is for this purpose, ....' in the 'recommended
 practice' section); or for somewhat longer future, to
 come up with a new format that's compatible with
 sub-setting and web font usage. I think acertaining the
 origin/authorship/copyright status of a font is a good
 thing, we just need to find a new format which can do that,
 while surviving sub-setting and web font usage.
 
 For the short-term, the
 Microsoft folks had been somewhat quiet on this matter... it
 would be nice to confirm the disagreement between the spec
 and the most widely-used MS implementation (not the
 'only' as Adam Twardoch kindly pointed out), and
 come to an addendum in the spec - either remove the 4th step
 in the procedure of 5 in the spec slightly to match it, or
 add a sentence about the most widely used implementation
 does not quite do what the spec says.
 
 Regards,
 Hin-Tak