[css-fonts] The Cursive = Chinese Kaiti equivalent

[c933103]

Currently, in https://www.w3.org/TR/css-fonts-4/#cursive-def , it suggested that the Chinese font Kaiti can be seen as a Cursive font. And as far as I understand, numerous browsers and software have already implemented similar equivalent and mapped Kaiti to be a Chinese cursive form and used "cursive" as the English family name for the Chinese font family "Kaiti".

However, the function and purpose of "Cursive" in Latin font and "Kaiti" in Chinese font are quite different from each other. One thing they have in common is that both of them are constructed using handwritten stroke which give a feeling of calligraphic style, as such they can be used in decoration, but that is where the commonality end. The cursive font for Latin character is a more informal font especially on the internet, resembling handwriting written with pen, and have a somewhat distinctive look from regular printed characters. However, the Kaiti font for Chinese character is a formal font (like it is one of the main font that would appears in government document or textbooks), resembling handwriting written with brush, and have a look that generally resemble regular printed character. See https://www.w3.org/TR/clreq/#kai for further description on Kaiti.

As such, given that the purpose of Latin "Cursive" is quite different from the Chinese "Kaiti", I don't think it is wise to promote such equivalency, which could lead to misunderstanding when designers select font families?

And, as a note, Chinese actually have its own cursive font style named as "Caoshu". But not much people use Caoshu font in computer in modern times as they could be rather difficult to read in untrained persons' eyes.

[css-meeting-bot]

The CSS Working Group just discussed The Cursive = Chinese Kaiti equivalent.

The full IRC log of that discussion

<stantonm> topic: The Cursive = Chinese Kaiti equivalent
<astearns> github: https://github.com//issues/4606
<stantonm> chris: first had these thoughts in CSS2, said cursive matched cyrillic (?)
<stantonm> ... how similar is kaiti to cursive
<stantonm> ... would like to see more comments from people who read chinese
<stantonm> myles: can we ask i18n
<stantonm> chris: we should reference clreq
<stantonm> fantasai: usage of kaiti is similar to how english uses italics, not really cursive
<stantonm> ... switching to cursive english font in middle of kaiti feels inappropriate
<stantonm> heycam: see kaiti in childrens books
<stantonm> fantasai: something like comic sans
<stantonm> ... not fully connected writing
<stantonm> florian: mapping english words like cursive doesn't always make sense in other language
<stantonm> ... inconsistent mapping
<stantonm> chris: we don't provide typography for free, better to use font-family name
<stantonm> ... if you want something specific say something specific
<stantonm> fantasai: high-level switching can be nice, distinguish paragraphs
<stantonm> fantasai: think we do need some kind of syntax
<stantonm> florian: should not map all keywords we have to other language
<stantonm> ... how far do we need to go? not sure
<stantonm> astearns: we should ask clreq for this issue
<stantonm> florian: what do we want to ask
<stantonm> astearns: do we need a keyword for kaiti, or can it map to existing keywords
<stantonm> chris: followed spec in good faith, people may need to back things out if we change
<stantonm> s/authors followed/followed/
<dbaron> q+ to comment on whether data indicating which category a font falls in exists in the font or the OS
<chris> s/people/browser implementers/
<stantonm> myles: valuable for us to have criteria on when to add new generic font keywords
<stantonm> astearns: open page on wiki for requirements of new keywords
<stantonm> dbaron: it's useful to have that in the spec, fine to have non-normative explaining why the spec is this way
<Zakim> dbaron, you wanted to comment on whether data indicating which category a font falls in exists in the font or the OS
<stantonm> hober: lets people know how to change it if they see it in spec
<stantonm> astearns: put in wiki as scratch space
<stantonm> dbaron: can we extract metadata from fonts to help derive these keywords
<stantonm> myles: most existing generic font families fail that test
<stantonm> jfkthame: in theory panose should word, but in pratice usually not there
<stantonm> s/word/work/
<fantasai> s/word/work/
<stantonm> myles: some criteria for naming, needs to map to more than just one font file
<stantonm> ... useful for installed fonts, OS's need to have installed fonts that match
<stantonm> ... other criteria is that at least two OS support a font for that generic
<stantonm> chris: not always helpful in underrepresented languages
<stantonm> astearns: but we already resolved to do work on that front
<stantonm> fantasai: so then it's with appropriate language pack installed
<fantasai> for some appropriate definition of language pack
<stantonm> myles: computers don't know, browser dev needs to manually type in list
<Zakim> fantasai, you wanted to say that the threshold is, are typographers regularly using a distinction in font stylistic groupings to make a semantic distinction in their publications
<stantonm> fantasai: threshold should be whether typographers in typical publications are using distinctions between different groups of fonts
<stantonm> ... example is italic vs normal vs bold in latin
<stantonm> ... sans-serif, serif, monospace makes a semantic distinction
<stantonm> dbaron: does serif/sans-serif meet that criteria
<stantonm> hober: good to come up with criteria, stuck with the ones we already have
<stantonm> ... new criteria should just work going forward, may not fit existing perfectly
<stantonm> fantasai: there are stylistic distinctions sometimes, but can also be semantic in many others
<stantonm> florian: criteria is useful for prioritizing, but hard to say yes/no
<stantonm> florian: if we don't meet criteria we shouldn't add, if we meet it we *may* add
<fantasai> it's a sufficient but not necessary criteria
<stantonm> s/florian/fantasai
<fantasai> s/if we don't meet criteria we shouldn't add, if we meet it we *may* add/if we meet the criteria, should add; if we don't, we may add/

[bobbytung]

I remember that we had discussed several years ago in Sapporo.

For now, Chrome , Safari , Firefox will map 'cursive' to KaiTi for both Traditional and Simplified Chinese, when font is available (on Windows and macOS).

The only problem I found is pairing with default cursive latin font. On Edge, that is Comic Sans, On Safari, that is a hand-writing font. Both of them are not good with KaiTi as Serif and San-serif fonts.

[c933103]

See also discussion at http://www.chinaw3c.org/issue-chinese-fonts.html

[svgeesus]

@bobbytung @c933103 thanks! (English translation)

[r12a]

This seems to be a subset of the discussion at #4397

See also it's siblings: #4425 and #4566

[r12a]

Fwiw, the english version of the doc pointed to by c933103 is https://www.w3.org/International/wiki/Chinese_font_families

[c933103]

As an example to the "great variety of fonts in China" mentioned in document, I have checked website of various Chinese font vendors and main types of fonts I have seen are:

Main families: 黑体: Hei (=Gothic), 宋体: Song (=Ming), 仿宋: FangSong, 楷体: Kai, 圆体: Yuen (=MaruGothic)
See https://www.w3.org/TR/clreq/#commonly_used_chinese_typefaces for description and example of the first four, and Yuen is like a version of Hei with rounded corners, which I think it can be considered as a rounded font.

Main calligraphy style: 行书: Hsin (=Semi-Cursive), 隶书: Li (=Clerical), 草书: Tsao (=Cursive), 篆书: Zuan (=Seal)
See http://www.art-virtue.com/styles/ for description and example of these styles. Actually 楷体: Kai (=Regular script in this context) mentioned above is also one of these calligraphy style but it's used frequent enough in modern day Chinese typesetting to be count as one of the main font family, according to my understanding. Functionally they are probably similar to e.g. Roman and Blackletter for Latin characters

And then there are also 手写: Handwriting for handwriting fonts written with a ball pen/ink pen that doesn't fit into any of the aforementioned traditional calligraphy style.

Among these calligraphy styles, there are also some smaller font families like 魏碑: Wei Bei, 欧楷: Ou Kai, 颜楷: Yan Kai and some others that are more specific styles of those calligraphy styles listed above. They are generally font styles that are developed based on historical antique writing samples written during a specific time or by a specific person, reflecting characteristics of those samples. The 仿宋: FangSong style mentioned as one of the main family above is also one example of such, but it's used frequent enough in modern day Chinese typesetting to be count as one of the main font family.

And then there are also various creative/artistic/decorative fonts, like 娃娃体 baby fonts, 卡通体 cartoon/comic fonts, 综艺体 variety show font, POP体 POP font, 古印体 ancient seal font, 少女体 young girl font, 勘亭流体 kanteiryu font, or other functional fonts like fonts with integrated zhuyin/pinyin ruby or font that have mapped most common simplified/traditional glyphs to corresponding glyph in counterpart's system, which are all established styles across different Chinese font vendors.

[xfq]

We discussed this issue in the clreq meeting yesterday. Here's a summary:

Since Chinese have multiple major calligraphy styles, and Kai is only one of them, mapping cursive to Kai is not perfect. The biggest issue is that Kai does not match most cursive Western fonts (aesthetically).

However, the clreq editors still think the current status a useful compromise. In the future, if the CSSWG accepts new generic font families (whether in the form of a registry or not), we think a new generic font family for Kai in CSS would be useful.

[svgeesus]

However, the clreq editors still think the current status a useful compromise.

So, for CSS Fonts 4 in particular, there should be no change to the specification in this area?

And for CSS Fonts 5, where I predict there will be a re-evaluation of the intended use and applicability of generic font families, if we expand the set, then a new generic for Kai (and new generics for other styles?) could be considered.

[xfq]

So, for CSS Fonts 4 in particular, there should be no change to the specification in this area?

It is good enough for the clreq editors, but I have also noticed that the Japanese layout TF chair (@kidayasuo) disagreed with the cursive-Kai mapping (whether the spec needs to be changed is another issue because of potential compatibility issues). In https://lists.w3.org/Archives/Public/public-i18n-japanese/2020AprJun/0089.html :

cursive が楷書にマップされるのは賛成できません。

which means "I don't agree that cursive should be mapped to Kai".

[svgeesus]

Ok so given "mapping cursive to kai is not perfect" and "I don't agree that cursive should be mapped to Kai" then it seems best to remove the mapping.

[xfq]

I agree that mapping Kai to cursive is oversimplified, but if the mapping is removed, there will be no way to use Kai by using a generic font family until the new generic font family is added, and since most browsers has implemented the mapping, there may be compat issues. It would be useful if we can analyze the usage on the Web used before removing the mapping.

---

(You can see the rendered fonts in various browsers here. A CSS library seems to be using this mapping too.)

[c933103]

Actually, to match the need of Kai used in some formal occasion, should the desired font family be Standard Kai/Formal Kai instead of simply Kai? It would also match the role and characterisc of Textbook type in Japanese

[svgeesus]

Related: Font styles & font fallback

[acli]

As I mentioned in issue 4425, the map between kai and italic (structural cursives) / “cursive” (calligraphic) is not exact because of the different axes of slant. Chinese was historically ttb, so kai slants along the vertical axis towards the upper right, even when written horizontally. But the structure is inherently cursive (more so in Japanese type than in Chinese type).

So the problem is when we say italic or cursive, we expect the type to slant along the main axis (so to speak), but traditional obliques and italics in CJK (fangsong and kai, for example) can slant along either the main or cross axes, depending on writing direction; the axis of slant is fixed on the vertical, irrespective of writing direction.

Since this issue is using the term “cursive” not in the typographic sense but in the sense of calligraphic, I’d also like to point out that Chinese kai types are more like italic (formalized cursive) but Japanese kai types are more like “cursive” (calligraphic cursive).

I’d also like to point out that the use of kai in Chinese is in line with how italic was historically used for Latin.

[svgeesus]

Drawing on I18n WG Generic font families I propose to

1. add generic(kai)
2. remove the cursive = kaiti equivalence

to resolve this issue.

It meets the criteria suggested by @litherum, having multiple fonts, including OS fonts, for Simplified Chinese and Traditional Chinese

@r12a @xfq

[xfq]

1. add generic(kai)
2. remove the cursive = kaiti equivalence

I agree with #1.

Regarding #2, although I agree in principle, I don't know how many websites have already relied on this behaviour and whether it's web-compatible. I tested it and at least Blink and Gecko have implemented this behaviour.

[bobbytung]

1. add generic(kai)
2. remove the cursive = kaiti equivalence

I agree with the #1.

Regarding #2, although I agree in principle, I don't know how many websites have already relied on this behaviour and whether it's web-compatible. I tested it and at least Blink and Gecko have implemented this behaviour.

I agree with #1.

About #2, Kai fonts used to be mapped to cursive in Webkit and Blink and Gecko. Webkit removed recently.
It is not well-known by web designer that they can use cursive for Kai font in desktop environment.
And for Chinese both Traditional and Simplified, only san-serif font is available for web content.

So I think it is ok to remove the description in 2.1.3 Generic font families..

[xfq]

The Chinese Layout Task Force discussed this and supports both #1 and #2 in #4606 (comment) . We think it is an important issue, and hope the CSSWG and browser vendors support it soon.