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

RE: fsType and embedding information

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Wed, 19 May 2010 09:43:35 -0400
To: John Hudson <tiro@tiro.com>, Christopher Slye <cslye@adobe.com>
CC: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D0209C2D9EA@wob-email-01.agfamonotype.org>
On Tuesday, May 18, 2010 9:38 PM John Hudson wrote:
> This explanation seems to me very necessary:
> 	None of the existing embedding bits constitute or
> 	imply permission to create or serve a WOFF file.
> 	Web authors should confirm that a font is licensed
> 	for such use.
> And the reason that this explanation is necessary is that the only
> other
> dedicated web font format to which we can point, EOT, explicitly did
> associate embedding bits with creating and serving web fonts, thereby
> creating a perception that the embedding bits constituted or implied
> such permission.

We need to be very clear about WOFF processing pipeline and where the embedding permissions may play a role. The permissions are only defined in an original font, what you propose here would only be relevant for the conversion step from an original SFNT-based format into WOFF. 

As Tom P. already mentioned, there is a chance that in the future OpenType / OFF spec may add new tables (e.g. EEULA), bitfields or definitions of the remaining reserved embedding bits. There have been discussions in the past that they may be used for other types of embedding such as in applications, and it is certainly feasible that these bits could be used in the future to define permissions to use fonts in Flash, on the web, etc. 

I am not against providing an explanation that John proposed, but we need to be very explicit in defining the meaning of the "existing embedding bits".

> As I said earlier, I figured the browser makers would appreciate having
> the additional clarification that they're doing the right thing by
> ignoring embedding bits when downloading and unpacking WOFF files. 

Unlike EOT (that has embedding permissions present in the EOT header) WOFF doesn't have any. The conversion of an original font into WOFF format happens prior to WOFF file being introduced as a resource, and there are no embedding permissions in WOFF for user agents to even look at. Once WOFF file is downloaded and unpacked, we are outside the scope of the WOFF spec, and User Agents now deal with original fonts. It seems best to be silent about it and just leave it up to UA as Håkon suggested.

Received on Wednesday, 19 May 2010 13:44:31 UTC

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