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

RE: WOFF and extended metadata

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Thu, 27 May 2010 11:02:52 -0400
To: Sylvain Galineau <sylvaing@microsoft.com>, Tal Leming <tal@typesupply.com>
CC: Jonathan Kew <jfkthame@googlemail.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: <7534F85A589E654EB1E44E5CFDC19E3D03F1F11BEC@wob-email-01.agfamonotype.org>
I would like to make few points:

1) I think it is 100% certain that at one time or another someone will have a need to extend the existing metadata with additional information that is not covered by the schema defined in the spec. Arbitrary XML extensions could be used for this purpose but there would be no guarantee that this extended data is ever visible. Because of this, we may find ourselves in a position where a spec needs to be revised to accommodate the metadata XML extensions. Thus, providing an easy to use extensible structure that can accommodate arbitrary information *and* would insure that this additional information is displayed to an end user reliably is a huge benefit.

2) We seem to agree that changes in metadata structure may simplify future UI implementation to display the metadata content, and that now is the only time making such changes would be feasible. I particularly like the approach Sylvain proposed because it achieves both the compatibility with existing XML metadata structure and provides an easy to use extension mechanism. 

3) I also like the fact that this proposed extension mechanism can accommodate any number of "odd" metadata items that may be useful for one particular locale or country but not the other - something that we would never be able to predict with any certainty, and something that may never be *universally useful* for "official" future spec XML extension.

4) The use of arbitrary XML extensions remains a possibility for font vendors, with the clear understanding that existing UI solutions will not be able to display this arbitrary info. Thus, there will always be a choice of tools to use (extensible key/value pair mechanism and/or arbitrary XML extension) to differentiate public extended information vs. proprietary (in a sense that it is cannot be guaranteed to ever be visible).

I really like Sylvain's proposal and would support changing the existing extended metadata block description to accommodate it.

Thank you and regards,
Vlad


On Wednesday, May 26, 2010 6:19 PM Sylvain Galineau wrote:
> 
> 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.
> 

Received on Thursday, 27 May 2010 15:10:58 UTC

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