RE: DSIG and other issues

Hi David, Jonathan, all,

David, you're absolutely right that there is no requirement for an OpenType font to have DSIG present, and the specs do not mandate it. However, the reality on the ground is that since DSIG was introduced as part of the OpenType spec some application developers decided to use its presence as a differentiating feature between OpenType and TrueType font, and used it as a flag to enable other complex OT features in .ttf fonts. I hope this would change soon, but for now we are stuck with this and the only question that remains to be answered if this behavior is specific to certain applications only or if this is something that is implemented on much deeper level and is related to existing APIs. I hope someone may be able to clarify this.

Regardless of the specific apps or APIs behavior, after careful consideration of all possible WOFF2 options w.r.t. DSIG treatment ( and I am speaking now with my chair hat off, just as a group participant) - I'd lean towards the option that WOFF2 encoder should signal the presence of the DSIG in the original font. We know that the DSIG table signature(s) will be invalidated by WOFF2 processing, and, therefore, it would be absolutely useless to keep DSIG as part of the compressed data stream, but if we indicate that the original encoded font file had DSIG present we will enable decoders / browsers to make their own choices based on that information. I don't think that WOFF2 spec should mandate the recreation of the DSIG table in any form, but if the original font had it and this was indicated in the compressed file - the decoder will be able to act on it based on the specific implementation needs.

As far as the way to indicate the presence of DSIG in the original font, like I said in my previous email - we have different options available, but my personal preference would be the following: 
- WOFF2 encoder to indicate the presence of the DSIG in the original file by adding 'DSIG' as an arbitrary table flag using the last table directory entry (with 'transformLength' set to 0), and leave the actual DSIG out of the compressed data. To me, this seems like the cleanest solution that doesn't require any special treatment for DSIG. I am not opposed to using one of the reserved flags (set with the last table directory entry) to indicate the same, but IMO separate DSIG entry with length=0 is a much cleaner indication of what's been done to the original DSIG.
- WOFF2 decoder will not be mandated to do anything about DSIG but will be given an option to create an empty DSIG with no signatures (as Behdad suggested). The decoder will also set bit 11 of the 'head' table flags so that it is clear that the output font was subjected to a content-aware modifying transform (regardless of whether an empty DSIG was added or not).

Thank you,
Vlad


-----Original Message-----
From: Jonathan Kew [mailto:jfkthame@gmail.com] 
Sent: Friday, May 23, 2014 5:25 AM
To: David Kuettel; Levantovsky, Vladimir
Cc: Behdad Esfahbod; Chris Lilley; w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: 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 13:43:46 UTC