<div dir="ltr">OK. I see now.<div><div><span style="line-height:1.5">John and Peter’s suggestion is fine.</span><br></div></div><div><br></div><div>Thanks</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 19:56 Peter Constable <<a href="mailto:petercon@microsoft.com">petercon@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree that OT language system tags and ISO 639 IDs represent different information. However, the OT language system tags were badly under-documented. The mappings were provided since, otherwise, there would be no indication whatsoever what the language system tags are intended to mean.<br>
<br>
As for actual mapping usage, I can't think of any usage scenario in which one would map from the language system tag to an ISO 639 language ID. But mapping in the other direction certainly can happen since content is often tagged for language using BCP 47 tags. Hence this mapping information could get picked up in implementations to use as a default mapping from a language tag to a language system tag — if the font uses that tag (else default).<br>
<br>
With that in mind, SLA could be left as a higher-level category, and the language tag scs could be left as a mapping. But if we really want it to be a higher-level category, then the mapping should list both scs and xsl. Then we'd be left with this:<br>
<br>
Lang system tag: SLA<br>
Description: Slavey<br>
ISO 639-3 mappings: scs, xsl<br>
<br>
Lang system tag: SSL<br>
Description: South Slavey<br>
ISO 639-3 mappings: xsl<br>
<br>
That suggests a gap that could be filled, as John suggests:<br>
<br>
Lang system tag: SCS<br>
Description: North Slavey<br>
ISO 639-3 mappings: scs<br>
<br>
That would work and wouldn't conflict with anything. I wonder if it's overkill: is anybody going to implement fonts that have different glyphs or layout behaviour for SLA versus SSL versus SCS? But I won't object if that's how people want to proceed.<br>
<br>
<br>
<br>
Peter<br>
<br>
<br>
-----Original Message-----<br>
From: John Hudson [mailto:<a href="mailto:john@tiro.ca" target="_blank">john@tiro.ca</a>]<br>
Sent: Tuesday, May 24, 2016 9:58 AM<br>
To: Denis Jacquerye <<a href="mailto:moyogo@gmail.com" target="_blank">moyogo@gmail.com</a>>; Levantovsky, Vladimir <<a href="mailto:Vladimir.Levantovsky@monotype.com" target="_blank">Vladimir.Levantovsky@monotype.com</a>>; OTspec (<a href="mailto:mpeg-OTspec@yahoogroups.com" target="_blank">mpeg-OTspec@yahoogroups.com</a>) <<a href="mailto:mpeg-OTspec@yahoogroups.com" target="_blank">mpeg-OTspec@yahoogroups.com</a>>; Peter Constable <<a href="mailto:petercon@microsoft.com" target="_blank">petercon@microsoft.com</a>><br>
Subject: Re: [OpenType] RE: [mpeg-OTspec] Re: Languages tags (Buruchaski & North Slavey)<br>
<br>
On 24/05/16 09:30, Denis Jacquerye wrote:<br>
> The OT language system tag SLA already maps to ISO 639 [scs] (the ISO<br>
> 639 code for North Slavey).<br>
> Slavey; SLA; scs<br>
<br>
Mapping of OTL language system tags to ISO 639 codes was not part of the original intent of the former, and I'm still not convinced it is a good idea, since they represent different types of data that only sometimes align. I certainly don't think it makes sense to use ISO 639 codes — which I think can only constitute an annotation to OTL language system tags — to determine the intent of the latter.<br>
<br>
That said, in this case I don't imagine there are many fonts that would be affected by redefining SLA as North Slavey.<br>
<br>
JH<br>
<br>
<br>
--<br>
<br>
John Hudson<br>
Tiro Typeworks Ltd    <a href="http://www.tiro.com" rel="noreferrer" target="_blank">www.tiro.com</a><br>
Salish Sea, BC        <a href="mailto:tiro@tiro.com" target="_blank">tiro@tiro.com</a><br>
<br>
Getting Spiekermann to not like Helvetica is like training a cat to stay out of water. But I'm impressed that people know who to ask when they want to ask someone to not like Helvetica. That's progress. -- David Berlow<br>
<br>
</blockquote></div>