Re: New work on fonts at W3C

On Jun 24, 2009, at 12:49 PM, Levantovsky, Vladimir wrote:

> On Wednesday, June 24, 2009 2:47 PM Brad Kemper wrote:
>>
>> On Jun 24, 2009, at 10:52 AM, "Levantovsky, Vladimir" wrote:
>>> On Wednesday, June 24, 2009 1:19 PM Brad Kemper wrote:
>>>> No, but that won't change until Microsoft starts supporting the  
>>>> same formats as Firefox, Safari, and Webkit. [...]

>>> Why is that someone has always have do what someone else has done,  
>>> even if there is no consensus for it.

>> Because there is near consensus among implenters about the value of  
>> supporting raw file formats, with the one major exception being the  
>> company that is nearly always lagging in standards support (for  
>> about the last decade anyway).
>
> You forgot to mention font vendors who do not support raw file format,
> so the company you mentioned isn't really a one major exception.

I did not forget. You may have noticed that in answering your question  
about "why do what [implementors have] done" (see quotes above,  
because that is what we were talking about), I began that sentence  
with "Because there is near consensus among implementers" (aside from  
misspelling it the first time). Font vendors are not implementors. I  
also didn't mention end users, magazine reviewers, and Chinese  
communist party officials. We all might hope that implementors listen  
to us and give weight to our arguments, but it is the major  
implementations that determine the viability of one approach over the  
other. Everything else falls out from there. Monotype can say they are  
going to give EOT licenses to everyone, but that doesn't matter much  
to the users of the other major UA implementations if they don't also  
support EOT.  Looking at a larger group—containing more and more self  
interested parties— for consensus will virtually ensure that there is  
none. There is unlikely to be consensus among all font publishers for  
the decisions all UA implementors take, but there are some font  
publishers that are today expanding the number and reliability of  
fonts that can be used in Web site designs (directly, without images,  
FIR, etc.).

And also, by the way, any new format will much less useful until the  
majority of users have upgraded to a version that supports it. In my  
experience, IE users are the slowest to upgrade (I still have to deal  
with about 30% of all my site visitors being on IE6, about the same as  
all Firefox visitors to my site). So If I want a cross-browser  
embedded font experience, then for years to come it will be EOT plus  
whatever the other browsers support (and "raw" fonts have a head start  
on any new wrapper format).



>>> We could be much better off if we get out of the trenches and  
>>> adopt a position that, as Aryeh said, may not be ideal but can  
>>> work and would satisfy all parties involved.
>>
>> Great! Glad to hear that you will now be supporting Daggett's scheme,
>> and that Microsoft will be concentrating the @font-face improvement  
>> on
>> supporting regular formats as well as the other implentors are.
>>
>
> Speak for yourself. And you apparently missed the last part of the
> sentence, I did say that a solution "would satisfy all parties
> involved".

Well, if you are going to define "all parties" very broadly, then you  
will never satisfy all parties. I am an involved party, and your  
suggestions have not satisfied me to nearly the same extent as John  
D.'s name-changing proposal. So apparently by saying "would satisfy  
all parties involved" you mean that it would satisfy you but leave me  
disappointed. Or perhaps you mean that others should concede major  
compromises and be satisfied, but you could never do the same. If you  
think others' compromises can lead to their satisfaction, then why not  
accept a font-renaming compromise and be satisfied yourself? And why  
shouldn't Microsoft also try to be satisfied by compromising and  
offering support for regular font formats? It would be much easier for  
them to do so than to expect all other UAs to change.