[css-fonts] Propose adding lang as a font-face descriptor

[kahsieh]

See https://drafts.csswg.org/css-fonts-3/#at-font-face-rule

Per the discussion in #1736, we note that generic fonts typically map to more than one system font with lang affecting the resultant font. Adding lang as a @font-face descriptor might be useful for similar reasons, for example with CJK:

• CJK have partially intersecting character sets, so unicode-range alone cannot specify fonts for each language. This can be an issue on pages containing text in more than one lang.
• Even if a single font (or @font-face) contains faces for all the characters in some text, that font may not be for the correct lang everywhere. (A single codepoint can map to different variant glyphs depending on lang, and this is reflected in fonts.)

This addition would allow fonts to resolve lang-appropriately when a font family specified with @font-face is applied to a page with multiple langs.

[litherum]

Exposing an implementation detail of existing font selection facilities is not a sufficient use case to justify a new web-facing feature.

[AmeliaBR]

Here's a specific use case:

The Noto collection of fonts includes sans & serif fonts for most modern languages. For CJK, that means multiple fonts for the same code points, optimized for each language. They offer both subsetted font files (with just the glyphs for one language) and full CJK fonts, with the specified language as the default and the others available through OpenType features. Of course, the full fonts are much larger files.

For a website that is primarily in one language, but wants to have compatible glyphs for occasional content in another language, it would be preferable to be able to use the subsetted font files, only downloading the additional language when it is required:

@font-face {
font-family: Noto Sans;
src: url(.../noto-sans-jp.woff2);
lang: jp;
}
@font-face {
font-family: Noto Sans;
src: url(.../noto-sans-kr.woff2);
lang: kr;
}
@font-face {
src: url(.../noto-sans.woff2);
unicode-range: /* whatever would be the ascii/latin range */
}

The last rule shows how we can currently use unicode-range to do language fallbacks where the scripts have different unicode code points. But we can't do it for language-based switching of glyphs for a single codepoint. That is only available through OpenType features in a single font file -- or through the browser font selection algorithm for generic font families.

[kahsieh]

@AmeliaBR Thank you for the specific use case—it does seem to me that the CJK case is limited by the standard, rather than by existing implementations. Due to Han unification, rendering a character completely correctly requires both the codepoint and the lang.

I'll add the example from my post in #1736 of lang causing a glyph change on the same codepoint given font-family: sans-serif:

left: zh, right: ja

[tabatkins]

:shakes fist at Han unification again:

@litherum Yeah, while this is definitely part of the built-ins, it's relevant for any page that wants to do high-quality rendering of both Chinese and Japanese text with a single combined font-family.

[faceless2]

I also think this is a good idea. Particularly if we define the "lang" property as a list of languages, and define the highest priority @font-face match as (assuming all other @font-face matching criteria are equal) the one with the longest common prefix. For example:

@font-face {
  font-family: thefont;
  src: url(thefont-zh-simp.otf);
  lang: zh
}
@font-face {
  font-family: thefont;
  src: url(thefont-zh-trad.otf);
  lang: zh-HK zh-TW
}

• Language of "zh-TW" will match both rules, but the second has the higher priority.
• Language of "zh-SG" will match the first rule due to the common prefix "zh"

[svgeesus]

Due to Han unification, rendering a character completely correctly requires both the codepoint and the lang

Han unification is a clear use case for language-specific font rendering, but not the only one. In Cyrillic, for example, there are differences between Russian, Serbian and Bulgarian rendering of the same Unicode code point. (A good explanation).

As to whether we need a new descriptor though, things are less clear. OpenType already has a language feature, and Fonts 3 Language-specific display already states:

If the content language of the element is known according to the rules of the document language, user agents are required to infer the OpenType language system from the content language and use that when selecting and positioning glyphs using an OpenType font.

If that is not enough, there is also the font-language-overide property.

I see the motivation for the proposed descriptor, but also see it re-inventing the OpenType language system with a combination of a new descriptor and a link to a (subsetted, single-language) font.

This seems at odds with the direction the font industry seems to be headed, with multi-language fonts which can have quite careful and nuanced typography for different languages, depending of course on the effort and interest of the font designer.

The matching scheme mentioned by @faceless2 looks the same as BCP 47 language tagging. On the other hand, OpenType language tagging uses a single level of 4-byte codes. So for example Traditional Chinese is ZHT .

[faceless2]

Yes, assuming a suitably enabled font you can do all of this with font-language-override, or Unicode variation selectors. But I believe the intention of the original poster was to prevent the font being loaded at all if it doesn't apply. Not so much an issue with cyrillic/arabic/urdu, more useful with the bigger Chinese/Japanese fonts.

[patrickdark]

I think it should be more clear what problem needs solving:

Given a traditional Chinese document with a run of Japanese text, a property declaration such as font-family: "Traditional Chinese Font", "Simplified Chinese Font", "Japanese Font"; should just work with glyphs from the appropriate script displayed, including characters with one code point but multiple, language-specific glyphs.

Instead of using a language descriptor, a better approach may be to use a language exclusion descriptor. So, for the aforementioned "Traditional Chinese Font", one might declare something along the lines of exclude-lang: "*-hans", "*-jpan" in its @font-face rule and this would prevent it from being used to render text marked as ja-jpan, zh-hans, zho-hans, etc.

This approach also avoids having to make a decision about how to label a font that contains characters from multiple languages.

[kahsieh]

@svgeesus As mentioned by @faceless2, the intention is to skip loading the font if it doesn't apply. In @AmeliaBR's example with Noto fonts, subsetted, single-language fonts are already offered for use on the web because the full multi-language fonts are large. This somewhat accounts for the use of the BCP 47 language tags rather than OpenType language tags: the lang descriptor would be matched with HTML language tag(s) and not font file language tag(s).

@patrickdark I think it's okay if a font contains characters from multiple languages. The author need only specify lang in @font-face for languages that should be rendered in specific fonts, and then there can be fallback behavior for other languages. It seems to me that using an exclude-lang descriptor could get unwieldy. For example, a site about the use of Classical Chinese might use various combinations of the zh-Hans, zh-Hant, ja-JP, ko-KR, and vi-VN language tags on its pages.

[svgeesus]

This looks like a good topic to f2f discussion at TPAC, perhaps together with I18n and also with Fonts WG

[faceless2]

For what it's worth, we've implemented this locally (with a prefix, naturally) and it's working well.

Referencing the steps for font matching outlined at
https://drafts.csswg.org/css-fonts/#font-style-matching, we have effectively added a step before 5a which is "sort the remaining fonts first by how well they match the element's language, based on BCP47, and secondly on the order they're defined in CSS".

So for example: you have three matching fonts with languages of "zh-hant", "zh" and no language. If the font is requested by an element with a language of "zh-hans", it will match "zh". If the element language is "en", all of the fonts have equal priority based on the language match so are prioritised by the order they're defined in CSS, exactly as they are in the current spec.

This approach is backwards compatible: with no languages on the @font-face rule, the matching algorithm runs as it is now. And, if a language is defined, it won't prevent it from matching an element with a different language: it will only change the priority they're matched on.

I have one more argument in favour of this. In the PDF world where we're coming from, every font has to be embedded. So as well as time taken to download the font and better language-specific shapes for the glyphs, we need this to reduce the size of the final document. For example:

@font-face {
  font-family: Noto;
  src: url(NotoSerifCJKzh-Regular.otf);
  lang: "zh"
}
@font-face {
  font-family: Noto;
  src: url(NotoSerifCJKjp-Regular.otf);
  lang: "ja"
}

<p lang="ja">日本の字</p>

Without language matching (and presuming Noto Chinese has no hiragana glyphs for the sake of example), we'd embed two fonts: the first two glyphs would match the Chinese fonts as it has a higher priority, with the third matching the Japanese font.

[asmusf]

Just to put that one on the record: language tuning may be appropriate for Latin-script fonts as well. It appears that Polish and French use some of the same accents but with different angles, to give just one example that was widely discussed at one point in Unicode. The standard ended up "unifying" the two language versions of these characters, meaning that one either has to use some compromise font or be able to select a font variant by language.
There are probably other examples.