- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Sat, 18 Oct 2008 08:41:54 -0700
- To: "robert@ocallahan.org" <robert@ocallahan.org>
- CC: "bert@w3.org" <bert@w3.org>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <7C2F64B551D8664AAD94A28DAC37D020670924CA4A@NA-EXMSG-C103.redmond.corp.microsoft>
Silverlight 2 is in fact different, and I think I can explain how different. I am not sure however why this argument would have any value (beyond being embarrassing for Microsoft, which has already been established). If there is an existing implementation that is different from what is a new standard being proposed, why would it affect the proposal? From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan Sent: Friday, October 17, 2008 6:48 AM To: Alex Mogilevsky Cc: bert@w3.org; www-style@w3.org Subject: Re: CSS3 @font-face / EOT Fonts … The Silverlight argument Microsoft's Silverlight version 1 doesn't use EOT and creates unprotected, downloadable OpenType files. Microsoft's competitors naturally claimed unfair competition: If W3C standardized EOT, DHTML/AJAX applications might have to use EOT, but Microsoft itself uses an easier solution. Microsoft has since said that they made a mistake and promised that version 2 will not create raw font files anymore, only embedded ones. So this argument is no longer relevant. This is incorrect. Silverlight 2 is completely capable of using bare font files, either packaged in the application ZIP file or at standalone URLs in the same domain, via the WebClient interface. Silverlight 2 does not support EOT. Furthermore, Silverlight developers are exhorted to respect font licensing restrictions, but Microsoft's internal conclusion that "font embedding" permissions do not apply to Silverlight applications does not seem to have been communicated to Silverlight developers.
Received on Saturday, 18 October 2008 15:42:42 UTC