RE: Preprocessing and tool source tables

Hi John, all,

I am 100% in agreement that custom / tool-specific SFNT tables should be stripped prior to font conversion to a webfont. Like you said, VTT is one such tool that inserts custom SFNT table into font data, I believe that FontForge is also guilty of this although off the top of my head I don't remember the table tags that it generates. These custom tables only have value for the tools that generate them and represent a needless font data bloat for a browser, if delivered as part of a webfont.

Having said this, I am not sure if the removal of custom tool tables is in scope of the WOFF 2.0 as it's been defined by the WG charter. I would consider this a separate input conditioning step with "dirty SFNT" data going in and "clean SFNT" produced as an output that is, in turn, becomes WOFF 2.0 encoder input. While this can definitely be done as part of the single WOFF 2.0 encoding step, I am not sure the WOFF 2.0 spec should deal with it. For the reasons mentioned above I would rather see WOFF 2.0 spec completely agnostic to this "dirty laundry" type of processing.

Thank you,
Vlad


-----Original Message-----
From: John Hudson [mailto:tiro@tiro.com] 
Sent: Thursday, March 27, 2014 5:19 PM
To: Levantovsky, Vladimir; Jonathan Kew; Raph Levien; public-webfonts-wg@w3.org
Subject: Preprocessing and tool source tables

The discussion about recognised table tags has me wondering whether stripping of recognised tool source tables might be a reasonable preprocessing step? There are a few font tools that use the sfnt structure as a source format and store custom tables in the font; when the font is 'shipped' from these tools, the source data is compiled to standard font tables and the custom source tables are stripped. 
Obviously web fonts should properly be made from shipped fonts, and not from sfnt files containing source tables, and in a sane world we'd be able to rely on the makers of WOFF files and/or WOFF creation tools to ensure that this is the case. However, since these custom source tables can be of very significant size, and clearly inappropriate to include in any web font, I wonder if it would make sense to identify known source table tags in the spec as invalid for inclusion in a WOFF?

Offhand, I would include the following VTT and VOLT source table tags in such a list:

 TSI0
 TSI1
 TSI2
 TSI3
 TSI4
 TSI5
 TSIV

[If Microsoft can confirm the convention of beginning all custom source table names with 'TSI', we could presumably declare any such tag invalid for inclusion in a WOFF.]


JH

Received on Monday, 31 March 2014 08:37:05 UTC