[OpenType] MS Proposal for a new Name Table ID
Sairus Patel
sppatel at adobe.com
Thu Jan 3 21:00:01 CET 2013
Dwayne,
> the language the font was really designed for [...] If the font genuinely targets and fully supports
The notion of "fully supporting" a language is problematic, just as the notion of codepages bits (or Unicode block bits) was problematic. Fonts can and often do support only a subset of characters in a language. What if a font supports only one, or a few characters in a language -- but those characters are central to the font's purpose, e.g. a digits-only font, or an A-Z only display font? I wouldn't want my text editor -- to use your example -- to filter out those fonts when I set my language to English.
> These strings are encoded in UTF-16BE using platform ID 0, encoding ID 3 ...
The spec for a new name ID should be independent of particular platform and encoding IDs, since name IDs can be present in any of various platform/encoding combinations. If particular implementations support only particular platform/encoding combinations, that should be recorded in the Recommendations section (e.g. "Windows version xxx supports name ID 23 strings only for platform ID 0, encoding ID 3"). I realize the 'name' spec doesn't currently do this, and there have been attempts at remedying this, but I feel least additions to the spec should be cleanly done in this regard.
Also, specifying the string's encoding as UTF-16BE belongs not to the spec for this name ID but rather to the spec for platform ID 0, encoding ID 3.
> ... and the respective language id.
The platform ID 0 spec doesn’t define any language IDs (except for 0, which does not indicate any particular language).
If "the respective language id" means the same ID as the name ID string itself, then should we be assuming that this proposed name ID will be present only in format 1 'name' tables, e.g. the name ID 23 string is "zh-Hans" under {platform 0, encoding 3, and language "zh-Hans"}?
If so, then under which language ID should a comma-separated string of language IDs be registered?
Best,
Sairus
-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of Jonathan Kew
Sent: Thursday, January 03, 2013 10:20 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:
On 3/1/13 17:33, Michelle Perham 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."
I think there's a problem with this wording: Do you really mean that it will include "more than one name table entry", or (as I suspect) that the (single) name table entry will include multiple, comma-separated IETF language tags?
JK
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
More information about the mpeg-otspec
mailing list