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: Fri, 11 Jun 2010 15:54:49 -0400
To: 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: <7534F85A589E654EB1E44E5CFDC19E3D03F2191B40@wob-email-01.agfamonotype.org>
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,

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

> -----Original Message-----
> From: Sylvain Galineau [mailto:sylvaing@microsoft.com]
> Sent: Wednesday, June 09, 2010 7:26 PM
> To: Levantovsky, Vladimir; Tal Leming
> Cc: Erik van Blokland; www-font@w3.org; 3668 FONT
> Subject: RE: WOFF and extended metadata
> From: Levantovsky, Vladimir
> [mailto:Vladimir.Levantovsky@MonotypeImaging.com]
> >With the level of scrutiny that was applied to the draft spec, the
> review process conducted by the WG can hardly be characterized as
> "rubber-stamping". Sylvain, you among many other members of the WG
> provided valuable > comments, and this particular discussion is the
> direct result of it. I agree with you that mischaracterizations are
> unnecessary, including the allegations of "rubber-stamping".
> With respect, being repeatedly told that my feedback comes too late,
> that 'there is no discussion' about something because all the
> stakeholders have already approved it etc. does not convey the
> impression that feedback is really sought nor that change is truly
> desirable, if possible.
> > ...yet you seem to be asking for a proof that this format and its
> usage already exist.
> I am being *told* it does exist, and that it is a reason why we should
> not change certain things. So I don't 'seem' to be asking. I *am*
> asking based on the information given.
> At a minimum, I expect that a format designed with input from foundries
> has been at least hand-tested on a bunch of ways using real/imaginary
> products. Such samples are important to document use-cases and usage.
> We need them. The spec, imo, needs some of them as well. Good
> informative examples and use-cases are very worthwhile.
> > Speaking from my own experience: I know many things - one of them
> being that there are many more things I don't know.
> > I would speculate that this is universally true for everybody - this
> is exactly the reason why I (and many members of this WG) believe the
> extensibility is so important.
> > What we know today can be documented in the spec; it is what we don't
> know that will become use cases for metadata extensions.
> You cannot design for extensibility in a complete vacuum. You can't
> just say 'and here is the place where extensibility magically happens'.
> That's silly. While you can't predict all the things people will come
> up with, you add extensibility based on at least a few scenarios.
> Because until you have some you can't possibly design an extension
> mechanism with any degree of confidence that it will actually be useful
> for anything at all. I never asked or expected anyone here to document
> the entire universe of future needs. It doesn't mean that there is no
> value in inventing *some* based on what we know today to get us
> started.
> > We have already agreed that any "random" or "arbitrary" XML should be
> ignored, there is no reason to bring this up times and times again.
> I was told my argument was all over the place. Do you mind if I outline
> the sequence of events as it happened ? :)
> > No one, really? Don't we all dislike "mischaracterizations"? :)
> I came up with the EU/Adobe hint example. How many use-cases for the
> extension area have come up before yesterday ? Given the number of
> people qualified to come up with useful examples in this group, I do
> not believe this was a mischaracterization.
> > Fonts by their very nature are tightly coupled with languages and
> writing systems. The communities who speak *minority* languages are
> going to benefit the most from this development - this is why
> localization of metadata > is so important.
> It's an argument one could make about any kind of metadata format.
> People speak multiple languages therefore property names should be
> translatable.  Well, not quite; use-cases first please. So we
> understand how much localization support is likely to be necessary for
> the scenarios we know of, instead of assuming that everything needs its
> own separate language matching and what not.
> > The keyword here is "mutually" - yet you Sylvain sometimes seem to
> contradict everyone including yourself.
> Please be specific. Where I contradicted myself, and *why* it happened.
> When the input changes or  the process gets stuck, I may have to change
> my mind. Should I stubbornly stick to the same thing in the face of
> evidence, or lack thereof ? Would that really be better ? In the
> absence of actionable input allowing substantial progress to be made,
> what options do I have but fall back on the original status quo ? It
> doesn't mean I like it. It means I'm stuck. My apparent contradictions
> only reflect the nature of the discussion e.g. I was first told
> extensions would be defined using arbitrary XML which could be rendered
> using XSL transforms or equivalent etc. Then I'm told extensions must
> support localization according to a pattern already established in the
> specification. Which implies the XML could not be arbitrary in the
> first place.  I am bending this way and that because that is what's
> going on, Vlad. Believe me, I'm not jumping left, then right, then back
> left by choice or because it's so much bloody fun.
> > May I remind you that we are only two weeks into this development
> and, given the progress we made, it's pretty impressive what this WG
> can accomplish. Your input is valuable and very much appreciated -
> let's keep things > positive, negativity doesn't help anyone.
> No it does not. And I don't take the failure to make progress on this
> topic - the mail volume/progress ratio being pretty horrible imo - as
> anyone's but my own.
> I don't think I understand the problem any better now  than I did two
> weeks ago. That's a pretty poor return on the effort so I'm happy to
> let others have a go at it. I've frankly had enough of jumping  through
> every other hoop and being told I shouldn't jump so much. I think I've
> spent more time arguing the design of this feature  than it should take
> a summer intern to code it if it was designed with implementation in
> mind.
> Add to that that it's an optional feature and I can't justify spending
> any further time on this topic at this point. Sorry.
Received on Friday, 11 June 2010 19:56:31 UTC

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