Bug 1531985

Summary: UKai does not come with a fontconfig file specifying it as a cursive
Product: [Fedora] Fedora Reporter: Mingye Wang <arthur200126>
Component: cjkuni-ukai-fontsAssignee: Peng Wu <pwu>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: i18n-bugs, kent.neo, petersen, pswo10680, pwu
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-30 20:50:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mingye Wang 2018-01-07 02:47:46 UTC
Description of problem:
AR PL UKai, as packaged by Fedora, does not take precedence over current "script" placeholder Source Han Sans CN in a zh_CN locale. As a proper "script" -- handwritten-y -- typeface, UKai should be prioritized over a printed-looking Sans.

Version-Release number of selected component (if applicable):
0.2.20080216.1-56

How reproducible:
Always

Steps to Reproduce:
1. Install it
2. LC_ALL=zh_CN.utf8 fc-match -a script | less
3. Unpack the rpm, and go "uh"

Actual results:
UKai does not come with a fontconfig file specifying it as a script. It goes way after SHSCN in fc output.

Expected results:
It should be before SHSCN.

Additional info:

Comment 1 Peng Wu 2018-01-08 05:09:14 UTC
I think maybe good to not change default Chinese fonts by installing fonts packages.

If you want to change default Chinese fonts, please try fonts-tweak-tool.

UMing/UKai fonts are for Traditional Chinese, not for Simplified Chinese.

Comment 2 Mingye Wang 2018-01-08 05:47:21 UTC
> not change

In that case we got a broken default. We can remove the forced priority on Source Han Sans, and fix fontconfig's 40-nonlatin instead.

Also, the UMing package still does a prepend, which is a weak attmpt at changing the default.

> Simp

UMing/UKai come with CN variants, which are for Simplified Chinese.

Comment 3 Mingye Wang 2018-01-08 05:50:34 UTC
(Can we discuss the CN issue in #1531986 instead?)

Comment 4 Cheng-Chia Tseng 2018-01-08 06:49:48 UTC
There are some generic font families with different definitions: sans-serif, serif, monospace, cursive and script. 

Kaiti or Kai is more of a cursive font or script font.

Here is a rough mapping between the generic font families and the Chinese typefaces:

Sans-serif to 黑體
Serif to 宋體/明體
Monospace to 英文字母寬度為中文字寬度一半的任何字型 (any Chinese fonts whose Latin glyph width is half of the Chinese character)
Cursive to 楷體/草書
Script to 楷體/手寫體

The relationship above is widely accepted and used in Chinese publishing industry, especially on Web and EPUB.

I agree and suggest to see AR PL UKai font as a Cursive font as in the general font family.

PS. I don't think Mingye is trying to change the default Chinese font by his description. That issue seems to be out of what he is trying to talk about.

Comment 5 Mingye Wang 2018-01-08 07:57:04 UTC
Reconfirmed this issue with `fc-match -a cursive:lang=zh-cn | less`. Source Han Sans is, again, first on the list.

The connection between cursive/script is indeed wobbly. In theory cursive should only have things that are, well, cursive like Zapfino[1] and 草, but since there isn't one family for a more slowly-written script it is used for "elementary school level" script fonts like 楷 and Comic Sans[2] as well.

[1]: https://en.wikipedia.org/wiki/Zapfino
[2]: https://en.wikipedia.org/wiki/Comic_Sans

Fontconfig's 60-latin runs "cursive" in this sequence:

1. ITC Zapf Chancery Std[3]
2. Zapfino[1]
3. Comic Sans[2]

From [3] you can see Zaph Chancery isn't as "cursive" as Zapfino either; it's more like an in-between handwitten script. In Chinese terminology you may call it a 行?

[3]: https://www.linotype.com/850/itc-zapf-chancery-family.html

Comment 6 Ben Cotton 2018-11-27 16:18:34 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Ben Cotton 2018-11-30 20:50:43 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.