Re: Fonts WG Charter feedback

On Wed, Jul 1, 2009 at 1:35 PM, Håkon Wium Lie<howcome@opera.com> wrote:
> Also sprach Sylvain Galineau:
>
>  > > - the new font encoding is just that: a thin
>  > >   wrapper/obfuscation/compression layer on top of the current TT/OT
>  > >   format; there should be no new data for browsers to deal with
>
>  > So you're comfortable with Ascender's proposal(s) ?
>
> Given commitment from MS to do TT/OT, I can live with this proposal:
>
>  http://blog.fontembedding.com/post/2009/06/10/New-Web-Fonts-Proposal.aspx
>
> This is the trickiest part:
>
>  License information: The 'License Description' field in a
>  TrueType/OpenType font can be used to describe how the font can be
>  used. Font Vendors could also add information about the specific
>  licensee if desired. The 'PERM' table proposed by David Berlow could
>  also be added to fonts to specifically address the license
>  permissions which the font vendor grants to its customers. Ascender
>  supports either option. The effect of either option is to allow
>  users and font vendors to better control how the font files are
>  deployed, and importantly, will help communicate the need to obtain
>  a license for a commercial font for web use. Enforcement would be
>  the responsibility of the font vendor and not the browser or
>  authoring tool, although font vendors would greatly appreciate any
>  support offered by browsers in communicating the need to obtain
>  licenses.
>
> Assuming that the last sentence comes out loud and clear, I think it
> will be ok. That is, there will be no new data for browsers to deal
> with.

I'm also fine with this sort of proposal (in addition to raw TTF/OTF
support), though I'd prefer compression be mixed into the proposal as
well.  The proposal already includes subsetting support for
bandwidth-conservation reasons, and good compression has been shown to
have a significant effect on several fonts.  We've already gotten some
interesting looks at the efficacy of different compression techniques,
and it shouldn't be difficult to assemble a representative sample of
fonts and do some direct testing among the different proposals (which
Vladimir listed).

Silvain Galineau said:
> However the compression is done, I would not expect it to be controversial as long as it's optional.

I don't see any good reason to make compression optional in a new
webfont format.  Using existing uncompressed TTF/OTF has benefits (no
effort at all, and already works in most major UAs), but if we're
going to the effort of defining a new standard webfont format as well,
we might as well make it truly worth it.  It's been shown that
standard gzip is significantly less efficient than certain other
methods, so it would be worthwhile in my opinion to standardize on one
of these and make it part of the proposal.

However, I just saw your most recent email, and agree that including
compression would be more difficult than not doing so, but I still
strongly feel that the benefits are worthwhile here.  Punting to HTTP
isn't really saving any effort, the way mod_deflate does for us Apache
users, because you're already having to convert your TTF/OTF fonts
into the new format (or are receiving the font in webfont format
directly from the foundry).  Making the actual compression happen on
the HTTP level just means an additional step of server setup (though
this can easily become trivial/default) and consumes extra resources
on the server side that are unnecessary.  Doing all the necessary
conversions once is a bit simpler for the developer.

If your fear is that we prematurely settle on one compression format
and then later discover a more efficient one, note that compression
adoption *still* requires browser interop before it can actually be
deployed.  It would be equivalent to the effort necessary to just
spawn off a new version of the webfont format with the new compression
algorithm specified.

~TJ

~TJ

Received on Wednesday, 1 July 2009 20:57:12 UTC