Description of problem:
UMing as packaged by Fedora comes with a fontconfig file 65-ttf-arphic-uming.conf that prepends it to a number of families in a number of locales. This file has problems.
Version-Release number of selected component (if applicable):
Always (text-editor level).
Steps to Reproduce:
1. gedit /usr/share/fontconfig/conf.avail/65-ttf-arphic-uming.conf
This file wants to prepend UMing, a serif, to the good list of sans-serifs. This file also misses AR PL UMing CN for zh_CN.
UMing should not be prepended as a sans-serif. An entry similar to HK and TW for UMing CN should be added.
Current default fonts are way ahead of them in precedence, so this problem on its own shouldn't cause anything bad unless someone uninstalled all of them...
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.
Compared to Source Han Sans CN, both UMing and UKai are Serif fonts, I think.
> I think maybe good to not change default Chinese fonts by installing fonts packages.
UMing is attempting to do so with the "prepend" directives its fontconfig file. It fails because Fedora has other defaults. Parts of its attempts -- those adding it to sans-serif -- are nevertheless wrong. And "Sans" is short for sans-serif FYI.
> UMing/UKai fonts are for Traditional Chinese, not for Simplified Chinese.
There are CN variants. You might be thinking it is for Trad. because it is not complying well with Chinese standards, but guess what it's not very TW/HK-compliant either. And people still use it in TW and HK!
If you are thinking it's not for Simp. because it's called a "Ming", then nobody should be using Source Han Serif for Trad and Japanese because it's called a "Song".
> Compared to Source Han Sans CN, both UMing and UKai are Serif fonts, I think.
Fontconfig uses generic families beyond sans-serif, serif, and monospace. You can read those files numbered 60 to 69 in conf.avail for a sense of it. There's "cursive" for handwritten stuff[^1] like Kai and Comic Sans. There's also "fantasy" for crazy-looking things like "impact".
[^1]: my bad, I've been calling it "script". I will re-test 1531985.
Since the rules in the fontconfig file of AR PL UMing package try to prepend itself in the generic Sans-serif and Monospace font candidate list besides Serif one, installing the package will definitely affect the default Chinese font behavior.
There three main thoughts on this issue:
1. UMing is a 明體/宋體 typeface which is grossly referred to the generic Serif font family. It must not claim itself as a candidate font to prepend to the generic "Sans-serif" or "Monospace" font family or it creates unexpected result for everyone who install the package.
The rules to claim AR PL UMing as a generic sans-serif or monospace font family should be removed
2. AR PL UMing provides AR PL UMing CN variant for China, although the glyph in TW, HK and CN are all the same. The project planned to support different variants of the glyph in different regions but failed to do so after the initial commit. The project latter stopped and is not maintained anymore.
However, we can still map AR PL UMing CN to map zh-cn language tag for the users to let applications using fontconfig technology can see AR PL UMing as a generic Serif font family.
3. As we are using Source Han Serif font as the default Chinese font candidate in the generic Serif font family, we should make sure that installing AR PL UMing package won't change the default Chinese font behavior.
In my f27 installation with traditional Chinese environment, I installed AR PL UMing package as well, and the output of fc-match -s Serif still see Source Han Serif TW font as the first Chinese candidate, so the Chinese font candidate list seems to work as expected.
$ fc-match -s Serif
SourceHanSerifTW-Regular.otf: "思源宋體 TW" "Regular"
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSerif-Bold.ttf: "DejaVu Serif" "Bold"
DejaVuSerif-Italic.ttf: "DejaVu Serif" "Italic"
DejaVuSerif-BoldItalic.ttf: "DejaVu Serif" "Bold Italic"
NimbusRoman-Regular.t1: "Nimbus Roman" "Regular"
StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"
STIX-Regular.otf: "STIX" "Regular"
STIX-Bold.otf: "STIX" "Bold"
STIX-Italic.otf: "STIX" "Italic"
STIX-BoldItalic.otf: "STIX" "Bold Italic"
Caladea-Regular.ttf: "Caladea" "Regular"
SourceHanSerifCN-Regular.otf: "思源宋体 CN" "Regular"
Symbola.ttf: "Symbola" "Regular"
mingliu.ttc: "新細明體" "Regular"
Lohit-Bengali.ttf: "Lohit Bengali" "Regular"
Lohit-Gujarati.ttf: "Lohit Gujarati" "Regular"
Lohit-Tamil.ttf: "Lohit Tamil" "Regular"
Meera.ttf: "Meera" "Regular"
Lohit-Kannada.ttf: "Lohit Kannada" "Regular"
Lohit-Telugu.ttf: "Lohit Telugu" "Regular"
uming.ttc: "AR PL UMing TW" "Light"
In all, the rules of the fontconfig file provided by cjk-uming-fonts package should be modified to remove the "sans-serif" and "monospace" part. It would be better to add "AR PL UMing CN" for "zh-cn" language to let programs see it as a Serif font in zh-cn environment as well.
Tseng, I don't have that much problem with the monospace part as UMing, like all the old Chinese fonts, is indeed a monospace. It's just I won't use it as one because my eyes would hurt…
PS: UKai has the same latin characters as UMing.
Oh, sorry that I don't find it as a Monospace font as well. :P
Just checked, the Latin glyph width of AR PL UMing IS half the the Chinese one, so the "monospace" part can be reserved.
The rules which should be removed are the ones about generic "sans-serif" font family.
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.