Re: DSIG and other issues

On 23/5/14 00:58, David Kuettel wrote:
> 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 <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.

How about OpenType features in Latin-script fonts -- e.g. ligatures, or 
contextual forms in cursive "handwriting" fonts? Do those work in 
DSIG-less fonts?

> 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?

I don't see why not. If a browser (or anything else that's using WOFF2 
fonts, for that matter) is intending to pass the font to an API that in 
any way depends on the this, it could simply insert an empty DSIG 
regardless of what may have been present in the original sfnt.

JK

>
> 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
> <mailto: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
>     <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 <mailto: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
>     <mailto: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 <mailto: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!____
>
>     __ __
>
>

Received on Friday, 23 May 2014 09:25:21 UTC