Re: WOFF and extended metadata

On 10-06-08 20:18, Levantovsky, Vladimir wrote:
> On Tuesday, June 08, 2010 10:17 AM Erik van Blokland wrote:
>   
>> 4. This group looked at alternative structures of basic key / value
>> pairs, following the same localization system the other undisputed
>> elements have. There seem to be two competing ideas:
>>  a. allow localized elements for keys and values. Pro: if you're
>> translating only a couple of items, you don't have to duplicate the
>> whole structure. This follows the way the rest of the data can be
>> localized. Con: UA needs to iterate through everything and apply some
>> logic.
>>  b. move localization to the top level of the extension block.
>> Pro:
>> requires no logic in finding the right values for a given language, or
>> matching key / value pairs. Con: localised data has to be complete,
>> potentially duplicating parts of the data.
>>     

I believe the top-level localization split is much more sensible. The
way localization is done in the "name" table is utterly confusing, but
it somewhat understandable -- in the "name" table, certain entries have
technical significance (such as the PostScript font name), rather than
just being intended for human eyes.

With the metadata, the localized items seem to me to be more like UI
strings in applications -- and in app development, localized UI strings
typically stored in separate branches, one per language. This seems much
more logical to me, and certainly easier to handle and to implement.
Interestingly, that concept is more similar to the concept of
languagesystems used in OpenType Layout tables -- rather than being
additive, the OTL tables have mutually exclusive languagesystems, and
that is something that I'd prefer to see in the WOFF metadata.

A.

Received on Tuesday, 8 June 2010 18:28:29 UTC