- From: Thomas Phinney <tphinney@cal.berkeley.edu>
- Date: Mon, 17 May 2010 20:14:35 -0700
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
- Cc: John Hudson <tiro@tiro.com>, "rfink@readableweb.com" <rfink@readableweb.com>, John Daggett <jdaggett@mozilla.com>, Chris Lilley <chris@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>
Vlad wrote: > Since WOFF file format is supposed to be neutral to any specific flavor of SFNT-based font format, and because organizations and entities responsible for development and maintenance of existing font standards may in fact introduce future modifications that may be relevant to web font use (e.g. a new set of bits or a bitfield that may indicate specific conditions for web use), I tend to agree with Tom Phinney [5] (and others who expressed similar views) that it may be best for the WOFF spec to remain silent about embedding bits. I shared John Hudson's initial intent to clarify the relationships between the existing embedding permissions and WOFF, but I agree with John Daggett [6] and Sylvain [7] that an attempt to define conformant tool behavior isn't worth the distraction it creates. I believe I have come to this conclusion as well. The whole thing is a complex thicket, and there is no clear answer that will be best for all scenarios. Remaining silent on the matter, at least for now, seems best. (To parrot one example as a more specific case: Extensis' own WOFF generation currently and in the future will ignore any embedding bits, because our contracts with foundries explicitly give us permission to do things like make derivative WOFF files.) Cheers, T -- "I've discovered the worst place to wander while arguing on a hands-free headset." — http://xkcd.com/736/
Received on Tuesday, 18 May 2010 03:15:15 UTC