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

RE: WOFF and extended metadata

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 26 May 2010 22:18:32 +0000
To: Tal Leming <tal@typesupply.com>
CC: Jonathan Kew <jfkthame@googlemail.com>, Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2149453A@TK5EX14MBXC120.redmond.corp.microsoft.com>
> From: Tal Leming [mailto:tal@typesupply.com]
 
> It seems to me that trying to coordinate the associated credit, role
> and crediturl will be a problem.

More on this. First, as to why these need to be 'coordinated'.
As in, you want to convey that these things belong together without
depending on the generator to write them one after the other, right ?
Then we could add a group attribute e.g.

	<property group="credits" name="credit" value="Font Designer" />
	<property group="credits" name="role" value="Lead" />
	<property group="credits" name="crediturl" value="http://fontdesigner.example.com" />
	<property group="credits" name="credit" value="Another Font Designer" />
	<property group="credits" name="role" value="Contributor" />
	<property group="credits" name="crediturl" value="http://anotherdesigner.example.org" />
	<property group="credits" name="credit" value="Yet Another" />
	<property group="credits" name="role" value="Hinting" />

Thus all these properties are explicitly put in the same bucket name, but without allowing
arbitrarily deep nesting. (I'd rather have some kind of a use-case to show arbitrarily deep
nesting is necessary for metadata).

Then we have the issue of existing fonts. There may not be many, there may be no UI out there
to show it yet but the format is already specified and since the main goal of this proposal is 
to make future extensions as simple and predictable as possible for browsers, font vendors and
tool makers, there really is little need to change what we already have. We could keep the existing 
format and use name-value pairs for optional metadata extensions font vendors wish to include 
in their product. We'd do this by adding an optional container element like so (see at the end):

<?xml version="1.0" encoding="UTF-8"?>
<metadata version="1.0">
    <uniqueid id="com.example.fontvendor.demofont.rev12345" />
    <vendor name="Font Vendor" url="http://fontvendor.example.com" />
    <credits>
        <credit
            name="Font Designer"
            url="http://fontdesigner.example.com"
            role="Lead" />
        <credit
            name="Another Font Designer"
            url="http://anotherdesigner.example.org"
            role="Contributor" />
        <credit
            name="Yet Another"
            role="Hinting" />
    </credits>
    <description>
        <text lang="en">
            A member of the Demo font family.
            This font is a humanist sans serif style designed
            for optimal legibility in low-resolution environments.
            It can be obtained from fontvendor.example.com.
        </text>
    </description>
    <license url="http://fontvendor.example.com/license"
             id="fontvendor-web-corporate-v2">
        <text lang="en">A license goes here.</text>
        <text lang="fr">Un permis va ici.</text>
    </license>
    <copyright>
        <text lang="en">Copyright ©2009 Font Vendor"</text>
        <text lang="ko">저작권 ©2009 Font Vendor"</text>
    </copyright>
    <trademark>
        <text lang="en">Demo Font is a trademark of Font Vendor</text>
        <text lang="fr">Demo Font est une marque déposée de Font Vendor</text>
        <text lang="de">Demo Font ist ein eingetragenes Warenzeichen der Font Vendor</text>
        <text lang="ja">Demo FontはFont Vendorの商標である</text>
    </trademark>
    <licensee name="Wonderful Websites, Inc." />

    <!-- ...and now the metadata that wasn't in the spec but makes the life of this font vendor
         easier if it's here, regulatory tidbits useful in some countries, useful metadata for a 
         certain design tool lots of people use etc -->

    <metadata-extended>
	<property group="catalog-info" name="RefID" value="AAA-6667" />
	<property group="catalog-info" name="UnicodeRange" value="standard" />
	<property group="catalog-info" name="UpdateURI" value="http://www.fontvendor.com/update/AAA-6667" />
	<property group="EU" name="CopyrightNumber" value="FR-33323-2010" />
	<property group="EU" name="CopyrightGrantDate" value="20111021" />
	<property group="AdobeDreamweaver" name="category" value="headline" />
	<property group="AdobeDreamweaver" name="recommended-min-size" value="14pt" />
    </metadata-extended>
</metadata>

Given this, we have a stable and extensible schema, making it very easy for a browser vendor, a tool maker
or an add-on developer to design a UI that will render the metadata block and all included extensions in 
a consistent and reliable manner.

Or we can let each browser vendor figure out whether and how they'll render the unknown arbitrarily deep
XML they might come across. By now it's painfully clear which approach I believe to be most likely to 
result in solid, complete, working implementations so I'll stop :)



Received on Wednesday, 26 May 2010 22:19:15 UTC

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