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

On Tue, 31 May 2016 15:34 Behdad Esfahbod <behdad.esfahbod@gmail.com> 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" <lang.support@gmail.com>
> 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
>>
>