[css-fonts] font-language-override

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-fonts] font-language-override

Andrew Cunningham-4

Hi all,

The current editors draft indicates that font-language-override feature is at risk.

This feature can be used with firefox, but not with other browsers.

Current support means we can use the Padauk or Noto Sans Myanmar for a range of languages in Firefox that can not be supported by the same font in other browsers. For instance if I need to support some of the other Karen languages using Sgaw Karen preferences, i can not currently rely on font-language-override suppot to handle this.

This forces us to hack the fonts in question making alternative language versions of the fonts where the default rendering is changed.

Reengineering fonts in this way is beyond the ability of the average web developer and browser developers should not be placing this burden on web developers.

If font-language-override is dropped from the spec, an alternative method exposing browsers default locl processing needs to be exposed to web developers, allowing web developers to override locl processing in some fashion.

Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Behdad Esfahbod-5

What's wrong with lang / xml:lang?!

On May 30, 2016 10:26 PM, "Andrew Cunningham" <[hidden email]> wrote:

Hi all,

The current editors draft indicates that font-language-override feature is at risk.

This feature can be used with firefox, but not with other browsers.

Current support means we can use the Padauk or Noto Sans Myanmar for a range of languages in Firefox that can not be supported by the same font in other browsers. For instance if I need to support some of the other Karen languages using Sgaw Karen preferences, i can not currently rely on font-language-override suppot to handle this.

This forces us to hack the fonts in question making alternative language versions of the fonts where the default rendering is changed.

Reengineering fonts in this way is beyond the ability of the average web developer and browser developers should not be placing this burden on web developers.

If font-language-override is dropped from the spec, an alternative method exposing browsers default locl processing needs to be exposed to web developers, allowing web developers to override locl processing in some fashion.

Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Andrew Cunningham-4


On Tue, 31 May 2016 15:34 Behdad Esfahbod <[hidden email]> wrote:

What's wrong with lang / xml:lang?!


1) it assumes a one to one relationship between language tag and opentype language sytem, a relationship that does not exist,

2) it would only work if very iso-639-3 tag was added as a opentype language system tag

3) it would only work if web developers could make 1-1 and many-1 relationships to between html language tags and locl features.


An example where language tags succeed .... html marked up as "ksw"  vewed in chrome and using noto sans myanmar

Examples of where it fails: html markup  marked up as another Karen language viewed in chromeand using noto sans myanmar

Either the the font developer needs to make explicit locl features for every conceivable language the font supports, or the browser needs to be more flexible providing more control over what locl feature is needed.

Currently  chrome and internet explorer fail because they do not support font-language-override

If we are to we are going to rely on lang attribute, and use auto selection oflicl features by broswer then font developers need to rethink how they develop fonts.

It would be fairly quick and easy for google to add support for font-language-override

It would take years for google to map orthographic usage of sufficient number oflanguages to add additional locl support to noto for instance to make lang attribute usable.

For instance for html lang attribute towork for noto sans font, the noto developers need to identify every african language that uses eng, in order to create all the possible locl lookups just required to get the right eng based on language.

Alternatively google chrome developers needto do this mapping work, go through every iso-62309-3 language code to determine if locl support is theoretically required.

It is much simpler, and more extensible to add font-language-override support

Alternatively, font developers could just make smarter use of cvNN ans ssNN and avoid using locl, or du0licate locl effects via over opentype features.

Basically for lesser used and minority languages, the current system used by some browsers doesn't work.

Andrew


On May 30, 2016 10:26 PM, "Andrew Cunningham" <[hidden email]> wrote:

Hi all,

The current editors draft indicates that font-language-override feature is at risk.

This feature can be used with firefox, but not with other browsers.

Current support means we can use the Padauk or Noto Sans Myanmar for a range of languages in Firefox that can not be supported by the same font in other browsers. For instance if I need to support some of the other Karen languages using Sgaw Karen preferences, i can not currently rely on font-language-override suppot to handle this.

This forces us to hack the fonts in question making alternative language versions of the fonts where the default rendering is changed.

Reengineering fonts in this way is beyond the ability of the average web developer and browser developers should not be placing this burden on web developers.

If font-language-override is dropped from the spec, an alternative method exposing browsers default locl processing needs to be exposed to web developers, allowing web developers to override locl processing in some fashion.

Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Chris Lilley

Let me amplify and restate these points:


On 2016-05-31 06:57, Andrew Cunningham wrote:
It would be fairly quick and easy for google to add support for font-language-override

Supporting font-language override would not only increase spec compliance, it would be the path of least effort

It would take years for google to map orthographic usage of sufficient number oflanguages to add additional locl support to noto for instance to make lang attribute usable.

Depending on complex mappings from @lang to OpenType lang is a lot of work, currently being done for you by font designers. This is a duplication of effort and a maintenance burden; just support font-language-override. It is there for a reason.

-- 
Chris Lilley
@svgeesus
Technical Director, W3C Interaction Domain
Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Myles C. Maxfield
In reply to this post by Andrew Cunningham-4
The criterion for determining “at risk” is interoperable implementations. If you are hoping for vendors to implement this feature, I suggest filing (or commenting in existing) bugs in their respective bug trackers.

—Myles

On May 30, 2016, at 10:22 PM, Andrew Cunningham <[hidden email]> wrote:

Hi all,

The current editors draft indicates that font-language-override feature is at risk.

This feature can be used with firefox, but not with other browsers.

Current support means we can use the Padauk or Noto Sans Myanmar for a range of languages in Firefox that can not be supported by the same font in other browsers. For instance if I need to support some of the other Karen languages using Sgaw Karen preferences, i can not currently rely on font-language-override suppot to handle this.

This forces us to hack the fonts in question making alternative language versions of the fonts where the default rendering is changed.

Reengineering fonts in this way is beyond the ability of the average web developer and browser developers should not be placing this burden on web developers.

If font-language-override is dropped from the spec, an alternative method exposing browsers default locl processing needs to be exposed to web developers, allowing web developers to override locl processing in some fashion.

Andrew


Reply | Threaded
Open this post in threaded view
|

RE: [css-fonts] font-language-override

Levantovsky, Vladimir-2
In reply to this post by Chris Lilley

On Tuesday, May 31, 2016 11:30 AM Chris Lilley wrote:


Let me amplify and restate these points:

 

On 2016-05-31 06:57, Andrew Cunningham wrote:

It would be fairly quick and easy for google to add support for font-language-override


Supporting font-language override would not only increase spec compliance, it would be the path of least effort

I am not sure why font-language-override is really needed, can’t a developer simply define a span with another language tag [the one which behavior one wants to mimic]? Won’t the end result be the same ?

 

Depending on complex mappings from @lang to OpenType lang is a lot of work, currently being done for you by font designers. This is a duplication of effort and a maintenance burden; just support font-language-override. It is there for a reason.

OpenType maintains its own language tag system where the mappings in most cases are 1:1 and in some cases are n:1, but I wouldn’t consider it a complex mapping – as far as user is concerned, there is always a straightforward mapping from a content language tag to the OT language tag. Changing the content language tag, e.g. by defining a span with a different tag, should do the trick.

 

Regards,

Vlad

 

-- 
Chris Lilley
@svgeesus
Technical Director, W3C Interaction Domain
Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Jonathan Kew
On 1/6/16 09:35, Levantovsky, Vladimir wrote:

> *On*Tuesday, May 31, 2016 11:30 AM Chris Lilley wrote:
>
>
> Let me amplify and restate these points:
>
> On 2016-05-31 06:57, Andrew Cunningham wrote:
>
>     It would be fairly quick and easy for google to add support for
>     font-language-override
>
>
> Supporting font-language override would not only increase spec
> compliance, it would be the path of least effort
>
> I am not sure why font-language-override is really needed, can’t a
> developer simply define a span with another language tag [the one which
> behavior one wants to mimic]? Won’t the end result be the same ?
>
> Depending on complex mappings from @lang to OpenType lang is a lot of
> work, currently being done for you by font designers. This is a
> duplication of effort and a maintenance burden; just support
> font-language-override. It is there for a reason.
>
> OpenType maintains its own language tag system where the mappings in
> most cases are 1:1 and in some cases are n:1, but I wouldn’t consider it
> a complex mapping – as far as user is concerned, there is always a
> straightforward mapping from a content language tag to the OT language
> tag.

It is _far_ from complete. Last I checked, the OT spec mentions
somewhere between 4-500 ISO639 language tags. What about the other
7000-plus? (And that's without even considering complications like
regional variants.)

> Changing the content language tag, e.g. by defining a span with a
> different tag, should do the trick.

Changing the content language tag just to get the right shaping is not
an adequate solution.

For one thing, it requires changing the content HTML to achieve
something that should be possible purely through styling.

More significantly, it means you then have content with _incorrect_
tagging, which will break any other process (e.g. spell-checking,
hyphenation, machine translation, text-to-speech, language-sensitive
search and archiving, etc., etc.) that depends on having _correct_ lang
tagging.

We want to be able to have properly lang-tagged content, and render that
content with appropriate shaping. In the absence of an _exhaustive_ and
universally-supported BCP47-to-OpenType mapping, or something like that
-- which would be a huge and difficult undertaking -- the
font-language-override property allows authors to produce the correct
rendering without requiring them to corrupt their content to achieve it.

FWIW, even https://www.microsoft.com/typography/otspec/languagetags.htm 
itself says:

# If information is available to an application declaring the language
# of text content, then the application may make use of that to select
# a default language system tag to be applied when displaying that
# text. It is preferable, however, to give users control over the
# choice of language system tag to be used. ...

recognizing that while the language of the content (as recorded, for
example, by language tagging) may provide a useful default, it is
inadequate as the ultimate determinant of OpenType rendering behavior.

JK


Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Andrew Cunningham-4
In reply to this post by Levantovsky, Vladimir-2

On Wednesday, 1 June 2016, Levantovsky, Vladimir <[hidden email]> wrote:
> On Tuesday, May 31, 2016 11:30 AM Chris Lilley wrote:
>
> Let me amplify and restate these points:

>  
>
> On 2016-05-31 06:57, Andrew Cunningham wrote:
>
> It would be fairly quick and easy for google to add support for font-language-override
>
> Supporting font-language override would not only increase spec compliance, it would be the path of least effort
>
> I am not sure why font-language-override is really needed, can’t a developer simply define a span with another language tag [the one which behavior one wants to mimic]? Won’t the end result be the same ?
>
>  

Umm ... I am surprised someone would really suggest that as an option.

>
> Depending on complex mappings from @lang to OpenType lang is a lot of work, currently being done for you by font designers. This is a duplication of effort and a maintenance burden; just support font-language-override. It is there for a reason.
>
> OpenType maintains its own language tag system where the mappings in most cases are 1:1 and in some cases are n:1, but I wouldn’t consider it a complex mapping – as far as user is concerned, there is always a straightforward mapping from a content language tag to the OT language tag. Changing the content language tag, e.g. by defining a span with a different tag, should do the trick.
>
>

The mappings are 1-1, many-1, 1-many

In at least one case the many-1 mapping contains languages that have incompatible typographic systems. So even if you use the right tag you would need to override aspects of font rendering, which cannot be done in css.

Also technically the OT tag isn't a language tag in the sense that a BCP language tag is. And the OT tag doesn't specifically identify a language.

If I had mixed Latin script and Banum script in Bamum language and using  fonts I would be wanting to use diffeent OT language systems for each font for the same language.

Andrew

--
Andrew Cunningham
[hidden email]



Reply | Threaded
Open this post in threaded view
|

RE: [css-fonts] font-language-override

Levantovsky, Vladimir-2
In reply to this post by Jonathan Kew
Hi Jonathan,

On Wednesday, June 01, 2016 5:22 AM Jonathan Kew wrote:
> Changing the content language tag just to get the right shaping is not an adequate solution.
> For one thing, it requires changing the content HTML to achieve something that should be possible purely through styling.
>
> More significantly, it means you then have content with _incorrect_ tagging, which will break any other process (e.g. spell-checking, hyphenation, machine translation, text-to-speech, language-sensitive search and archiving, etc., etc.) that depends on having _correct_ lang tagging.

I agree it's a hack.

> We want to be able to have properly lang-tagged content, and render that content with appropriate shaping.
> In the absence of an _exhaustive_ and universally-supported BCP47-to-OpenType mapping, or something like
> that -- which would be a huge and difficult undertaking -- the font-language-override property allows authors
> to produce the correct rendering without requiring them to corrupt their content to achieve it.

Having proper language-tagged content is good but if the stated goal of font-language-override is to mimic another language typographic behavior:
a) how a developer would know what the font-supported language tags are (without hacking it)?
b) how one can choose which OT language tag to use for an override if the target language doesn't have it mapped to one of the OT language tags? [and]
c) how do they know what the correct rendering should be (or more importantly) what the actual rendering results on a given platform for a given browser/font are?

Thank you,
Vlad

Reply | Threaded
Open this post in threaded view
|

RE: [css-fonts] font-language-override

Levantovsky, Vladimir-2
In reply to this post by Andrew Cunningham-4

On Wednesday, June 01, 2016 5:40 AM Andrew Cunningham wrote:

On Wednesday, 1 June 2016, Levantovsky, Vladimir <[hidden email]> wrote:
>
> OpenType maintains its own language tag system where the mappings in most cases are 1:1 and in some cases are n:1, but I wouldn’t consider it a complex mapping – as far as user is concerned, there is always a straightforward mapping from a content language tag to the OT language tag. Changing the content language tag, e.g. by defining a span with a different tag, should do the trick.
>
>

The mappings are 1-1, many-1, 1-many

Can you please provide an example of 1-many mapping for OT language tag?


In at least one case the many-1 mapping contains languages that have incompatible typographic systems. So even if you use the right tag you would need to override aspects of font rendering, which cannot be done in css.

If this is the case, then it should probably be fixed in the spec itself, not via the font-language-override hack.


Also technically the OT tag isn't a language tag in the sense that a BCP language tag is. And the OT tag doesn't specifically identify a language.

Yes, the OT language tags define typographic conventions, and some unrelated languages may share the same set of typographic conventions.


If I had mixed Latin script and Banum script in Bamum language and using  fonts I would be wanting to use diffeent OT language systems for each font for the same language.

 

Maybe an example be helpful to clarify things – I must admit that based on what I read as part of the description for font-language-override property it isn’t clear how one would accomplish this (and this might be a contributing factor for the feature to be at risk).

 

Thank you,

Vlad

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

John Hudson
In reply to this post by Levantovsky, Vladimir-2
On 01/06/16 01:35, Levantovsky, Vladimir wrote:

> I am not sure why font-language-override is really needed, can’t a
> developer simply define a span with another language tag [the one
> which behavior one wants to mimic]? Won’t the end result be the same ?

The point of the font-language-override is to enable an author to
specify an OTL language system as supported in a font, in order to
affect a particular typographic display, while retaining accurate
document language tagging. Your suggestion fails in the latter regard,
requiring inaccurate document language tagging in order to affect a
particular display.

The example I give is a document in Macedonian language, displayed with
a webfont that provides Cyrillic variant letters desirable for
Macedonian but only associated in that font with a Serbian OTL language
system tag. Instead of hacking the font to add a Macedonian language
system feature tree, which is both technically non-trivial and may not
be permitted under font license, an author can use
font-language-override to activate the Serbian OTL language system
display behaviour for the Macedonian document text.

> Depending on complex mappings from @lang to OpenType lang is a lot of
> work, currently being done for you by font designers. This is a
> duplication of effort and a maintenance burden; just support
> font-language-override. It is there for a reason.
>
> OpenType maintains its own language tag system where the mappings in
> most cases are 1:1 and in some cases are n:1, but I wouldn’t consider
> it a complex mapping – as far as user is concerned, there is always a
> straightforward mapping from a content language tag to the OT language
> tag. Changing the content language tag, e.g. by defining a span with a
> different tag, should do the trick.
>

I'm going to be pedantic and insist that we use the full correct term
'language system' for the OTL tags — even though it is itself a
misleading misnomer —, because it is important to note that these are
*not* language tags, but a means of activating particular typographic
display, which may or may not map to document language tagging; indeed,
it might not map to a language at all, as in the case of OTL language
system tags for IPA and Americanist phonetic transcription.

JH


--

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        [hidden email]

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


Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Andrew Cunningham-4
In reply to this post by Behdad Esfahbod-5

Hi Behdad,

I am not sure how to respond to your email. I assume you deliberately resent that comment? I have been sitting on this email all day, pondering the contents. my concern is the ability to use lesser used and minority languages on the  internet. There are some browsers that are more suited to this than others.

John please correct any misconceptions of mine on OpenType fonts.

I am aware you believe that language tagging is sufficient and are resistant to implementing font-language-override. Fair enough.

Assuming lang / xml:lang is the preferred approach, we need a cross browser approach and normative requirements. Currently each browser does fairly different things with the language tags and how they match up to OT language systems. This is complicated by the fact that some browsers only support opentype while other browsers support additional font technologies.

One issue is the limited number of OT language system tags, and what seems to be accidental, haphazard approach to adding them. Maybe it is better to describe OT language system tags in terms of evolution, growing and refining over time. OT language system tags were never developed in a systematic way. And it is probably that over time more will need to be added. So locl support via language tags will always be a moving target.

Second issue is the poor mapping between language tags and OT language system tags. Documents like https://www.microsoft.com/typography/otspec/languagetags.htm are far from perfect and require more work.

For instance the OT language tag DNK is mapped to the language tag "din". This is a ISO-639-2 tag, and represents a macro-language. In theory all the ISO-639-3 language tags encompassed by it should be listed as well, but they are absent form this table. So DNK should strictly map to din, dip, diw, dib, dks and dik. Which the copy of the OT spec on Microsoft's site does not reflect.

Many African languages have specific glyph and diacritic placement requirements that may differ from other languages. Concentrating on DNK for a moment and limiting myself to a discussion of Sudanese and South Sudanese languages of which Dinka is one: most other languages from these countries are not represented as OT language system tags. I only have a partial collection of orthography statements for the languages of these countries, maybe one fifth, maybe less. But going through what I have at hand I identified the following language tags that have similar requirements as Dinka: ava, bfa, bxb, krs, bex, mfz, mor, mgd, mur, nus, lot, ddd, keo and mqu.

One option is to greatly expand the number of OT language system tags or alternatively to map these other languages to DNK. John Hudson may correct me, but my understanding is that the OT language system tags were intended to represent shared typographic traditions rather than representing languages per se, so within the context of the OT specifications it would be logical to map va, bfa, bxb, krs, bex, mfz, mor, mgd, mur, nus, lot, ddd, keo and mqu to DNK, rather than adding additional language system tags that essentially would be there to activate exactly teh same typographic features as DNK should.

Another similar example to DNK is the language system tag VIT which maps to "vi". But could and maybe should map to all Vietnamese ethnic languages that use the Latin script and share the same typographic traditions and conventions as Vietnamese does.

To really use lang or xml:lang to enable locl OT features rather than adding support for font-language-override and t future proof it as much as possible time, money and resources  needs to be used to provide as an extensive mapping as possible between bcp47 language tags and OT language system tags.

I would consider this work to be out of scope of the CSS WG, and I'd consider it to be out of scope for the OT spec itself. That leaves us with the browser developers to do the work.

But there are other issues as well. Some OT language tags should never be associated with bcp47 language tags. One such is KRN which represents the Karen languages (essentially it is a macro language tag) encompassing a number of of languages each with their own language code and in soem cases having incompatible typographic conventions. A few of these languages have their own OT language system tags and these should be used in preference to KRN.

John Hudson, in a previous email, listed a number of OT language system tags that do not correspond to any one language.

One other situation is where a OT language system tag is ambiguous or problematic since the language tag on a HTML element is not sufficient in and of itself to indicate if the language system should be used.In this case I am thinking of the KHT language system tag.  The language tag kht maps to KHT, but there are multiple orthographies for Khamti Shan. The fonts that I have seen that support a locl feature for Khamti are based on what is documented in UTN11 which is based on one of the orthographies in current use.

Automatically using KHT for content tagged as kht will work in some cases, but in others give the wrong variants and rendering. So even if you don't  support font-language-override you need some other approach to turning on and off locl support.

a CSS rule like:

:lang(kht) {
    font-feature-settings: "locl" 0;
}

should prevent a browser form using the localised features of a font. In this specific case I would expect the rule to prevent the browser form automatically applying the KHT language system, but rather use the default language system, which may be more appropriate for certain Khamti orthographies. Although it doesn't solve the use case of where a SHN langauge system is available and that may be preferred over the default language system. In the absence of font-language-override maybe the browser needs to implement mroe complex logic, ie

    if kht AND font-feature-settings: "locl" 0 AND SHN use SHN
    if kht AND font-feature-settings: "locl" 0 use dflt
    if kht then use KHT
    else use dflt

but that may not support all Khamti orthographies. I  keep thinking that font-language-override is the easiest solution to the problem.

Automatically using lang / xml:lang to handle locl features is great, I am not against it, I like the feature. But to properly implement it requires a huge amount of work. And honestly I doubt web browser developers would be willing to do the amount of research needed to get it right and support as many languages as possible.

The reality is only a small subset of languages will be supported automatically by lang / xml:lang approach.

For other languages that leaves either font-language-override or not using the locl feature at all.

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Andrew Cunningham-4


On 9 July 2016 at 17:56, Andrew Cunningham <[hidden email]> wrote:
 
Another similar example to DNK is the language system tag VIT which maps to "vi". But could and maybe should map to all Vietnamese ethnic languages that use the Latin script and share the same typographic traditions and conventions as Vietnamese does.



A quick correction :the OT documents map VIT to the iso-639-3 tag vie, but in practical terms this would map to the ISO-639-2 language tag vi as well


--
Andrew Cunningham
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Tab Atkins Jr.
In reply to this post by Andrew Cunningham-4
On Sat, Jul 9, 2016 at 12:56 AM, Andrew Cunningham
<[hidden email]> wrote:
> Hi Behdad,
>
> I am not sure how to respond to your email. I assume you deliberately resent
> that comment? I have been sitting on this email all day, pondering the
> contents. my concern is the ability to use lesser used and minority
> languages on the  internet. There are some browsers that are more suited to
> this than others.

The email's timestamp is for May 30th, making it originally the third
message in the thread.  I suspect this is someone being very late
cleaning out the spam queue, is all.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

Andrew Cunningham-4

Thanks Tab,

I am currently leaning towards locl being a dead feature for minority languages ... in terms of browser support (neither font-language-override  or lang/xml:lang support is there in a cross browser fashion), and maybe its best to support minority languages through a mix of separate forks of fonts or alternative features.

A.

On 12 Jul 2016 4:28 am, "Tab Atkins Jr." <[hidden email]> wrote:
On Sat, Jul 9, 2016 at 12:56 AM, Andrew Cunningham
<[hidden email]> wrote:
> Hi Behdad,
>
> I am not sure how to respond to your email. I assume you deliberately resent
> that comment? I have been sitting on this email all day, pondering the
> contents. my concern is the ability to use lesser used and minority
> languages on the  internet. There are some browsers that are more suited to
> this than others.

The email's timestamp is for May 30th, making it originally the third
message in the thread.  I suspect this is someone being very late
cleaning out the spam queue, is all.

~TJ
Reply | Threaded
Open this post in threaded view
|

Re: [css-fonts] font-language-override

John Hudson
+ Peter Constable


On 11/07/16 11:44, Andrew Cunningham wrote:
> I am currently leaning towards locl being a dead feature for minority
> languages ... in terms of browser support (neither
> font-language-override  or lang/xml:lang support is there in a cross
> browser fashion), and maybe its best to support minority languages
> through a mix of separate forks of fonts or alternative features.

There's been some talk of a mechanism within OTL to specify ISO tags as
OT language system tags, thereby avoiding the need to register separate
OT language system tags for all languages. If language is indeed the
basis on which one wishes to invoke a <locl> glyph or behaviour
variation — it isn't always — then such a mechanism would enable this.

J.


--

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        [hidden email]

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