[OpenType] Language system tag for Chinantec languages?

Levantovsky, Vladimir vladimir.levantovsky at monotype.com
Wed Mar 29 21:41:09 CEST 2017


Great, thank you Peter!


From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Wednesday, March 29, 2017 3:40 PM
To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
Cc: opentype-list at indx.co.uk
Subject: RE: [OpenType] Language system tag for Chinantec languages?

FYI, the Language system tags page for OpenType 1.8.1 has been updated to add CCHN.

https://www.microsoft.com/typography/otspec/languagetags.htm



From: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec]
Sent: Wednesday, March 22, 2017 1:05 PM
To: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>
Subject: [mpeg-OTspec] FW: [OpenType] Language system tag for Chinantec languages?



Bringing back the discussion that ran away to a different email list - part 3.

-----Original Message-----
From: listmaster at indx.co.uk<mailto:listmaster at indx.co.uk> [mailto:listmaster at indx.co.uk] On Behalf Of Peter Constable
Sent: Wednesday, March 22, 2017 10:13 AM
To: listmaster at indx.co.uk<mailto:listmaster at indx.co.uk>
Subject: RE: [OpenType] Language system tag for Chinantec languages?

Message from OpenType list:


As you know, I've been interested for several years in the idea of the "6" prefix to sanction tags based on any ISO 639 language ID, except when that would duplicate an already-registered tag. It will take a bit of work to document, and a key question is whether it should allow use of only individual-language IDs from ISO 639-3, or also macrolanguage IDs from ISO 639-3, and collection IDs from ISO 639-5. But it is doable.

As for "A" and "C" prefixes, I don't mind informal conventions, but I'm not inclined to formalize anything in the spec at this time.

Regarding documenting the composition of a collection: I agree that's needed, and I made attempts at such information in the existing registry. But I wouldn't want to set any expectations: It is beyond the scope of the OpenType spec to document languages or language relationships.

Of course, how language systems will actually get selected in applications is beyond the scope of the OT spec.

Peter

-----Original Message-----
From: listmaster at indx.co.uk<mailto:listmaster at indx.co.uk> [mailto:listmaster at indx.co.uk] On Behalf Of Martin Hosken
Sent: Wednesday, March 22, 2017 4:51 AM
To: listmaster at indx.co.uk<mailto:listmaster at indx.co.uk>
Subject: Re: [OpenType] Language system tag for Chinantec languages?

Message from OpenType list:




> I'm open to that. I wonder, though, if we should document somewhere
> conventions for four- vs three-letter tags? So far, we've used
> four-letter tags for 'IPPH' and 'APPH', i.e. for phonetic notation
> systems that do not map to specific languages. Should we formalise
> this idea that four letter tags are for language systems that do not
> map to individual languages, but that might, as in the case of 'CCHN'
> map to multiple languages? [This does leave a number of existing
> three-letter tags that map to multiple ISO language codes, which we
> would presumably carry as legacy but could supplement with
> corresponding four-letter tags.]

I would propose that 4 letters be worked on a namespace principle. So the first letter is the namespace and the last 3 letters are the language code. So C for collections. Maybe we can revive the 6xxx for unregistered (for OT) languages from ISO639? That would save a lot of future registration work. Yes some special cases like IPPH and APPH might not fit, but hey we are big enough to come with that. Here's a starting list:

A - Alternate rendering, which would have been identified via a variant in the language tag C - Language collections. The registration should document all languages covered by the collection
6 - ISO639-3 languages otherwise unregistered.

That fits APPH well (interpreting it as a variant of IPPH). Shame that pph is not yet allocated, so we won't know whether it will cause a problem. But if pph were allocated and needed an APPH, we could register a special for that.

Yours,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20170329/7365f9e1/attachment.html>


More information about the mpeg-otspec mailing list