W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

RE: Agenda, action items and suggested WOFF changes

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 12 May 2010 02:23:06 +0000
To: John Hudson <tiro@tiro.com>
CC: Dave Crossland <dave@lab6.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, www-font <www-font@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2148B1BC@TK5EX14MBXC120.redmond.corp.microsoft.com>
> From: John Hudson [mailto:tiro@tiro.com]
> Sent: Tuesday, May 11, 2010 5:41 PM
> To: Sylvain Galineau
> Cc: Dave Crossland; public-webfonts-wg@w3.org; www-font
> Subject: Re: Agenda, action items and suggested WOFF changes

> All the commercial font vendors with whom I've discussed this are
> working on the latter model, i.e. no conversion licenses, WOFFs
> delivered direct from the foundry. 

That's my perception also. The web license will cover the WOFF file
that comes with it in most cases.

> I'm sure there will be exceptions,

> including customer-specific licenses to permit conversion, just as
> there are special licenses that already permit customers to do things that
> the general retail EULA does not, but I'm pretty sure that the main
> licensing model for web fonts from commercial vendors will involve WOFF
> files from the vendor, most likely serialised and with customer-
> specific meda-data in both font and wrapper.

But if the vendor, in some cases, allows you to convert your TTFs, why do we 
need to decide which embedding bit(s) allow this conversion ? We're adding
an extra step for font and tool vendors for what exact benefit ? What if a
font vendor like Adobe want to allow thousands of existing customers to convert 
some of their catalog to web use but they don't have the right bits set currently?
Should their future tool prevent their customers from doing that ?

I don't mean to sound like this makes no sense. It's clear that it does to you
guys but I'm missing something. 

Received on Wednesday, 12 May 2010 02:23:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC