- From: Dave Crossland <dave@lab6.com>
- Date: Wed, 5 May 2010 11:03:36 +0100
- To: Ben Weiner <ben@readingtype.org.uk>
- Cc: www-font@w3.org, Sylvain Galineau <sylvaing@microsoft.com>
On 5 May 2010 08:30, Ben Weiner <ben@readingtype.org.uk> wrote: > On 5 May 2010, at 05:40, Sylvain Galineau wrote: > >>> Why are fonts different than any other resource on the web? Meaning, >>> why do we need an update mechanism different from the regular update >>> mechanisms (cache headers, etc.)? >> >> I don't think Dave means update on the browser side but updating on the >> designer side i.e. what metadata could one embed in the file to help >> design tools check for font updates. Yes, I was thinking about the users of the fonts (web authors) rather than browsers. What I mean is, a developer of a HTML editor or font management tool could implement a feature so that when a CSS it loads contains an @font-face line, it reads the font, checks the URL in the font, and finds some data telling it that a new version of the font has been published. The editor can then notify the user of this. Developers could hack up something like this now, using the <vendor /> URL and the <uniqueid /> string, and also <majorVersion /><minorVersion /> metadata. Say your a large foundry who publishes both WOFF fonts and a font manager, Font Exploder X, and the <vendor> URLs point to typeface family specific pages. In the page as a non-W3C-standardised microformat, containing <uniqueid /> <majorVersion /><minorVersion />. Since the <uniqueid /> has changed, and the version numbers in the webpage are greater than those in the font, the desktop application notifies the user that there's a new version of the font, and shows the version number of the font they have, and the font they might want. There's also a microformatted <updateDescription> there too, which is displayed when the user clicks the "More info" button, and it contains sales copy and pricing information about the upgrade. > Like maybe in a notional online vector graphics app (I've not seen in-browser DTP yet) :-) This isn't hard to imaging given stuff like http://svg-edit.googlecode.com/svn-history/r1538/trunk/editor/svg-editor.html http://docs.google.com/drawings/ http://cappuccino.org/learn/demos/ > you save a file you made with version X of a woff and then > you return to open it later and the woff on the server is now > version Y. Worth being able to find out that it's different, and > also whether the newer version is better for your file (improved > kerning, perhaps). Otherwise you'll want to keep using version > X in this file in case there are any critical line-breaks that > could get messed up. Yes, I was thinking about this last night: The most important difference between two fonts is if their metrics+kerning have any differences. An upgrade to a font that shifts around a few points to improve the look, but keeps the metrics identical, is a nice tidy upgrade. A font that is completely respaced without any of the points moving is essentially a new font, because all textboxes need to be checked for the effects of reflowing. For a libre font which is available in full when published, tools can just download both WOFF fonts and diff them and extract whatever implicit metadata they like (fontaine.sf.net...) but the non-free font publishers have a tricky problem on their hands, pushing updates in a sensible way (and with paywalls, like in my above example.) Cheers Dave
Received on Wednesday, 5 May 2010 10:04:32 UTC