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: Wed, 16 Jun 2010 11:46:47 -0400
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, Sylvain Galineau <sylvaing@microsoft.com>, Tal Leming <tal@typesupply.com>
CC: Erik van Blokland <erik@letterror.com>, "www-font@w3.org" <www-font@w3.org>, 3668 FONT <public-webfonts-wg@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D03F3BF1EC9@wob-email-01.agfamonotype.org>
In order to facilitate the discussion and reach a consensus on this issue, I'd like to offer my personal opinion on different options under consideration:

1) Localizable metadata extension as proposed by Jonathan Kew [13] (with detailed description of the simple set of rules) - this is my personal favorite:

<extension lang="en"><!-- untagged subelements are English -->
    <name lang="nl">Bericht</name>
    <name lang="fr">Message</name>
    <value lang="nl">Hallo!</value>
    <value lang="fr">Salut!</value>
    <value lang="fr-CA">Bonjour!</value>
    <value lang="ja">こんにちは。</value>

2) Localizable metadata extension where only the <extension> element is tagged with lang attribute (a variation of what Sylvain has proposed [12]). Multiple extension elements would be needed to localize the content but since the repetitive elements are compressed well, this shouldn’t be a problem as far as the size of metadata is concerned:

<extension lang="en">
<extension lang="fr">
<extension lang="nl">

3) Metadata extension with no localization, only consisting of the sets of key/value pairs (with potential group attribute as originally proposed by Sylvain [4]). If needed, the key/value pairs can simply be presented and displayed in multiple different languages (may not be the best choice because the user would see duplicate entries, but simple to implement and I can live with it):


Speaking with my WG chair hat 'on' - I believe we all agreed that there are many benefits in offering an extension mechanism for metadata. We have rather strong opinions expressed by the people from the industry [1] and I would like us to make every possible effort to come up with a solution that both font vendors and UA implementers can be comfortable with. Please respond to this message indicating you preferred choice(s) of metadata extension mechanism.

Thank you and best regards,

> -----Original Message-----
> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
> request@w3.org] On Behalf Of Levantovsky, Vladimir
> Sent: Friday, June 11, 2010 3:55 PM
> To: Sylvain Galineau; Tal Leming
> Cc: Erik van Blokland; www-font@w3.org; 3668 FONT
> Subject: RE: WOFF and extended metadata
> Hello all,
> Thank you for your active participation and your contributions to the
> work of this WG.
> In an effort to move things forward I'd like to try to "refresh" this
> discussion and document its timeline, the issues we discussed to date,
> and the outcome of those discussions. I hope that by doing this we will
> be able to see the progress we made and focus our energy on the
> remaining issues.
> 1. Metadata use cases
> The use of metadata and the importance of its content has been
> addressed in a number of contributions that, in particular, represent
> the industry perspective and the possible need for localization and
> extensibility [1-3]. Some use cases for metadata extensions have been
> offered [4, 5]; however it would be desirable to include specific
> examples of metadata content that can be included in the WOFF
> specification. I would like to ask people to contribute these examples
> (both for metadata elements that already defined and possible scenarios
> for future extensions).
> 2. Metadata format
> I believe we have reached the consensus that
> - metadata elements defined in the spec may be rendered by UA if
> requested by the user;
> - if arbitrary (not defined by the WOFF spec) XML elements are added to
> metadata, they will be ignored;
> - the currently defined set of metadata elements is acceptable both for
> font vendors and implementations.
> In particular, Sylvain has stated that he is okay with parsing and
> rendering the currently defined schema [6], and proposed to consider
> specifying the extension mechanism that would allow font vendors to
> define additional metadata and show it to the user (which he proposed
> earlier in [4]).
> 3. Metadata extensibility
> The mechanism proposed for metadata extensions was originally based on
> a simple key/value pairs with the possibility to group them into higher
> level categories [4]. A derivative format was proposed to enable
> localization of the proposed metadata extensions [7]. However, the
> discussion of this proposal [8-11] revealed potential implementation
> issues where a rather complex set of rules would have to be developed
> to insure proper rendering of multiple localized name/value pairs.
> Alternatively, other proposals were presented to simplify rendering by
> introducing "lang" attribute at the higher element level [12,13]. So at
> that point (as summarized by Erik in [14], p.4a&b) we have two
> alternative structures. Another alternative was recently proposed by
> Laurence Penney [15].
> In conclusion, given that we already have a consensus on some core
> issues (as mentioned in p.2 of this email) I would like to ask the WG
> members to review the alternative approaches to enable metadata
> extensibility giving proper considerations to the following questions:
> - localization and extensibility are both important, but considering
> the extremes of this issue - would we rather have localizable metadata
> without extensibility or extensible metadata with no localization?
> - among the alternative options we currently have under consideration -
> which one is the most likely to satisfy the needs of font vendors and
> address concerns of the implementers?
> - how can we simplify the structure of the metadata extensions to make
> it easier for browsers to render and display its content? (therefore
> making it much more likely for users to be able to see metadata, which
> is the goal)
> I also would like to ask group members to contribute your ideas and use
> cases for metadata extensions, and examples of metadata content that
> can be incorporated in the WOFF spec.
> Thank you,
> Vlad
> P.S. Every possible effort was made to accurately represent the essence
> of our discussions and to reference the source where appropriate. Many
> contributions on this subject offered useful ideas and insight, however
> it was impossible to include all of them in the list of references
> below. Please consider using WG public archive
> (http://lists.w3.org/Archives/Public/public-webfonts-wg/) as a primary
> reference.
> [1] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0235.html
> [2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0234.html
> [3] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0050.html
> [4] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0201.html
> [5] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0223.html
> [6] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0209.html
> [7] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0004.html
> [8] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0010.html
> [9] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0013.html
> [10] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0017.html
> [11] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0016.html
> [12] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0021.html
> [13] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0023.html
> [14] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0047.html
> [15] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0304.html
Received on Wednesday, 16 June 2010 15:47:25 UTC

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