RE: WOFF and extended metadata

> -----Original Message-----
> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-


> You've stated you don't like the idea of updating the UA / UI for every
> new field in the meta data, nor do you want to render data of unknown
> structure and contents. That implies that the extension structure has
> to be reasonably well structured, reasonably future proof, and
> reasonably adaptable. That should get us through the next 20 years.

That seems entirely inarguable. As long as one assumes that 'reasonably'
is clearly defined. 

> Addressing your pt. 1: While I can't guarantee that all these fields
> will be used to their full potential, deciding to explicitly _not_
> allow localization has the hallmark of decisions like "surely they
> wouldn't need more than 256 fonts / colors / characters / K". 

That is not at all the issue. The current design requires that I
language-match names and values independently before rendering them.
This is not about 'allowing localization'. It's a very specific 
capability for which there should be use-case: an existing relevant
file or document format that does this, or known localization issues 
with OpenType that this would solve. "Well, if we can do it that 
way, why not ?" isn't a useful answer.

Localization can be addressed in many ways. It doesn't follow that
they're all equal. I'm not interested in choosing the most costly
trade-off under the highly dubious assumption that 'the more features, 
the more future proof'. 

> Assuming all future users of these future fields are folks with 
> excellent command of the English language seems bit of stretch. 

I did not make that assumption. You, on the other hand, are assuming
that file metadata needs as much localization as data itself. It'd be
nicer if you could provide evidence of file formats where either:
1) the metadata includes translated names for each metadata property
2) #1 as well as the ability to lang-match names and values separately
are supported
3) their users are currently harmed by the lack of #1 and/or #2. 

It would be even better if we had examples of #3 as they relate to
OpenType and other type formats as they would help us assess whether
this specification addresses these known issues, as opposed to general
assumptions that this proposal does fix them because it does 'localization' 
and 'that's a good thing'. 

That I do not know why that's the case may 
well be a reflection of my own ignorance. If so, please enlighten me.


> Folks using minority languages and niche scripts have expressed great 
> interest in webfonts. I think it's reasonable to assume they're going 
> to make fonts and use WOFF to ship them.

I hope so!

> 
> Regarding pt. 2.  Not being able to match a name / value pair is not
> the end of the world. I guess the only damage would be an awkwardly
> looking paragraph if either name or value is missing. I don't think
> there would be any problem with transforming the appropriate <name>
> field to something in bold, and the appropriate <value> field to the
> regular font used in the rest of the text, and add a newline / return /
> <br/> at the end. One item has one name and one value. Draw what you
> have. With my limited experience in computer science I can make this
> work in Python in less than a screenful. 

The number of people who can write a proof-of-concept script that does 
the simplest possible rendering of anything is neither relevant nor the 
concern. 

Assuming folks who speak minority languages are OK with wading through 8 
languages worth of the same data to find something they can consume is not 
what I think of as 'localization'. Neither is showing a property name in their 
language next to a mismatched value they can't actually make sense of. I 
do not consider either behavior a desirable feature. Thus I consider proposals
that implicitly or explicitly allow such implementations without a good reason 
weaker than alternatives that strive to avoid them.

I am also not interested in writing code to handle use-cases no one wants in
practice. I don't think that's unreasonable.

> It is not rocket science.

Actually, removing unnecessary features to keep what is essential and nothing 
more is a bit of an art. Causes much controversy, usually because everyone
is certain they're the 'reasonable' one :)

> 
> Regarding pt. 3. It would have to be a helluva lot of text to not fit
> in a reasonably-width text dialog. We could add "scrollbar" to the
> conformance criteria, but I hope it would just be common sense and we
> can leave it out. I'm hoping this is not what you mean.

What kind of presentation is used is up to the UA and out of scope here.

But who's assuming that 'surely they shouldn't need more than 256 colors' 
now ? 

'Reasonably' is, again, conveniently ill-defined here. What's 'reasonable'
on a netbook ? What's 'reasonable' on a slate device ? What's reasonable in
a locale where text is rendered vertically ? What's a reasonable amount of 
metadata for a large company like Adobe vs. a small font shop in Japan ? 
And what's a reasonable use of this feature 10 years from now ? I don't know.

We have to guess. But I'd rather articulate these guesses in very specific 
terms using concrete scenarios e.g. real fonts from real vendors and how 
we'd describe them with this format. I do not think it is unreasonable for
us to apply this format to actual fonts, come up with examples of extensions,
see how this solution fixes known deficiencies with OpenType metadata etc.

We do not need implementations to use this schema. We do not need implementations
to get a feel for what works and what doesn't. For what is essential and what
isn't. For what has known use-cases. And what doesn't. For what must stay. And 
what can be cut.

If this work has already been done, I'd love to see samples of it. Thanks.

Received on Monday, 7 June 2010 03:14:29 UTC