FW: [OpenType] MS Proposal for a new Name Table ID

[Levantovsky, Vladimir]

FYI

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of Peter Constable 
Sent: Tuesday, January 08, 2013 4:44 AM
To: "multiple recipients of OpenType"@mail.indx.co.uk
Subject: RE: [OpenType] MS Proposal for a new Name Table ID

Message from OpenType list:


This is a fair comment I suppose, though I will note that (i) this would provide a way to add the new information with minimal engineering work required to update existing implementations; and (ii) measured against current-day needs, the name table is really not well designed for the stated need:

- There's no need for platform distinctions (any platform-specific strings would always get a distinct name ID).
- There's no need for encoding distinctions (everything should just be UTF-16BE).
- Platform-specific language IDs are a decidedly unfortunate design.
- Fonts should have locale-independent descriptors for identification that implementations should always use to identify a font in non-UI contexts -- the localized strings should _only_ be for presentation in UI.
- The model for localization, given the usage scenarios, is inherently broken: a font developer decides what localizations to include, but then the strings get displayed (one must assume) in software controlled by a different developer with different localization priorities -- and it is the display language of the software that should determine what localization of the strings should be used, not anything to do with the font.

If name ID 3 was intended to be a locale-independent ID -- essentially what I referred to in the 4th point above -- then that would constitute a precedent for deviating from your assumption that only localizable UI strings go into the name table. There are other name IDs that might never be localized -- specifically, the vendor name and URL (though in principle I guess either of these could be localized).



Peter

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of John H. Jenkins
Sent: Thursday, January 03, 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







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