[css-fonts] What does fangsong map to for non chinese text

[frivoal]

The description of the fangsong generic font families should include some guidance as to what sort of font it should map to for characters outside of Chinese. If you pick fangsong and write in Latin, or Arabic, or Hebrew, or Thai, what do you get?

I believe the actual expectation is that for languages/writing-systems where fangsong isn't really a concept, the result should be a serif font. At least that seems to be what the Latin part of FangSong fonts tends to look like.

[svgeesus]

Good point (and the same for emoji and math btw).

I was going to say that maybe it doesn't match anything and we go to the next in the list but no:

Each generic font family must always map to at least one matched font face.
https://drafts.csswg.org/css-fonts-4/#generic-font-families

[AmeliaBR]

I was going to say that maybe it doesn't match anything and we go to the next in the list but no:

Each generic font family must always map to at least one matched font face.

That rule doesn't need to be extended to all new keywords. We could divide the list of generic font keywords according to those that do need to have full coverage and those that don't. We've already discussed this in #4107 (about new system-* font keywords).

[tabatkins]

Agree with Amelia; we should make it clearer that not all generic fonts need to map to a face.

That said, I think fangsong can map to serif in non-chinese text, like Florian said. (I don't think we want to impose cursive on authors of English/etc unless it's really likely they want it.)

[frivoal]

That said, I think fangsong can map to serif in non-chinese text, like Florian said.

For Latin text, that's the right thing to do AFAICT, but at the same time fangsong fonts typically contain the Latin range anyway. I suspect that mapping to serif for other ranges not typically contained in fangsong fonts (Arabic, South East Asian…) is probably also a reasonable thing to do, but I am less confident there.

[svgeesus]

@frivoal

I believe the actual expectation is that for languages/writing-systems where fangsong isn't really a concept, the result should be a serif font.

Perhaps, but the point of fangsong is that it is in some ways an intermediate between serif and sans (plus some other features).

@AmeliaBR

We could divide the list of generic font keywords according to those that do need to have full coverage and those that don't.

If we did that, then authors could decide between fallback to sans and fallback to serif, by putting the appropriate generic font family after fangsong in the stack.

[kojiishi]

The word "fangsong" indicates very specific style for CJK users. Mapping to any other typefaces looks very strange to me.

We don't have active plan to implement this at this moment, but if we do, I think we want to limit only to "fangsong" style fonts. It looks like wikipedia has a list of fangsong CJK fonts.

[svgeesus]

@kojiishi I agree, and tend to prefer (as @AmeliaBR suggested) that fangsong only match for Chinese; otherwise it fails and we move to the next font in the stack.

I think the same strategy would also work well for the two new generic font families emoji and math

[frivoal]

The word "fangsong" indicates very specific style for CJK users. Mapping to any other typefaces looks very strange to me.

As currently defined, it has to map to something, as it is a generic font family type that always matches. If we keep that, we really should say what it maps too. Having fangsong match serif outside of the CJK range doesn't sound much worse to me than saying that "serif" matches "mincho" (which we already do).

However, changing it being more normal and allowing fallbacks, so that the authors can pick what they want if the fangsong font doesn't cover their language also sounds ok to me.

(as for math and emoji, I'm not sure I understand how they work: emoji isn't a style of font, it's a subset of Unicode... but that's probably a separate topic)

[litherum]

We resolved at TPAC that the ui-serif, ui-monospaced, and ui-rounded names won’t map to fonts on some platforms. So we already need language about a separate category of fonts that the spec mentions that aren’t generic font families and therefore don’t need to map to something on every platform.

I understand that it’s valuable for the generic font families to match on every platform so authors can specify them and they will work everywhere. However, the font they match to doesn’t have to support every character. In fact, the matched font can support only a single character, not present anywhere on the webpage. So I don’t quite understand the reasoning behind the fact that all platforms must have a mapping for every generic font family.

[frivoal]

Not 100% sure if we are in agreement or not. Let me try again to state my position, and hopefully it'll be clear enough that you can tell me if we agree :)

I understand that it’s valuable for the generic font families to match on every platform so authors can specify them and they will work everywhere. However, the font they match to doesn’t have to support every character. In fact, the matched font can support only a single character, not present anywhere on the webpage. So I don’t quite understand the reasoning behind the fact that all platforms must have a mapping for every generic font family.

My mental model here of how the current system works is: generic font families don't match a single font; they match a font stack, and the stack does cover as much of Unicode as the system can. There's no fallback after the generic font if the glyph isn't found, because the generic font (stack) is the fallback.

If I ask for sans-serif on "hello 日本", I get (with a particular browser and OS combination) a Helvetica and Hiragino Sans, while I get Times and Hiragino Mincho ProN if I ask for serif. It is defined that serif corresponds to Mincho, Sung / Song, Batang, Naskh, and for languages/script where the a specific style isn't named, the general concept of serif is still described in high level terms.

Of course, what will be in that font stack depends on what's available on the system, and there could be systems where for instance there's a single CJK font, so you cannot ensure that switching from serif to sans serif will always result in switching from a Mincho font to a Gothic one for Japanese. But you do express that intent. That's what generic font families mean to me: within what's available on the system, you pick what sort of fonts will be used if all else fails.

I don't know if it would be web compatible to switch to that model for the existing/traditional generic font families. That could be interesting to look into, as a separate question.

---

Now, for the newer ones, like fangsong, if a "generic" font family name cannot be given some kind of meaning across all of unicode, then it shouldn't be an always matching generic font, and should allow fallback for the ranges it doesn't cover. Otherwise, authors are unable to define their preferred style for regions of unicode not covered meaningfully by the generic font. Or they start to depend on whatever it is that the browser with dominant market share happens to match, and eventually everybody has to follow. If it does match something across all of unicode, then we ought to define, even if in somewhat vague terms, what sort of things it tries to matches.

I don't particularly want fangsong to match across all of unicode, and I'd be perfectly happy defining that it doesn't, and you can specify your own fallbacks for the ranges it doesn't cover, just like we decided to do for ui-serif, ui-monospaced, and ui-rounded.

However, if we don't do that, and keep it as something that matches no matter what, I think we ought to characterize what sort of font it does match. And as a first approximation, outside of the CJK range, I think that the intent of fangsong isn't terribly different from that of serif, that's what I'd state.

Putting it in the same bucket as ui-serif, ui-monospaced, and ui-rounded does sound good an more scalable, as following that pattern will save us from having to answer in #4397 what nastaliq ought to mean for Japanese or Cyrillic, and similar questions problematic questions.

[litherum]

generic font families don't match a single font; they match a font stack

I can't speak for other browsers, but at least in WebKit, all of the generic font families except system-ui match only a single font, not an entire stack. I'm curious whether that's true in other browsers or not.

the stack does cover as much of Unicode as the system can

The point I was trying to make is that there's no guarantee of how much of Unicode is actually covered.

Stated another way: The spec currently says:

Each generic font family must always map to at least one matched font face.

If the goal here is to provide interoperability between browsers, then this statement doesn't actually provide any interoperability guarantees. In order to provide those guarantees, some requirements would have to be added about unicode coverage. I don't quite understand why the spec places the requirement on generic font families always matching at least one face, if it doesn't actually accomplish its goal.

I'm trying to argue that, instead of having some generic font families that always match something on the system and some that don't, we should just say that all of them don't. Because that's effectively the world we already live in today.

But, I'm on a tangent. I should move this into another issue.

[AmeliaBR]

at least in WebKit, all of the generic font families except system-ui match only a single font, not an entire stack.

Are you saying that for font-family: serif, MyWebFont, there are some characters that will trigger the web font as opposed to a system font? This is interesting & opposite to how I've always interpreted the spec. Although now I reread it, I agree with you: it never says that the generics must match for every character!

Can anyone answer how it works in other browsers? Do the existing generics always guarantee complete character coverage?

[tabatkins]

Every browser has a "last resort" font that they use for any characters unmapped by the font stack, but that's shared by every font stack, and so isn't really part of the generic family system.

[kojiishi]

at least in WebKit, all of the generic font families except system-ui match only a single font, not an entire stack.

Same for Blink.

Can anyone answer how it works in other browsers? Do the existing generics always guarantee complete character coverage?

No. There's a system fallback which kicks in after all specified families are exhausted. That tries as much coverage as possible.

[kojiishi]

Tab is right, the "last resort font" is more common terminology than the "system fallback".

[litherum]

Are you saying that for font-family: serif, MyWebFont, there are some characters that will trigger the web font as opposed to a system font?

Yes.

Every browser has a "last resort" font that they use for any characters unmapped by the font stack

This isn't quite right. LastResort is the font that only has a handful of glyphs, the glyphs all look like em boxes, and it maps all of Unicode as those boxes. It isn't really applicable here, since users almost never see it. If an engine falls off the end of the font-family list, it will find some font on the system that can render the desired character. It uses heuristics about which fonts are present inside the font-family list, and tries to find a font that is similar to those but can support the desired character. WebKit does this with CTFontCreateForString(). The only way LastResort will ever be used is if there is literally no font on the entire computer and no web font that can render the character.

[litherum]

The difference between fantasy mapping to a font that supports 0 characters, and fantasy not mapping to any font, is untestable. Untestable things shouldn't be normative in specs.

[AmeliaBR]

OK, bringing this back to the original issue, then:

Generic font families are not required to have full script coverage, or even any script coverage. So that answers @frivoal's original question: the fangsong font doesn't need match to anything outside of what is normally in a fangsong font. Authors can use the font stack to control fallback.

But: should we say more than that?

• Should we specifically restrict fangsong to certain scripts (even if the chosen font-family includes other characters)?

• Or the reverse: should we encourage user agents to create a composite font that looks nice with the fangsong font they are using? E.g., if the fangsong font includes Latin characters of a certain styles, should that style be used consistently for other characters?

• Or should we give user agents free range to find fonts for any script that are "a relaxed, intermediate form between serif and cursive"?

(I suspect that these last two approaches could result in contradictory results.)

[litherum]

(Migrated above issue to #4442)

[svgeesus]

The difference between fantasy mapping to a font that supports 0 characters, and fantasy not mapping to any font, is untestable. Untestable things shouldn't be normative in specs.

Well, fantasy is both useless and wildly untestable, so shouldn't have been in any spec. But there we are.

[r12a]

If i apply font-family:fangsong to the text "第一条 = first", and:

1. i have a fangsong font on my system that is mapped to that generic style, and
2. that fangsong font contains glyphs for Latin characters, then

i would expect the word 'first' to be rendered using the glyphs in the fangsong font. Is this consistent with the direction in which this thread is going? (I couldn't tell for sure.)

I think that that behaviour would be important, not only for aesthetic reasons related to glyph shapes, but also because if you did something similar with, say, arabic+latin text and ended up substituting different fonts for arabic and latin letters, you'd almost certainly have significant headaches around baseline alignment and relative font sizes.

[svgeesus]

With the recent resolution of issue: 4442 Don't require browsers to always match every generic font family to a concrete font family, it is now clearer that

a) the other (new) generic font families may not map to at one matched face
b) even if they do, there may be no match for a given codepoint.

[c933103]

The different between Song (the current simplified chinese equivalent to serif) and Fangsong in Simplified Chinese typography is really not that big (see comparison chart in https://zhuanlan.zhihu.com/p/66725620 with red = Song, green = Fangsong), that while design feature of both of them are distinctive enough to separately categorize them as two different font families, I believe it would be fine to correspond both of them to serif fonts in almost all other languages.

[svgeesus]

So the specification now: clearly distinguishes universal generics, may-match generics and script-specific (may match) generics.

It also states that generic(fangsong) is a script-specific, may-match generic:

Note: ''generic(fangsong)'' might not map to any locally installed font, but if it does, that font will be in Fang Song style.

[svgeesus]

@r12a:

i would expect the word 'first' to be rendered using the glyphs in the fangsong font. Is this consistent with the direction in which this thread is going? (I couldn't tell for sure.)

Yes. The steps are a) does it exist and b) does it have glyph coverage for the codepoint.

[svgeesus]

I believe that with recent edits, this issue is ready to be closed. Any disagreement?

[acli]

In principle Fangsong is an oblique roman. It slants toward the upper-right corner because Chinese used to be written ttb. The structure is roman (Ming) and it has a slant but it does not have flow (italic-ness).

[acli]

The real script specificity here is that historically the script was ttb, so the angle of slant is towards the upper right along tthe vertical axis, as opposed to (say obliques for Latin) towards the right along the horizontal axis.