- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 2 Jun 2010 14:56:28 +0000
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "Tal Leming" <tal@typesupply.com>
- CC: "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Some feedback on latest format updates: 1. Localization and fallback: we must define rules to handle the case where the user prefers German content but no content for her language is available in the block. 2. Localization and rendering: how does the user pick his preferred language and whether they can override it for font metadata is something we should talk about. It follows from #1 that users may not always get the language they want, even from the fallback rules, and may want to switch to other available languages. Even if it's to say the browser should handle this the same way it does for web pages, it should be mentioned. 3. Localization attribute: the current design sets a lang attribute on leaf nodes and stores all localized data in one document instance . As it seems that most items in the document can be localized, an alternative would be to tag the root element for language and allow the metadata block to contain multiple documents. The fallback rules would apply at document level. It'd allow translating attributes that currently aren't such as roles, too. (If that matters; I'm unclear on the actual requirements or use-cases here i.e. what should be localizable and what shouldn't) It would be consistent with the way localization is handled in many other applications including the web itself: when you get a page in Russian it may have the same markup as its en-us version but all the content is in Russian i.e. it doesn't appear that way because the browser hides those leaf nodes tagged for German, French etc. The downside being that any metadata that does not need translation - esp. in the extension area as well as any private XML people embed - would have to be repeated as well. But since we do not know what will be done or why in this respect, it remains a possibility. I personally don't mind adding simple constraints that will keep extensions simple and relevant to all users :) (And yes, I know some fonts already use this schema but it's not yet standardized and no one renders it that I know of) 4. Text element: it is unclear why a text element is needed, especially in the extension area where it adds an extra level of depth for little apparent reason beyond copying what's done in the main document. Allowing multiple instances of the same element as long as they're in different languages should be sufficient. And if the whole document was in one language then these nodes could be entirely eliminated from the structure.
Received on Wednesday, 2 June 2010 14:57:06 UTC