RE: DSIG and other issues

Hi David,

The specifics on how the presence or absence of DSIG affects the OT layout isn't known in details (at least, not to me). According to the email from Simon Daniels to the MPEG OT-spec list, "DSIG is currently the defined way to differentiate between an OpenType font and a TrueType font, and some apps use the presence of the table to treat the font differently than a regular TrueType font. By definition all OpenType CFF fonts are OpenType, so DSIG isn't needed." The expectations are that if a Windows app uses its own code for OT layout (as e.g. Adobe applications do) - then they are not affected by it. However, if an app uses Win API to do the layout, then it may be affected by the differences in font treatment based on whether DSIG is present or not.
If Chrome browser has its own layout code then it is probably not affected. I hope that Sergey may be able to help us to learn more about this issue and see if we should consider spec changes.

Thank you,
Vlad


From: David Kuettel [mailto:kuettel@google.com]
Sent: Tuesday, May 20, 2014 7:55 PM
To: Levantovsky, Vladimir
Cc: w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: Re: DSIG and other issues

On Tue, May 20, 2014 at 3:33 PM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto:Vladimir.Levantovsky@monotype.com>> wrote:
Folks,

I am traveling this week and won't be able to join the telcon tomorrow, we will resume next week.

One issue that was discussed recently at the MPEG font list about DSIG is the reliance of some of the Windows  applications on DSIG presence to distinguish OT fonts from TTF, and by extension, to use this distinction to enable the OpenType layout features. 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. Let's give it a time to discuss it at the next telcon (on May 28).

Most interesting.  Would you happen to know what Windows applications (or underlying APIs) rely on the presence of the DSIG table?

Specifically, I am eager to know if browsers (such as Chrome, Firefox, Internet Explorer) would be impacted.

In quickly testing with Chrome M36 + the Google Fonts directory + a few complex scripts (Devanagari, Khmer) + WOFF 2.0, the OpenType functionality appears to work (at least to my untrained eye).  Would we expect it to not work?

Reconstructing the DSIG table is an interesting idea.  Perhaps (if the impact is limited), the respective Windows browsers (or WOFF 2.0 consuming applications) could take this on?

Thank you,
Vlad