font-family and generic font not working for Chinese Kaiti font.
Categories
(Core :: Layout: Text and Fonts, defect, P5)
Tracking
()
People
(Reporter: mattison.computer, Unassigned)
References
Details
(Keywords: fonts, testcase)
Attachments
(9 files, 1 obsolete file)
display_part1.png: screen capture of top half+ of display page generated by kaiti.html
I made web pages that contain mostly English with some Chinese mixed in. I want the Chinese characters to display with Chinese KaiTi font in all operating systems. I develop these pages on my Fedora (currently release 28) workstation. The Kaiti font on this workstation is "AR PL Ukai CN".
In the html file, when a paragraph's "font-family" value list starts with "ar pl ukai cn", the Chinese text is displayed as I want. Otherwise, I get what looks like a HeiTi (sans-serif) font. I tried including in the "font-family" value list "kaiti", "kaishu", "regular", "zheng", and "zhen", and combinations that try hyphenated and two-word variations of these. I also set the generic font to "cursive" (without the quotes). I always get the sans-serif font for the Chinese characters.
According to this W3C web page:
"https://www.w3.org/TR/css-fonts-4/",
"cursive" (without the quotes) is the correct generic family for Chinese KaiTi fonts. I've also seen in a few web pages that "kaiti" is the correct font-family for KaiTi Chinese fonts. But these did not work correctly.
There are 4 attachments:
- the html file "kaiti.html" that generates the page showing the problem.
- a screen capture of the top half+ of the display generated by "kaiti.html".
- a screen capture of the bottom half+ of the display generated by "kaiti.html".
- a screen capture of my Firefox font preferences.
I have only done this on my Fedora-28 work station. Results might be different on other workstations and other operating systems.
|
Reporter | |
Comment 1•5 years ago
|
||
|
|
Reporter | |
Comment 2•5 years ago
|
||
|
|
Reporter | |
Comment 3•5 years ago
|
||
|
||
Comment 4•5 years ago
|
||
:xidorn since you're the assignee of bug 1220019, maybe you'd like to take a look at this.
|
||
Comment 5•5 years ago
|
||
The CSS generic font-family: cursive will map to a KaiTi font if this is specified in the font preferences. Mappings for the (rarely-used) cursive value are not exposed in the Preferences window; you'd need to look in about:config for the setting font.name-list.cursive.zh-CN (or ...zh-HK or ...zh-TW, as appropriate for your content).
It doesn't look like Firefox has any default mapping for cursive Chinese font prefs on Linux (I see defaults for Windows and macOS, but quite likely there's too much variation among Linux distributions for any useful "universal" default to be set).
The other issue I see is that your test document is tagged with lang=en, which means it won't use the Chinese font prefs anyway; it'll use the Western (Latin-script) font prefs.
So to get the result you're looking for, I think you need to appropriately lang-tag your Chinese content with lang=zh-CN (or other zh-XX as appropriate); AND configure an appropriate font.name-list.cursive.<lang> preference, as there's no default provided on Linux.
(Assuming you don't want the surrounding English text to use a cursive font, you'd need to mark up the Chinese separately anyway so that you can have different font-family lists for the two kinds of text.)
If you want a reliable KaiTi result for all users, though, I think the only real option will be to provide a webfont with the style you want, as you can't be sure what (if anything) various browsers and operating systems will provide for the cursive generic name.
|
|
||
Comment 6•5 years ago
|
||
I should add: if there is a "standard" KaiTi font, or maybe a couple of options, that we can expect to be widely available across a range of Linux distributions, we can consider adding this to the default font prefs. Otherwise, it's not clear to me that there's an actionable issue here.
Or if you're using Firefox as packaged by a particular distribution, rather than the generic Linux build directly from Mozilla, another way forward would be for the distro packagers to add a suitable KaiTi font pref to their particular package.
|
||
Comment 7•5 years ago
|
||
It seems to me that we almost don't specify any mapping on Linux at all, we basically just rely on fontconfig's default settings.
That makes me wonder whether adding something like pref("font.name-list.cursive.zh-CN", "cursive"); would help... which leads me to bug 1173260. According to that bug, I suppose we already invoke fontconfig when querying cursive generic font. So it is probably just responsibility of distributions and users to setup the proper mapping in fontconfig, and there is probably nothing we should do here.
|
|
Reporter | |
Comment 8•5 years ago
|
||
(responding to comments 4 through 9 inclusive)
First, I was sloppy in my original description of the problem. “kaiti” is a family of fonts, not a specific font. The specific font on my workstation is “ar pl ukai cn”. This is like “Times” - a family of fonts, vs. “NimbusRomNo9L” and “Times Roman” - each a specific font.
Having studied a page in the W3C web site and a few pages in the W3Schools web site, here's my understanding of how things should work. The web page designer and programmer should not have to be concerned about browser settings like those in “about:config”. He should be able to design and program a web page, and expect viewers on almost all operating systems and hardware to see the same thing, including font families, without the viewer having to touch browser settings (assuming the page does not use rare font families, and the browser is is not configured to suppress/block page font settings). The kaiti font family is one of the major Chinese font families, along with “songti”, “heiti”, and maybe “fangsongti”. Most hardware and OSs should have a kaiti font.
It's also my understanding of W3C requirements that the browser is to try to match the font family starting with the first (leftmost) value in the “font-family” list of values, and continue rightward until a match is found or there are no more choices. In my test file (attachment 1 [details] [diff] [review]), most of the test lines (the 27 which included a “font-family” of “kaiti”) should have matched either the first “font-family” value or the second “font-family” value. Browser efforts should have succeeded before reaching “cursive” (the generic font). It didn't work. All of the test lines except the first should have succeeded at “cursive” had they not succeeded before.
Also, shouldn't Chinese characters (and text of other non-English characters) be recognized by their UTF-8 codes? It seems to me that “lang=” shouldn't be needed.
I'll “play around” some more with “lang=”, “span”, and font families. Meanwhile, please consider W3C requirements before deciding what to do with this bug, and how to fix it. I'll also try to research more on best practices in designing and programming multi-language web pages.
Question: I've been assuming that “kaiti” is the correct “font-family” for the various kaiti fonts. What actually is the correct “font-family” for all the kaiti fonts?
|
|
||
Comment 9•5 years ago
|
||
(In reply to Bill Mattison from comment #8)
(responding to comments 4 through 9 inclusive)
Thanks for the detailed writeups. There is no comment 9, though.
First, I was sloppy in my original description of the problem. “kaiti” is a family of fonts, not a specific font. The specific font on my workstation is “ar pl ukai cn”. This is like “Times” - a family of fonts, vs. “NimbusRomNo9L” and “Times Roman” - each a specific font.
The concept is a bit of messing, but in CSS's terminology, Kaiti conceptually is not a single font family, it's a set of font families, or to say, it's a generic font family. It includes font families like DFKai-SB, SimKai, STKaiti, and so on. A font family, for example, Kaiti SC on macOS, includes fonts Kaiti SC Regular, Kaiti SC Black, and Kaiti SC Bold. Similarly, Times is a font family including Times Regular, Times Italic, Times Bold, and Times Bold Italic. Times New Roman, then, is a different font family.
Having studied a page in the W3C web site and a few pages in the W3Schools web site, here's my understanding of how things should work. The web page designer and programmer should not have to be concerned about browser settings like those in “about:config”. He should be able to design and program a web page, and expect viewers on almost all operating systems and hardware to see the same thing, including font families, without the viewer having to touch browser settings (assuming the page does not use rare font families, and the browser is is not configured to suppress/block page font settings). The kaiti font family is one of the major Chinese font families, along with “songti”, “heiti”, and maybe “fangsongti”. Most hardware and OSs should have a kaiti font.
So, no. Those are conceptually closer to generic font family, which consists from different font families.
It's also my understanding of W3C requirements that the browser is to try to match the font family starting with the first (leftmost) value in the “font-family” list of values, and continue rightward until a match is found or there are no more choices. In my test file (attachment 1 [details] [diff] [review]), most of the test lines (the 27 which included a “font-family” of “kaiti”) should have matched either the first “font-family” value or the second “font-family” value. Browser efforts should have succeeded before reaching “cursive” (the generic font). It didn't work. All of the test lines except the first should have succeeded at “cursive” had they not succeeded before.
CSS Fonts spec maps generic font family serif to Song, sans-serif to Hei, and cursive to Kai in Chinese. CSS Fonts Level 4 creates a new generic font fangsong for Fang Song. See Generic font families in CSS Fonts Level 4.
Also, shouldn't Chinese characters (and text of other non-English characters) be recognized by their UTF-8 codes? It seems to me that “lang=” shouldn't be needed.
Chinese characters in Unicode has their codepoints, but "lang=" is still needed, especially for Chinese characters (more than any other scripts), which is because Chinese characters are used by several different languages, especially Japanese and Korean. That is why they are officially called CJK characters.
A single Chinese character can have different shape in different languages. Even in Chinese, a character can be different among different region, hence distinguishing zh-CN, zh-TW, and zh-HK is also important for picking the right font to use.
I'll “play around” some more with “lang=”, “span”, and font families. Meanwhile, please consider W3C requirements before deciding what to do with this bug, and how to fix it. I'll also try to research more on best practices in designing and programming multi-language web pages.
Question: I've been assuming that “kaiti” is the correct “font-family” for the various kaiti fonts. What actually is the correct “font-family” for all the kaiti fonts?
It is cursive, with lang="zh-CN".
cursive has been mapped to corresponding Kai font families on Windows and macOS for zh-{CN,TW,HK}, while on Linux we fully delegate all generic font family mappings to fontconfig, and thus cursive may not map to Kai if the user / system doesn't choose to do so there.
Ideally Linux distributions can follow the same spec to provide Kai as cursive.
|
|
Reporter | |
Comment 10•5 years ago
|
||
|
|
Reporter | |
Comment 11•5 years ago
|
||
|
|
Reporter | |
Comment 12•5 years ago
|
||
|
|
Reporter | |
Comment 13•5 years ago
|
||
The terminology (“font”, “font-family”, “generic font”, and others) is somewhat confusing. There seems to be some “overloading” and inconsistency in the use of such terms. Further discussion to learn these terms would be helpful, but not really appropriate here in bug comments. Xidorn, your comment #9 was helpful; may I ask more questions of you off-line?
I did “play around” some more. I think my new test xhtml file is a better test; it is attachment #5 [details] to this bug. (It does validate.) The results were screen-captured; see attachments 6 and 7. I now think that my assumption that the browser would/could use the UTF-8 codes to determine language, which resulted in my not using the “span” feature, was the cause of the problem. The problems I originally reported were not caused by a bug in Firefox. My apologies for the unjustified bug. In my opinion, you may close this bug. If there is anything more you want me to do, please let me know.
I am experiencing an unrelated problem in Firefox. It has to do with animation (looping) of weather satellite pictures. In this case, I'm the user, not the programmer. The programmer has not responded to me. I'm told by someone else that it works fine in a different browser. Who can I discuss this with before submitting a bug, so I don't submit another invalid bug?
|
|
||
Comment 14•5 years ago
|
||
Given comment 13, I'm going to close this bug as INVALID.
There is one problem in your latest testcase in attachment 9041215 [details] I'd like to mention that, cursive as a generic font family should be specificed as a keyword, rather than a string, which means you need to write font-family: cursive rather than font-family: "cursive".
I am experiencing an unrelated problem in Firefox. It has to do with animation (looping) of weather satellite pictures. In this case, I'm the user, not the programmer. The programmer has not responded to me. I'm told by someone else that it works fine in a different browser. Who can I discuss this with before submitting a bug, so I don't submit another invalid bug?
Don't worry about filing invalid bug. (We ourselves file invalid bug from time to time as well.) If you see something unexpected, just file a new bug and describe it. Browser developers generally know more about what's the best next step for those things, and we also have team to track web compatibility issues regardless of whether it's a bug of our browser or the website.
|
|
Reporter | |
Comment 15•5 years ago
|
||
|
|
Reporter | |
Comment 16•5 years ago
|
||
|
|
Reporter | |
Comment 17•5 years ago
|
||
|
|
Reporter | |
Comment 18•5 years ago
|
||
(responding to comment 14)
(sigh)
"cursive" vs. cursive.....
I made the correction. Now this bug needs to be "resurrected". The xhtml file in attachment #8 [details] shows the correction, and another 2 test cases. A screen capture of the results are in attachment #9 [details].
- "cursive": what should this do?
- cursive as a keyword does not work as it should.
- sans-serif as a keyword works as the keyword cursive should. I think this works because of how I've set my font preferences.
- not specifying a font, font-family, or generic font results in a kaiti font. Is this how it should work?
I do not understand why "cursive" and no font-family gave different results, or the results shown.
Key point: Using the keyword cursive as suggested results in a hei font for the Chinese characters, not a Kaiti font. Please resurrect this bug.
|
|
||
Comment 19•5 years ago
|
||
As I mentioned above, on Linux, we fully delegate the mapping of generic font family to fontconfig like all other generic font families. It's probably that your fontconfig having incorrect mapping.
|
|
Reporter | |
Comment 20•5 years ago
|
||
Based on what Jonathan Kew said (comment 5), I searched about:config for "font.name-list.cursive". No matches at all. I need more instructions on this.
|
|
||
Comment 21•5 years ago
|
||
You can create new string value naming font.name-list.cursive.zh-{CN,HK,TW}. That being said, it probably makes sense to add them to prefs even if C++ code can do the fallback, so that it is more discoverable from about:config.
|
|
Reporter | |
Comment 22•5 years ago
|
||
(In reply to Xidorn Quan [:xidorn] UTC+8 from comment #21)
You can create new string value naming
font.name-list.cursive.zh-{CN,HK,TW}.
font.name-list.cursive.zh-CN string kaiti (does not work)
font.name-list.cursive.zh-CN string cursive (does not work)
font.name-list.cursive.zh-CN string AR PL Ukai CN (this works)
I did not know that us mere users could add things to about:config.
I learn something new every year!
Thank-you, Xidorn.
That being said, it probably makes sense to add them to prefs even if C++ code can do the fallback, so that it is more discoverable from about:config.
You completely lost me here. I hope this is intended for Firefox programmers!
|
|
||
Comment 23•5 years ago
|
||
You completely lost me here. I hope this is intended for Firefox programmers!
That's right, it's for us Firefox developers.
Description
•