Re: EOT & DMCA concerns

On 5 Aug 2009, at 17:10, Sylvain Galineau wrote:

>> From: Jonathan Kew [mailto:jonathan@jfkew.plus.com]
>> Sent: Wednesday, August 05, 2009 1:30 AM
>
>
>> One concern I have is that if we all implement EOT-Lite (by whatever
>> name) now, it will be more difficult for a new and better format to
>> gain acceptance, and so we may end up with an inferior format in the
>> long term for the sake of short-term gain.
>
> That assertion has been made before but I'm not sure why that's true ?

If everyone implements EOTL now, then authors will naturally deploy  
EOTL fonts, because they'll work everywhere. That means that even if  
some of us implement another "better" format as well, authors are  
unlikely to bother deploying it because it won't work in legacy IE (or  
even current IE for a couple of years, perhaps). So the new format  
will not get any significant level of testing in the marketplace; and  
because EOTL will be the "universal" format in actual use on the web,  
there'll be little incentive for slower-moving vendors to bother  
supporting the new format at all.

On the other hand, if we define a web font format that provides  
tangible benefits (such as compression to reduce bandwidth  
requirements, and improved metadata support that many vendors would  
like), and do *not* rush to implement EOTL, there's a strong incentive  
for all parties to work towards support of the new format. Meanwhile,  
authors who wish to support web fonts on legacy IE browsers will need  
to deploy two formats for some time -- how long depends on Microsoft's  
business decisions, and on how slowly users upgrade, and on how  
concerned authors are about getting their chosen fonts to display in  
obsolete browsers. Is that such an unreasonable scenario?

> If the new format is better, acceptance should not be an issue. If
> .webfont and ZOT add so little value over a 100 bytes of header prefix
> that the latter would delay their adoption then maybe they need  
> thorough
> questioning, given that they will take more design and coding time.

I designed the .zot format, implemented sfnt2zot and zot2sfnt tools,  
and patched Gecko to support .zot fonts in less time than I've spent  
reading www-font messages in the last few weeks. It's not complex. And  
you're welcome to use the code. :)

(Not that I'm asking for that prototype .zot to be the final answer;  
it was merely a proof-of-concept, and I expect it to be adapted in the  
light of feedback from other parties, if we decide to go in that  
direction at all.)

>
> The data shows that Firefox, Safari and Opera users have a much  
> faster upgrade
> cycle. There are many reasons for this, including the user  
> population : many IE
> 'seats' are corporate/government for instance, and have very  
> conservative upgrade
> policies.

Perhaps if those corporate/government 'seats' are so slow to upgrade,  
they might also have relatively little interest in an explosion of  
downloaded font use, and be happy for the stability of continuing to  
see everything in Verdana et al.

> As it generally takes 18 months for a new IE release to replace 50% of
> its installed base and IE9 is no less than two years away, this is a  
> long time for
> authors and font vendors to wait. This is also what makes EOTL  
> relatively more attractive,
> despite known IE bugs. Whether the trade-off is worth it in practice  
> really depends on authors.
>
>> I don't think it is reasonable to let the outcome be dictated by an
>> assumption that "IE users can't be expected to upgrade in order to  
>> see
>> standard linked fonts; users of other browsers can".
>
> It's not an assumption. It's a fact. Our installed base is very  
> large and
> a significant fraction of it upgrades at a very slow pace.

And those who upgrade at a very slow pace should not expect to see the  
latest glitzy web features in their browser.

>
>> Microsoft is just as capable as any other vendor of delivering an  
>> upgrade that adds
>> support for a new font format, especially if it is a simple-to-
>> implement format such as .zot or .webfont.
>
> Even if we could just code up new features and push them in the  
> upgrade pipeline at will
> (which we can't and many of our paying customers have no desire for)  
> that does not make
> people deploy those bits any faster.
>
>> It comes down to vendor priorities and resource allocation, and  
>> user choice.
>
> Precisely. And many of our users do choose to upgrade slowly.

Fine. That's their choice. Then why are we trying so hard to deploy  
new fonts to them?

Jonathan

Received on Wednesday, 5 August 2009 17:11:31 UTC