- 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>
> 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