- From: Tal Leming <tal@typesupply.com>
- Date: Fri, 25 Mar 2011 11:41:17 -0400
- To: Chris Lilley <chris@w3.org>
- Cc: WOFF Working Group <public-webfonts-wg@w3.org>
On Mar 25, 2011, at 11:02 AM, Chris Lilley wrote: > TL> Please let me know if you have comments, suggestions, concerns, etc. > > The "should convert to WOFF: yes/no" is clear for something like a command-line WOFF converter. > > I wonder what we should do for something like a font editing tool,where the sfnt is imported and the woff is exported. The tool may issue warnings or offer to clean up errors in the sfnt or, possibly, silently correct them; as that preceded the woff conversion spec they we can't, and probably shouldn't, say its a failure of woff conversion. > > We should be clear on the pass/fail criteria where there are separate sfnt-import and woff-export stages. That's a good point. We have this in the spec: http://dev.w3.org/webfonts/WOFF/spec/#conform-incorrect-reject > If the input font has defects or anomalies that make this impossible, the WOFF-generating tool SHOULD either reject the font or issue an appropriate warning that lossless round-trip conversion will not be possible Do you think a note at the top of the test suite page would be a good way to address this? It could say something like this: The tests in this suite represent SFNT data to be used for WOFF conversion without any alteration or correction. An authoring tool may allow the explicit or silent modification and/or correction of SFNT data. In such a case, the tests in this suite that are labeled as "should not convert" may be converted so long as the problems in the files have been corrected. The bitwise identical tests may also fail as a result of an authoring tool's modifications. This is a really tricky thing to explain... Tal
Received on Friday, 25 March 2011 15:41:47 UTC