- From: Chris Lilley <chris@w3.org>
- Date: Thu, 22 Oct 2009 12:42:08 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- CC: Sylvain Galineau <sylvaing@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Hudson <tiro@tiro.com>, "www-font@w3.org" <www-font@w3.org>
On Wednesday, October 21, 2009, 10:42:53 PM, Robert wrote: ROC> On Thu, Oct 22, 2009 at 9:26 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote: ROC> ROC> That they would have to do that is currently based on a set of ROC> assumptions around both licensing and the current definition of ROC> the CWT format, which is based on a rootstring-less header version. ROC> Right. I argued on this very list that for this reason, it ROC> should be possible for EOT fonts containing a rootstring to also ROC> be valid CWT fonts (although the rootstring would be "padding ROC> data" as far as CWT is concerned), but to no effect (so far). A CWT font with no rootstring has fairly clear implementation obligations. An EOT font with a rootstring has murky enforcement obligations. A CWT font that is allowed to contain a rootstring in the binary padding seems like the worst of both worlds, and I would not like to stand up in court and defend either the design, or have a jury try to divine the font creators' intentions, from that case. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Thursday, 22 October 2009 10:42:17 UTC