W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: [OpenFontLibrary] Fwd: www-font: WebOTF Proposal

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Fri, 7 Aug 2009 18:39:18 +0100
Cc: www-font <www-font@w3.org>, Nicolas Spalinger <nicolas_spalinger@sil.org>
Message-Id: <826B803F-A019-4177-85C1-819F112892FA@jfkew.plus.com>
To: Dave Crossland <dave@lab6.com>
On 7 Aug 2009, at 12:29, Dave Crossland wrote:

> Feel free to mail the OP directly, I'm just forwarding this so that
> www-font people see the responses from the libre community which may
> be of interest)
>
> ---------- Forwarded message ----------
> From: Nicolas Spalinger <nicolas_spalinger@sil.org>
> Date: 2009/8/7
> Subject: Re: [OpenFontLibrary] Fwd: www-font: WebOTF Proposal
> To: Open Font Library <openfontlibrary@lists.freedesktop.org>
>
>
> Ben Weiner wrote:
>> Hi there,
>>
>> With Nicolas Spalinger's comments about font metadata (13:00 BST  
>> today)
>> fresh in my mind, I want to ask what the open font community thinks
>> about this proposal. As I understand it, this proposal is intended to
>> *replace* OTF/TTF font linking. Unlike another proposal, it does not
>> allow any kind of backward compatibility with any version of 'EOT',
>> Microsoft's system for font linking in Internet Explorer from  
>> version 4
>> upwards.
>
> At a quick glance this seems like a very nice proposal with a lot more
> consensus from the various stakeholders. Thanks to the authors for  
> their
> efforts. A rather good sign that the debate is maturing, IMHO.  
> (Probably
> not intended as a replacement to direct TTF/OTF usage in UAs already
> implementing that, though).

Right, there is no expectation that UAs implementing direct TTF/OTF  
will remove that support, or that UAs implementing EOT will remove  
that. The hope, though, is that this can become a simple, efficient,  
interoperable format, and so people may wish to adopt it in preference  
to the alternatives once it becomes widely supported.

>
> My concern would be that some key extended metadata fields which are
> encouraged to be treated by the UA as the primary source of  
> information
> about the font remain optional:
> - MAY have license text and/or URL to licensing info.
> - MAY have copyright text.
> - MAY have trademark text.
> These should really be switched to "MUST". I don't see why you would
> want to distribute a font where this information is not present.

Perhaps not, but I don't think it is our place to tell people what  
they MUST include. These exist anyway in the OpenType name table. If  
they're missing, then you may not know who owns the font or what  
rights you have, it's true. But this has no bearing on whether you can  
repackage the font into WebOTF format; this can be a purely mechanical  
process. (From a technical point of view, that is. Whether you're  
allowed to do so is a separate matter, and no concern of the format  
specification.)

> If
> fallback on the TTF/OTF name table entries is then used, why not make
> sure to populate the extended metadata fields in the first place?

There is no benefit to simply copying data from the name table into  
the extended metadata. Some vendors may choose to duplicate it there  
for their own convenience, but if it is a simple duplication then it  
is just adding bytes, not value. The reason for having the metadata  
block is so that those who wish to attach *additional* metadata can do  
so (more easily), but we do not wish to *require* this from people who  
are content with what they already have.

>
> Whatever licensing model you choose, then declare it clearly!
> The days of simply saying "please review the license agreement you
> received with this font software" of similar vague blanket statement  
> are
> over. I think users and designers who remix want to know.

Sure. But you have to take that up with the font designers/vendors/ 
etc. The WebOTF format can't be responsible for ensuring that  
licensing terms are clear, it just allows them to be expressed however  
clearly (or vaguely) the creator wishes.

>
> Some of the extra metadata fields could map nicely with what we  
> already
> have in the FONTLOGs. Presumably the font design toolkit will include
> utilities to compare/sync between fields in ttf NAME table/extended
> metadata/FONTLOG.

You could even put your whole fontlog into a custom element of the  
metadata, if you wish, depending how important it is to you that it be  
delivered along with the font to anyone who actually downloads and  
looks at it. We are not proposing a strict DTD that limits what you  
can include, only that the metadata should be valid XML, and the  
meaning of certain elements and attributes should be agreed so that  
UAs can be encouraged to make use of them.

>
> Putting all the fine technical details aside: an approach were clear
> metadata is easily filled in by authors and nicely exposed in the DOM
> and somewhere non-intrusive in the UI of the browsers is the way
> forward. Everybody benefits.

Yes, that's what we hope to achieve.

JK
Received on Friday, 7 August 2009 17:40:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT