RE: New work on fonts at W3C

Hello Thomas,

On Tuesday, June 23, 2009 4:58 PM Thomas Lord wrote:
> 
> On Tue, 2009-06-23 at 14:43 -0400, Levantovsky, Vladimir wrote:
> 
> > Pending additional discussions on the same-origin restriction
> > and CORS, I can see that this compromise solution will address
> > the needs and concerns of all web users:
> > - simple to use by web authors
> > - minimizes bandwidth use for fonts - reducing the usage site
> > owners pay for, and improving the experience of billions of
> > users worldwide.
> > - satisfies the needs of font vendors (files hosted by a
> > servercvs -z3 -
> d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs
> > co <modulename> cannot be directly installed as system fonts);
> > - implementable by anyone, including open source browsers and tools.
> 
> 
> All of that is swell but a deep problem remains, at least
> in my opinion.
> 
> The odd thing about that compromise solution is that it
> puts W3C in the business of introducing a new font format
> for no reason other the business model concerns of a few
> players.
> 

I think it would be fair to say that what we are trying to do can be more accurately described as a new web font wrapper, which, in addition to font data, can also include additional metadata you proposed earlier.

> The impact is fairly large because we reasonably
> expect that UAs rely on existing font engines which means
> that either those font engines have to be modified or UAs
> have to go through this strange conversion step.  What
> justifies requiring that conversion step?
> 
> A touchstone question might be:  how does that conversion
> step benefit users?

I see your point. In my opinion, by introducing this simple conversion step we address the concerns of the font vendors and, in turn, it would benefit web users by making large collection of high-quality fonts available to them. As a result web users will also benefit from high quality typography and worldwide language support on the web.

> 
> The compression aspect I can see.  There is an obvious
> benefit to users with that.  Indeed, compression is desirable
> orthogonally to the web.
> 
> The obfuscation for obfuscation's sake, though, how
> do you explain that?  How does the user benefit?  If
> the only answer is that a few vendors will otherwise take
> their ball and go home then that's blackmail and bad
> software standards engineering.
> 

I would say that if a targeted font compression is part of the solution, then I agree with you that an obfuscation for obfuscation's sake would be redundant. As far as your second alleged answer is concerned, I don't think there is a reason to even suspect this kind of behavior - so far font vendors and Monotype in particular have been cooperative participant and valuable contributor. Would you agree?

> The wrapper proposal (there's a third proposal offered for
> the table, even if I can't get close enough to put it
> on the table) provides useful-to-users functionality.  It's
> rationale is principled - it creates a very flexible side-band
> channel, potentially for all media types.  It so happens that
> a wrapped file is "obscured" in the sense that it can't be
> dragged and dropped into legacy applications but it doesn't
> obscure for the sake of obscuring - it adds the wrapper to perform
> a useful function.
> 

And I agree with you here - I do believe that additional metadata in your wrapper proposal would be a valuable thing.

Regards,
Vladimir

> It could be that I have too high an opinion of W3C and
> this kind of compromise ultimately goes through but I
> begin to wonder if maybe TAG shouldn't weigh in on the
> question.
> 
> -t
> 
> 
> 
>

Received on Tuesday, 23 June 2009 21:51:27 UTC