[OpenType] RE: [mpeg-OTspec] Re: Languages tags (Buruchaski & North Slavey)

[Martin Hosken]

Dear John

> On 24/05/16 11:56, Peter Constable wrote:
> 
> > 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:
> >
> > Lang system tag: SLA
> > Description: Slavey
> > ISO 639-3 mappings: scs, xsl
> >
> > Lang system tag: SSL
> > Description: South Slavey
> > ISO 639-3 mappings: xsl
> >
> > That suggests a gap that could be filled, as John suggests:
> >
> > Lang system tag: SCS
> > Description: North Slavey
> > ISO 639-3 mappings: scs
> >
> > 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.  
> 
> I think it is worthwhile to think about this as a more generalised case, 
> rather than thinking about the Slavey languages per se. As Peter notes, 
> OTL language system tags were badly under-documented; now they are less 
> badly under-documented, but they're not even close to well-documented. 
> As with other aspects of OTL, there is no standard implementation 
> specification, or even recommendation of best practices.
> 
> Something like the structure Peter outlines, above, for Slavey 
> languages, looks to me useful in a number of other situations, if it 
> were spec'd what client software is supposed to do.
> 
> My take on this is that it would be useful to be able to specify 
> language *group* systems (by which I mean typographic conventions 
> associated with multiple languages, locales, etc.). So I wouldn't expect 
> SLA to have distinct behaviour from SSL or SCS, but rather would provide 
> a single tag for a single behaviour appropriate to both North and South 
> Slavey. If a font maker wanted some distinct behaviour in SSL vs SCS, he 
> or she would use those two tags, but otherwise would only need to use SLA.
> 
> In order for this to work, there needs to be a defined behaviour for 
> software when mapping from ISO 639 language-tagged content to default 
> OTL ls tags, such that the software would look first for a one-to-one 
> mapping, e.g. scs to SCS for North Slavey, and then for a mapping as 
> part of a set, e.g. scs,xsl to SLA for Slavey, and then fall back to dflt.

So you are asking for a new mechanism within OTL that does a fallback system when mapping from language tag to OTL tag? That would be quite a bit of extra data and complexity for not much gain. It's just as easy to have SCS lang id to point to the same language structure as SAS which would give an equivalent fallback without having to create any new mechanism. Then we can keep the one to one mapping from language tag (note the emphasis on tag there) to OTL tag. Thus for MAL and MLR, I would see MAL <> ml; MLR <> ml-reformed (I know there is no registered reformed variant for ml, but there should be). I.e. we can have a clear mapping 1:1 between OTL tags but it will be to more than just a language component of a language tag, it'll be to a full tag.

> Am I foolish to assume there is never a situation where a single ISO 
> code would map, one-to-one to multiple OTL tags? Any other way this 
> could be blown up?

If there were such a situation, how would the system know what to do? (And how can you map 1:1 to multiple things? surely that's 1:n, by definition?) I think the current approach of 1:1 for language tags to OTL tags is a good approach and fonts can implement fallback for very little cost (6 bytes per entry).

On those grounds, I don't see any value to having SLA be a 'macro' type language.

Yours,
Martin