RE: New work on fonts at W3C

On Tuesday, June 23, 2009 6:18 PM Thomas Lord wrote:
> 
> Hello.
> 
> Thanks for your reply.
> 
> Rather than a point for point reply, maybe I can suggest
> the following as potential points of agreement:
> 
> 
> 1. A format with compression is a good thing,
>    assuming that the compression technique is
>    free and clear for people to implement, use,
>    sell, and so forth.
> 

Yes, this is a good thing.

> 2. A format with compression is best expressed
>    orthogonally to a W3C standard because compression
>    is of more general utility than just "on the web".
>    Ideally, a format with compression would be
>    "included by reference" in a W3C web font Recommendation.
> 

Just for clarification purposes - compression included by reference to what? The font compression technology is currently specified only as a part of the original EOT submission - I am not sure if you can reference this. Also, Monotype Imaging licensing commitment for unrestricted GPL-compatible patent license is contingent on the adoption of the technology as part of the W3C Recommendation, so in case with fonts - I guess we can define a wrapper containing two data blocks - for metadata and for payload, and then define the payload format for fonts in details. 
Plus, as we discussed earlier on this list, we can improve the future web font solution, e.g. by extending the compression to support both TTF and CFF outlines, and by supporting font streaming, if necessary.

> 3. A wrapper format usable with any font format,
>    indeed with any media file format, that allows
>    the bundling of a media file with human-friendly
>    meta-data in HTML is desirable - has many potential
>    benefits.
> 

Yes, I agree. It will make it much easier for example to define "About ..." information block in the wrapper metadata (which a browser can display), rather than try to dig it out from inside an payload (e.g. a font) that is encapsulated in that wrapper.

> 4. It is practical to define and implement such a
>    wrapper format first in the context of fonts and
>    to leave its application to other media types for
>    a later day.  The font WG can lead by example and by
>    solving its problems with a tool both simpler than
>    alternatives and potentially more general than alternatives.
> 

Yes, I think that the metadata format can be made easily reusable for different types of encapsulated content.

> 5. The combination of
>     ~ a wrapper suitable for conveying
>       human-friendly meta-data
>     ~ a recommendation that UAs SHOULD make that
>       meta-data accessible to users
>     satisfies the "low walled garden" aspirations
>     of the vendors.   Should one of the standard formats
>     that can be so wrapped additionally support
>     compression, that is icing on the cake.
> 
> Regards,
> -t
> 
> 
> 
> >
> > 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 23:01:13 UTC