[OpenType] MS Proposal for a new Name Table ID

[Levantovsky, Vladimir]

Hi all,

The 3rd edition of the OFF standard (ISO/IEC 14496-22) is in the working draft stage. We don’t have to promote it to the next stage by a certain date but should rather strive for a feature-complete specification. What I am saying is that we currently *are* considering a round of changes so this is a perfect time to do it, even if it results in one more version of the working draft being produced. We can continue this discussion and anything that we don't agree on can be worked on and put in the next revision of the working draft (e.g. in April).

Thank you,
Vlad


> -----Original Message-----
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
> On Behalf Of Michelle Perham
> Sent: Thursday, January 03, 2013 5:38 PM
> To: opentype-migration-list at indx.co.uk; "multiple recipients of
> OpenType"@mail.indx.co.uk; OTspec (mpeg-OTspec at yahoogroups.com)
> Cc: Dwayne Robinson
> Subject: [mpeg-OTspec] RE: [OpenType] MS Proposal for a new Name Table
> ID
> 
> 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
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>