Re: WOFF and extended metadata

On 3 jun 2010, at 19:05, Sylvain Galineau wrote:

> As this is the *optional 
> extension area* of a file *metadata* block, I am in fact uncomfortable doing anything more than that 
> until such time a font vendor comes up with an actual metadata block they want to store in their 
> products that 1) needs localized metadata extensions 2) requires the ability to language-match names 
> and values independently to produce name-value pairs and 3) uses so many languages and/or data that 
> showing all the data to the user is an issue.

Sylvain, I thought the goal of the extension area was to allow for future applications and data to be added in a way that UA and UI would be able to display without having to update. As such having a designated place and structure for this kind of extension data is a good idea.

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.

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". Assuming all future users of these future fields are folks with excellent command of the English language seems bit of stretch. 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.

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. I can probably build an example as an XSL transform as well if that's helpful. I'll be the first to admit my code is crap, but that only means an experienced programmer can do it with less code and no time. It is not rocket science. 

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.

All the best,
Erik

Received on Thursday, 3 June 2010 18:46:12 UTC