Re: DSIG and other issues

Thank you Vlad and Behdad.

It will be incredibly helpful to hear back from Microsoft on the importance
of the DSIG table for browsers using the Windows APIs.  In particular
DirectWrite, which Internet Explorer and Firefox currently leverage, and
which Chrome is currently adding support for.

Internally, we reached out to the Chrome + DirectWrite team, to see if they
could test a few OpenType (complex script) fonts with WOFF 2.0 to
understand the behavior in the absence of the DSIG table.  For reference,
this is quite easy to do now.  With Chrome M36+, just enable DirectWrite
(chrome://flags/#enable-direct-write) and access the Google Fonts Directory
(http://google.com/fonts) where the dynamically cut preview fonts are being
served as WOFF 2.0.  To my untrained eye, they appear to work, but we want
to be sure.

In regards to what decision to make, my preference would be the keep the
status quo -- to have the WOFF 2.0 conversion tools drop the DSIG table and
be done with it.

In the case that browsers on particular platforms absolutely needed to
create a DSIG (e.g. an empty one) to be compatible with existing APIs, it
would be ideal if the browser could make the determination based on other
attributes of the font, esp. given that specifications (as far as I have
seen) do not recommend making the TrueType vs. OpenType determination based
on the presence of the DSIG table.  Is that possible?

Were this not possible, then I would lean towards using one of the reserved
flag bits, to indicate that the font had a DSIG table that was removed and
thus it should create a new and empty one upon decoding the font.  I would
prefer to not change the known table tags, and leave them as is.  I think a
flag bit would be much clearer.


On Wed, May 21, 2014 at 3:51 PM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

>  Behdad wrote:
>
> Sure.  But I don't see why you would want to make a DSIG exception in the
> file format when it essentially saves nothing (5 bytes max?).  Perhaps add
> it back to the known-tables list.
>
>
>
> Yes, we can do that as well, although doing so would also require to
> redefine the 6-bit long field of the flags that are currently allocated to
> known table tags. Right now, we have exactly 63 known tables and the last
> entry is reserved for arbitrary tags.
>
> So, we do have multiple options to consider:
>
> -        Use extra flag bit to extend known table tags and add DSIG
> there,
>
> -        Or, keep the flag reserved and encode DSIG as an arbitrary flag,
> if present and
>
> - remove DSIG signatures and explicitly encode empty DSIG as part of the
> WOFF2 file, or
>
> - remove DSIG table completely and only encode its presence in the table
> directory (similar to 'loca', which will serve as an indication for decoder
> to insert empty DSIG table in the output file), or
>
> -        use a flag bit (e.g. set with the last table directory entry) to
> indicate the need to insert an empty DSIG.
>
>
>
> I don't have any strong preference to any of those options and their
> combination but since we do have choices - we need to make one.
>
>
>
> Thank you,
>
> Vlad
>
>
>
>
>
> *From:* Behdad Esfahbod [mailto:behdad@google.com]
> *Sent:* Wednesday, May 21, 2014 6:28 PM
> *To:* Levantovsky, Vladimir
> *Cc:* David Kuettel; Chris Lilley; w3c-webfonts-wg (
> public-webfonts-wg@w3.org)
>
> *Subject:* Re: DSIG and other issues
>
>
>
> On Wed, May 21, 2014 at 4:20 PM, Levantovsky, Vladimir <
> Vladimir.Levantovsky@monotype.com> wrote:
>
> In the scenario that Behdad proposed we would have to keep both the DISG
> entry in table directory and the empty table as part of the font data.
> Removing the DSIG table and inserting the empty DSIG table when the font is
> decoded is a possible alternative option, we would only need to record the
> presence of the DISG in the original file (we do have reserved flags that
> can be used for this) to let the decoder know when the empty one needs to
> be inserted.
>
>
>
> Sure.  But I don't see why you would want to make a DSIG exception in the
> file format when it essentially saves nothing (5 bytes max?).  Perhaps add
> it back to the known-tables list.
>
>
>
>
>
>
>
> Vlad
>
>
> On Wednesday, May 21, 2014 5:32 PM David Kuettel wrote:
> On Wed, May 21, 2014 at 2:18 PM, Behdad Esfahbod <behdad@google.com>
> wrote:
>
> > My recommendation is that the spec be changed, to recommend that if
> > the original font had a DSIG table, then all signatures in the DSIG
> > table be removed.  Ie. an encoder is encouraged to keep an a DSIG
> > table with zero signatures.  That's a valid table that is only eight
> > bytes.  (00 00 00 01 00
> > 00 00 00).
>
> Interesting.  So rather than removing the table all together (as the
> latest draft currently recommends, http://www.w3.org/TR/WOFF2/), just
> removing all of the signatures from the table if present.
>
> That sound great!
>
>
>