[OpenType] MS Proposal for a new Name Table ID

[Michelle Perham]

John,
Thanks for your feedback. We're open to putting this data in another place. Dwayne is has a project that needs to be completed by tomorrow. Once he's done he'll put some more thought into this and address the concerns raised by you, Sairus and Ken. This might be something we need to save for the next round of changes so that we have more time to think things through.

Michelle 

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of John H. Jenkins
Sent: Thursday, January 3, 2013 1:56 PM
To: "multiple recipients of OpenType"@mail.indx.co.uk
Subject: Re: [OpenType] MS Proposal for a new Name Table ID

Message from OpenType list:


I object very strongly to this one. This is *extremely* useful data and I agree that there should be a mechanism for it to be made available, but the 'name' table isn't the place to do that.  The purpose of the 'name' table is to provide a mechanism the localizable display of information about the font to the user, not to store metadata.  That is, the 'name' table is about strings the end-user sees. 

If we really want to have a means of storing metadata which is better than the 'OS/2' table, I think it would be a good idea to create a 'META' table.  Just off the top of my head, I'd suggest something like:

UInt32	version // An int, not a fixed or anything like that, because they're always a pain
UInt32  flags   // Because you often end up wanting flags after the fact
UInt32  numTags

Then follows an array of tag data:

UInt32 (or FourCharCode) tagType
UInt32 dataOffset
UInt32 dataLength

And then finally comes the data itself.

This is a simple, extensible method of making it possible to add whatever metadata needs to be added at any point in the future.  

Just start off with a 'lang' metadata tag. Since we're dealing with IETF identifiers, we can use UTF-8 instead of UTF-16*. Since the identifiers are variable length, a comma-separated list makes sense.  

So we could have something like:

0000 0001 0000 0000 0000 0001 6C61 6E67 0000 0018 0000 000A 6379 2C65 6E2D 4473 7274

to record the supported languages for a rather unusual font.  

On 2013年1月3日, at 上午10:33, Michelle Perham <mihill at microsoft.com> wrote:

> Microsoft has several small changes we'd like to propose. I'll be sending them out over the next 2 days. The first proposal is for an addition to the 'name' table. The proposal comes from Dwayne Robinson, who I've cc'd on this email. Please include him on your responses.
> 
> Justification: OpenType fonts need a way to identify their intended language usage so that scenarios like text editing can choose appropriate fonts which switching language/IME. The inadequate legacy codepage bits have been long exhausted, so I propose adding name table id 23 containing an IETF language tag (http://www.microsoft.com/typography/otspec/name.htm).
> 
> The following description would be added to the documentation table.
> "Intended Language. This is the language the font was really designed for, which is not necessarily the same as character coverage. This allows distinction, for example, amongst Asian fonts as being Traditional Chinese vs Simplified Chinese vs Japanese, even though the fonts may have cmap coverage for a subset of each. All language identifiers follow the IETF format with an optional language and country and mandatory script subtag. These strings are encoded in UTF-16BE using platform ID 0, encoding ID 3, and the respective language id. Examples include "*-Jpan", "zh-Hans", "zh-Hant". If the font genuinely targets and fully supports more than one language, it will include more than one name table entry separated by commas."
> 




List archive: http://www.indx.co.uk/biglistarchive/

subscribe: opentype-migration-sub at indx.co.uk
unsubscribe: opentype-migration-unsub at indx.co.uk
messages: opentype-migration-list at indx.co.uk