change default CJK fonts to Noto CJK

Bug #1468027 reported by tomoe_musashi on 2015-06-23
96
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Ubuntu Seeds
Fix Released
Undecided
Unassigned
kubuntu-meta (Ubuntu)
Medium
Gunnar Hjalmarsson
language-selector (Ubuntu)
Medium
Gunnar Hjalmarsson
lubuntu-meta (Ubuntu)
Critical
Gunnar Hjalmarsson
ubuntu-meta (Ubuntu)
Medium
Aron Xu
xubuntu-meta (Ubuntu)
Medium
Gunnar Hjalmarsson

Bug Description

just realize that fonts-noto-cjk is available in the repository, finally its packaged.
i don't really know about korean community.
But for Chinese and Japanese community, i think that the answer is clear.
noto-cjk is definitely better what we had before, like fonts- wqy and fonts-droid.
Android community had received these complains for years, finally they got them fixed on lollipop.
Fedora also set it as default chinese font start from F21.
and of course, i still hope that ubuntu could drop those 69-language-selector fontconfig files, just like what F13 did.

tomoe_musashi (musashi) on 2015-06-23
Changed in language-selector (Ubuntu):
assignee: nobody → tomoe_musashi (musashi)
tomoe_musashi (musashi) on 2015-06-23
Changed in language-selector (Ubuntu):
assignee: tomoe_musashi (musashi) → nobody
Gunnar Hjalmarsson (gunnarhj) wrote :

fonts-noto-cjk installs NotoSansCJK.ttc. Time for Chinese? For Japanese?

tomoe_musashi (musashi) wrote :

i think its time for chinese and japanese, or maybe korean as well.

Nobuto Murata (nobuto) wrote :

Hello tomoe_musashi,

I believe Noto Sans CJK is one of the best fonts available in free/libre licenses for Japanese. However I'm not convinced to set the Noto Sans CJK as default yet and I would like to know your motivations here.

> But for Chinese and Japanese community, i think that the answer is clear.
> noto-cjk is definitely better what we had before, like fonts- wqy and fonts-droid.

For Japanese locale, what makes you so confident when compared to fonts-takao, the current default font?

> Android community had received these complains for years, finally they got them fixed on lollipop.
> Fedora also set it as default chinese font start from F21.

Can you point to a link where the discussion happened in Fedora?

> and of course, i still hope that ubuntu could drop those 69-language-selector fontconfig files, just like what F13 did.

Can you explain a bit how F13 dropped the files? In Ubuntu, language-selector no longer manages fontconfig files. Instead font packages have fontconfig files, e.g. /etc/fonts/conf.avail/65-fonts-takao-pgothic.conf in fonts-takao-pgothic. Even with Noto Sans CJK I think we still need to choose font family name per locale such as "Noto Sans CJK JP" for ja_JP locale.

Gunnar Hjalmarsson (gunnarhj) wrote :

On 07/06/2015 05:14 PM, Nobuto Murata wrote:> On 06/23/2015 07:42 PM, tomoe_musashi wrote:
>> and of course, i still hope that ubuntu could drop those
>> 69-language-selector fontconfig files, just like what F13 did.
>
> Can you explain a bit how F13 dropped the files? In Ubuntu, language-
> selector no longer manages fontconfig files.

Actually it does. The Japanese fontconfig files were moved to fonts-takao, but there are still a bunch of 69-language-selector-zh-* files, and I think tomoe_musashi is referring to those.

I, too, wonder which files F13 dropped. Fedora does not use language-selector.

2015-07-07 0:38 GMT+09:00 Gunnar Hjalmarsson <email address hidden>:
> On 07/06/2015 05:14 PM, Nobuto Murata wrote:> On 06/23/2015 07:42 PM, tomoe_musashi wrote:
>>> and of course, i still hope that ubuntu could drop those
>>> 69-language-selector fontconfig files, just like what F13 did.
>>
>> Can you explain a bit how F13 dropped the files? In Ubuntu, language-
>> selector no longer manages fontconfig files.
>
> Actually it does. The Japanese fontconfig files were moved to fonts-
> takao, but there are still a bunch of 69-language-selector-zh-* files,
> and I think tomoe_musashi is referring to those.

Ah, right. I thought CJK related files were moved when
fontconfig-voodoo was dropped. Thanks for the correction.

tomoe_musashi (musashi) wrote :

Hi Nobuto Murata,

Actually i think that fonts-takao is one of the best Japanese out there.but when its compared to fonts-noto, noto provides more weights, better CJK fonts support with multilingual, and personally, better monospace fonts paring bwtween English letters and CJK fonts, better e-reading experience with unified fonts design.

here are some links that they discussed about changing Fedora's Chinese fonts(in Chinese):
https://lists.stg.fedoraproject.org/archives/list/chinese%40lists.fedoraproject.org/thread/ATEHR3KTVLOL5WSXV2HZ4BAPPKDELXNF/
https://<email address hidden>/thread/ABGCWMJK7BDJD6QDZ4UFCHLVJXCCFV7T/

i apologize about uncertain F13 info i posted. its nothing to do with language-selector. i will edit the description.
And for those applications lacking locl GSUB feature and lang tagging, setting font family for per locale would be necessary.

Cheng-Chia Tseng (zerng07) wrote :
Download full text (3.5 KiB)

Fedora 21 only applies Adobe Source Han Sans / Noto Sans CJK to Chinese locale (zh_CN and zh_TW).

Fedora does not use 69-language-selectors-*.conf because they only set one major font for one locale, and they write the relevant configuration in the corresponding fontconfig fille for the major font. That is, they set one font for Serif, Sans-serif, and Monospace (listed below). However, I don't like this method. Using 69-language-selectors-*.conf is more flexible here.

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match>
        <test name="family" compare="contains">
                <string>Source Han Sans</string>
        </test>
        <edit name="autohint" mode="assign">
                <bool>false</bool>
        </edit>
        <edit name="hintstyle" mode="assign">
                <const>hintfull</const>
        </edit>
    </match>
    <match>
        <test name="lang">
            <string>zh-tw</string>
        </test>
        <test name="family">
            <string>monospace</string>
        </test>
        <edit name="family" mode="prepend">
        <string>Source Han Sans TW</string>
        <string>Source Han Sans CN</string>
        </edit>
        <edit name="family" mode="prepend" binding="strong">
        <string>DejaVu Sans Mono</string>
        </edit>
    </match>
    <match>
        <test name="lang">
            <string>zh-hk</string>
        </test>
        <test name="family">
            <string>monospace</string>
        </test>
        <edit name="family" mode="prepend">
        <string>Source Han Sans TW</string>
        <string>Source Han Sans CN</string>
        </edit>
        <edit name="family" mode="prepend" binding="strong">
        <string>DejaVu Sans Mono</string>
        </edit>
    </match>

    <alias>
        <family>Source Han Sans TW</family>
        <default>
            <family>monospace</family>
        </default>
    </alias>

    <match>
        <test name="lang">
            <string>zh-tw</string>
        </test>
        <test name="family">
            <string>serif</string>
        </test>
        <edit name="family" mode="prepend">
            <string>Source Han Sans TW</string>
            <string>Source Han Sans CN</string>
        </edit>
    </match>
    <match>
        <test name="lang">
            <string>zh-hk</string>
        </test>
        <test name="family">
            <string>serif</string>
        </test>
        <edit name="family" mode="prepend">
            <string>Source Han Sans TW</string>
            <string>Source Han Sans CN</string>
        </edit>
    </match>

    <alias>
        <family>Source Han Sans TW</family>
        <default>
            <family>serif</family>
        </default>
    </alias>

    <match>
        <test name="lang">
            <string>zh-tw</string>
        </test>
        <test name="family">
            <string>sans-serif</string>
        </test>
        <edit name="family" mode="prepend">
            <string>Source Han Sans TW</string>
            <string>Source Han Sans CN</string>
        </edit>
    </match>
    <match>
        <test name="lang">
            <string>zh-hk</string>
        </test>
   ...

Read more...

Cheng-Chia Tseng (zerng07) wrote :

According to the README pdf file (https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf) of Adobe Source Han Sans, and the experience within LibreOffice, I have to say that Super OTC file is not well supported in Linux desktop.

It is suggested using Regional Subset OTF files in Linux for now; however, that will take us a lot of space to keep all the OTF files. This is what Fedora provides for CN and TW locales, 7 files for about 39.6MB for TW locale and about 58.6MB for CN locale.

The other way is to endure the poor support of Super OTC and file related issues to those infected packages. And this will be a hard way for us to go. It will benefit the ecosystem better in the long run, but I don't recommend this way.

tomoe_musashi (musashi) wrote :

I agree that using 69-language-selectors-*.conf is more flexible IF ubuntu resulted to use Regional Subset OTF instead of Super OTC.
We should not fallback a sans-serif font to serif.
Also, they provide fixed width font for regular and bold weight font start from 1.002, as known as Source Han Sans HW or Noto Sans Mono CJK.
As their monospace fonts(english letters) are designed for SHS/Noto, i don't see the point to fallback DejaVu Sans Mono.

Aron Xu (happyaron) wrote :

After reading through the threads of discussion on Noto fonts on Fedora 21/22, I'm getting a bit conservative about whether we want to change the default font for CJKV at the moment. Most of our users are still using non-hidpi displays, and it appears that using Noto fonts with that would result into unexpected results...

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in fonts-noto (Ubuntu):
status: New → Confirmed
Changed in language-selector (Ubuntu):
status: New → Confirmed
Changed in ubuntu-meta (Ubuntu):
status: New → Confirmed
2 comments hidden view all 134 comments
Xhacker Liu (xhacker) wrote :

Hi Aron,

Have you seen any particular unexpected results? I’ve been using Noto Sans CJK for about a month on a low-dpi display. Based on my experience, besides the multiple weights it provides, it looks way better compared to WenQuanYi Micro Hei.

WenQuanYi Micro Hei was derived from Droid Sans Fallback, which is a font particularly designed for saving space. Noto Sans CJK is a very well-designed font family with complete character set. I’d say Noto Sans CJK is no doubt the best open-source Chinese font at this time.

Yuan Chao (yuanchao) wrote :

Comparing with WenQuanYi Micro Hei, Noto Sans is surely a better choice to me. For low-DPI display, a proper hinting configuration is needed. (if not using embedded bitmap font) This should not be a show stopper here?

Aron Xu (happyaron) on 2016-01-10
Changed in fonts-noto (Ubuntu):
assignee: nobody → Aron Xu (happyaron)
importance: Undecided → Medium
status: Confirmed → In Progress
Changed in language-selector (Ubuntu):
importance: Undecided → Medium
status: Confirmed → In Progress
assignee: nobody → Aron Xu (happyaron)
Changed in ubuntu-meta (Ubuntu):
assignee: nobody → Aron Xu (happyaron)
status: Confirmed → In Progress
affects: fonts-noto (Ubuntu) → fonts-noto-cjk (Ubuntu)
Changed in ubuntu-meta (Ubuntu):
importance: Undecided → Medium
Aron Xu (happyaron) wrote :

MIR for fonts-noto-cjk filed as Bug #1532533.

Mingye Wang (artoria2e5) wrote :

happyaron: O again, rendering, rendering, rendering. For systems with TT Bytecode support, be5invis has a release of SHS with his sfdhanautohint (for CJK) and ttfautohint applied called [Inziu]. Follow the link and fetch inziu-20\d{10}.

These generally look better on lower ppem sizes (common for loDPI screen display), and is turned off (just not generating the bytecode) for sizes >= 25ppem (and for fairly impossible sizes like <=9ppem). Hey this discussion looks familiar doesn't it…

Oh and these are all TrueType, so expect the same problem (or benefit, for Qt users) with Kaigen Gothic—you lose some OpenType features. Generated bytecode also makes the files fat.

  [Inziu]:http://code.fosshub.com/Inziu/downloads

Anyway these sharp things will not be considered with Ubuntu's current hintslight policy. This policy is not quite loDPI optimized either so you might want to… whatever. WQY looks blurry too, you know. I thought the WQY files were hintless actually.

Mingye Wang (artoria2e5) wrote :

My decaying brain… I mean \d{6}. I should just say ‘anything that's not iosevka’.

* * *

Well the biggest blocker here is actually some application support things. Qt show poor overall handling of some OpenType features used in SHS, the most significant being LOCL used in all those Super files. Line spacing also look weird under both Noto and SHS (SHS has a few releases to fixes some of the problems under OS X but … some said they break Plasma 5.)

If compatibility looks like a issue, a (relatively crazy) solution is to preinstall Kaigen Gothic instead. It's basically a TrueType version with some features removed (sigh.) If size looks like a problem (it definitely is), try to wise with the weights to preinstall, and don't even consider adding bytecode.

Aron Xu (happyaron) on 2016-01-12
Changed in fonts-noto-cjk (Ubuntu):
status: In Progress → Fix Committed
assignee: Aron Xu (happyaron) → nobody
Aron Xu (happyaron) wrote :

The MIR has been accepted, would you mind to review the l-s changes? I'll continue to track what to do in fonts-noto-cjk.

Changed in language-selector (Ubuntu):
assignee: Aron Xu (happyaron) → Gunnar Hjalmarsson (gunnarhj)
status: In Progress → Triaged
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-01-12 06:37, Aron Xu wrote:
> The MIR has been accepted, would you mind to review the l-s changes?

Not at all, I'll do that. Are we talking about Chinese only at this time?

Please note that the seeds of all the flavors need to be changed in the same manner as in your linked merge proposal for ubuntu.xenial.

> I'll continue to track what to do in fonts-noto-cjk.

One thing is that we need an equivalent to the config file in fonts-droid in order to make fonts-noto-cjk co-exist with the fonts-arphic-* packages, i.e. to prevent that UKai and UMing is picked over Noto by default when there is a non-Chinese locale. (See the discussion in bug #1227034.) I played with a possible config file, which may or may not be sufficient for the purpose:

$ cat /etc/fonts/conf.d/64-fonts-noto-cjk.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
        <alias>
                <family>sans-serif</family>
                <prefer>
                        <family>Noto Sans CJK SC</family>
                        <family>Noto Sans CJK TC</family>
                </prefer>
        </alias>
</fontconfig>
$ LANG=en_US.UTF-8 fc-match -a | grep -iE 'noto|ar pl' | head -20
NotoSansCJK.ttc: "Noto Sans CJK SC" "DemiLight"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Regular"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Medium"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Thin"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Light"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Bold"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Black"
NotoSansCJK.ttc: "Noto Sans CJK TC" "DemiLight"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Regular"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Medium"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Thin"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Light"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Bold"
NotoSansCJK.ttc: "Noto Sans CJK TC" "Black"
ukai.ttc: "AR PL UKai CN" "Book"
ukai.ttc: "AR PL UKai HK" "Book"
ukai.ttc: "AR PL UKai TW" "Book"
uming.ttc: "AR PL UMing CN" "Light"
uming.ttc: "AR PL UMing HK" "Light"
uming.ttc: "AR PL UMing TW" "Light"

But this certainly needs to be tested by users who speak Chinese.

Gunnar Hjalmarsson (gunnarhj) wrote :

The language-selector changes were just uploaded. This *really* need to be carefully tested soon by some Chinese users.

@Aron: Any thoughts on the matters I raised in comment #20?

Changed in language-selector (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package language-selector - 0.154

---------------
language-selector (0.154) xenial; urgency=medium

  * data/pkg_depends, fontconfig/69-language-selector-zh-*.conf:
    Default font for Chinese changed from "Droid Sans Fallback" to
    "Noto Sans CJK" (LP: #1468027).

 -- Gunnar Hjalmarsson <email address hidden> Sat, 16 Jan 2016 00:43:00 +0100

Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Aron Xu (happyaron) wrote :

@Gunnar, I'm working on that, :)

tomoe_musashi (musashi) wrote :
Download full text (4.0 KiB)

There should be a real monospaced English character font prepended, like DejaVu Sans Mono (i think the Noto Sans Mono is too small for reading). For some applications, there are problems with the current config file.
reference: https://github.com/adobe-fonts/source-han-sans/issues/57

Also, i think the Aliases for Chinese should be modified for noto-cjk
the modified part:
<!-- Aliases for Simplified Chinese Windows fonts -->
    <alias>
        <family>SimSun</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>NSimSun</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>SimSun-18030</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>NSimSun-18030</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>宋体</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>新宋体</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>AR MingtiM GB</family>
        <accept>
            <family>HYSong</family>
            <family>AR PL UMing CN</family>
        </accept>
    </alias>
    <alias>
        <family>KaiTi</family>
        <accept>
            <family>AR PL UKai CN</family>
            <family>AR PL ZenKai Uni</family>
        </accept>
    </alias>
    <alias>
        <family>楷体</family>
        <accept>
            <family>AR PL UKai CN</family>
            <family>AR PL ZenKai Uni</family>
        </accept>
    </alias>
    <alias>
        <family>Microsoft YaHei</family>
        <accept>
            <family>Noto Sans CJK SC</family>
            <family>WenQuanYi Micro Hei</family>
            <family>WenQuanYi Zen Hei</family>
        </accept>
    </alias>
    <alias>
        <family>微软雅黑</family>
        <accept>
            <family>Noto Sans CJK SC</family>
            <family>WenQuanYi Micro Hei</family>
            <family>WenQuanYi Zen Hei</family>
        </accept>
    </alias>
<!-- Aliases for Traditional Chinese Windows fonts -->
    <alias>
        <family>MingLiU</family>
        <accept>
            <family>AR PL UMing TW</family>
        </accept>
    </alias>
    <alias>
        <family>細明體</family>
        <accept>
            <family>AR PL UMing TW</family>
        </accept>
    </alias>
    <alias>
        <family>PMingLiU</family>
        <accept>
            <family>AR PL UMing TW</family>
        </accept>
    </alias>
    <alias>
        <family>新細明體</family>
        <accept>
            <family>AR PL UMing TW</family>
        </accept>
    </alias>
    <alias>
        <family>AR MingtiM BIG-5</family>
        <accept>
            <family>AR PL UMing TW</family>
       ...

Read more...

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for your comments, tomoe_musashi.

On 2016-01-16 05:32, tomoe_musashi wrote:
> There should be a real monospaced English character font prepended, like
> DejaVu Sans Mono (i think the Noto Sans Mono is too small for reading).
> For some applications, there are problems with the current config file.
> reference: https://github.com/adobe-fonts/source-han-sans/issues/57

Do you mean like this:

                <edit name="family" mode="prepend" binding="strong">
                        <string>DejaVu Sans Mono</string>
                        <string>Noto Sans Mono CJK SC</string>
                        <string>WenQuanYi Zen Hei Mono</string>
                        <string>HYSong</string>
                        ...
                </edit>

> Also, i think the Aliases for Chinese should be modified for noto-cjk

Ok, will do.

tomoe_musashi (musashi) wrote :

@Gunnar Hjalmarsson, exactly like that. Thank you for your hard work.

Yuan Chao (yuanchao) wrote :

For the prepend list, separated conf. for TC and SC is needed as different localized glyphs now supported by Noto sans. It would be nice if suitable "real" mono space EN fonts are prepended.

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-01-17 04:51, tomoe_musashi wrote:
> @Gunnar Hjalmarsson, exactly like that.

Thanks for confirming.

On 2016-01-17 04:53, Yuan Chao wrote:
> For the prepend list, separated conf. for TC and SC is needed as
> different localized glyphs now supported by Noto sans.

Right, we've had different fonts for TC and SC for many years, so that's already in place.

Changed in language-selector (Ubuntu):
status: Fix Released → In Progress
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-01-17 05:12, Gunnar Hjalmarsson wrote:
> Right, we've had different fonts for TC and SC for many years, so
> that's already in place.

s/fonts/confs/

Changed in language-selector (Ubuntu):
status: In Progress → Fix Committed
Gunnar Hjalmarsson (gunnarhj) wrote :

The build of language-selector with the latest changes failed.
http://irclogs.ubuntu.com/2016/01/17/%23ubuntu-devel.html#t21:05

So please be patient; sooner or later it will end up in the archive. ;)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package language-selector - 0.155

---------------
language-selector (0.155) xenial; urgency=medium

  * fontconfig/69-language-selector-zh-*.conf:
    Prepend "DejaVu Sans Mono" for monospace (LP: #1468027).
  * fontconfig/30-cjk-aliases.conf:
    Include "Noto Sans CJK" where applicable (LP: #1468027).

 -- Gunnar Hjalmarsson <email address hidden> Sun, 17 Jan 2016 17:30:00 +0100

Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Mateusz Gryzzli (gryzzli) wrote :

fc-cache -f -v is insanely slow with fonts-noto-cjk, upwards of 20 minutes on slower atom systems!!!

tomoe_musashi (musashi) wrote :

Just played with the config file for fonts-noto-cjk that @Gunnar posted above.
Its works great in non-Chinese locale, but it lacks monospace font support.
this should be added:
        <alias>
                 <family>monospace</family>
                 <prefer>
                         <family>Noto Sans Mono CJK SC</family>
                         <family>Noto Sans Mono CJK TC</family>
                 </prefer>
         </alias>

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, tomoe_musashi. I wrote a patch to get it in.

Changed in fonts-noto-cjk (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
status: Fix Committed → In Progress
tags: added: patch
Xhacker Liu (xhacker) wrote :

Just tried 16.04 nightly, I think the CJK font is too thin compared to Ubuntu Regular. Which weight for Noto Sans CJK do we use here? I played a little in LibreOffice, I believe the “Regular” weight should be used by default.

Gunnar Hjalmarsson (gunnarhj) wrote :

Font weight isn't specified in the fontconfig files. For simplified Chinese, fc-match lists them in this order:

$ LC_CTYPE=zh_CN.UTF-8 fc-match -a | head -7
NotoSansCJK.ttc: "Noto Sans CJK SC" "DemiLight"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Regular"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Medium"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Thin"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Light"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Bold"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Black"

Possibly it means that "DemiLight" is used by default. How would you specify font weight in fontconfig?

V字龍(Vdragon) (vdragon) wrote :

Using Regular here

$ LC_CTYPE=zh_TW.UTF-8 fc-match -a | head -7
SourceHanSansTW-Regular.otf: "思源黑體 TW" "Regular"
SourceHanSansCN-Regular.otf: "思源黑体 CN" "Regular"
SourceHanSansJP-Regular.otf: "Source Han Sans JP" "Regular"
DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSansCondensed.ttf: "DejaVu Sans" "Condensed"

currently no much problem about it.

1 comments hidden view all 134 comments
Mingye Wang (artoria2e5) wrote :

Regarding monospace, a +1 for musashi on prepending, since I have seen SHS HW doing terrible at distinguishing 0O 1Il. If someone can verify that these chars don't look bad in Noto Mono CJK, I guess that works too.

Note that you should always only prepend half-width fonts, where ``wcwidth(foochar) == 1`` means the glyph takes exactly 1/2em, or character alignment might still go wild.

Mingye Wang (artoria2e5) on 2016-03-11
no longer affects: language-selector
Mingye Wang (artoria2e5) on 2016-03-11
no longer affects: fontconfig
no longer affects: language-selector
Changed in fontconfig:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in language-selector (Ubuntu):
status: Fix Released → Fix Committed
Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Mingye Wang (artoria2e5) on 2016-03-12
no longer affects: fontconfig (Ubuntu)
Changed in language-selector (Ubuntu):
status: Fix Released → Fix Committed
Changed in fonts-noto-cjk (Ubuntu):
assignee: Gunnar Hjalmarsson (gunnarhj) → nobody
importance: Medium → Undecided
status: In Progress → New
tags: removed: patch
Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Changed in kubuntu-meta (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → In Progress
Changed in lubuntu-meta (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Critical
status: New → In Progress
Changed in xubuntu-meta (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → In Progress
Changed in ubuntu-meta (Ubuntu):
status: In Progress → Fix Released
no longer affects: fonts-noto-cjk (Ubuntu)
tags: added: xenial
tags: added: cjk
Changed in fontconfig:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in fontconfig:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in language-selector (Ubuntu):
status: Fix Released → Fix Committed
Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Changed in lubuntu-meta (Ubuntu):
status: In Progress → Fix Committed
55 comments hidden view all 134 comments
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for that report, Yuan Chao. It indicates that bug #1556457 is more urgent than we (I) first thought.

May I ask: Is "Regular" picked up first with a ja_JP or zh_TW locale?

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-03-28 21:56, Gunnar Hjalmarsson wrote:
> May I ask: Is "Regular" picked up first with a ja_JP or zh_TW
> locale?

Correction: with a zh_* locale.

(With a ja_JP locale, TakaoPGothic is still the default.)

Yuan Chao (yuanchao) wrote :

> May I ask: Is "Regular" picked up first with a ja_JP or zh_TW
> locale?
Yes, (only tested with live env) according to fc-match "Regular" is picked up over "DemiLight" in both zh_TW and zh_CN. TakaoPGothic is the default for ja_JP.

However, for Firefox, this hack in /etc/fonts/conf.d/69-language-selector-zh-??.conf doesn't seem to work. According to the inspection tool of Firefox, "AR PL UMing CN/TW", "Noto Sans CJK SC/TC Bold" and "DemiLight" are picked up.

UMing is second to TakaoPGothic so could be a problem in ja_JP on serif? (UMing does not have enough glyph coverage in JP)

Yuan Chao (yuanchao) wrote :
Yuan Chao (yuanchao) wrote :
Yuan Chao (yuanchao) wrote :
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, Yuan Chao. Let me try so summarize then:

There is an issue with fontconfig, so it by default picks "Demilight" over "Regular" (bug #1556457). We have tried to work around this problem in 69-language-selector-zh-??.conf and
64-language-selector-prefer.conf (the latter for e.g. an English locale). The workaround is not effective in Firefox, though.

I'm out of ideas. Is there anything we can do but waiting for bug #1556457 to be fixed? (Assuming that will address the Firefox issue...)

On 2016-03-30 12:30, Yuan Chao wrote:
> UMing is second to TakaoPGothic so could be a problem in ja_JP on
> serif? (UMing does not have enough glyph coverage in JP)

Possibly, but if so it wouldn't be a new problem. With the Japanese locale, and with full Japanese language support installed, TakaoPMincho is there for serif.

Gunnar Hjalmarsson (gunnarhj) wrote :

As a test I built fontconfig 2.11.94 in a PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/fontconfig-test2

I don't know yet if it would be possible to have it accepted for the 16.04 archive. What I know is that it would fix 'the Demilight issue' without the current workaround in the language-selector .conf files.

Would appreciate if some of you could test it. I'm especially interested in knowing if this fontconfig version also fixes the undesirable Firefox behaviour wrt font weights.

Changed in fontconfig:
importance: Medium → Unknown
status: Fix Released → Unknown
affects: fontconfig → ubuntu-seeds
Changed in ubuntu-seeds:
importance: Unknown → Undecided
status: Unknown → New
tomoe_musashi (musashi) wrote :

@Gunnar, i can confirm that the ppa fixes the "DemiLight" issue.
it also fixes some cases that rendering with undesirable font weights.

tomoe_musashi (musashi) wrote :
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-04-03 06:02, tomoe_musashi wrote:
> @Gunnar, i can confirm that the ppa fixes the "DemiLight" issue. it
> also fixes some cases that rendering with undesirable font weights.

Great, thanks! Then I'll try to get it in.

Gunnar Hjalmarsson (gunnarhj) wrote :

Fixed in lubuntu-meta 0.64.

Changed in lubuntu-meta (Ubuntu):
status: Fix Committed → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

Hi again,

We met some hesitation in upgrading to fontconfig 2.11.94 this late in the cycle, so together with Mingye Wang I have also built 2.11.1 in a PPA, where the necessary upstream commits have been patched:

https://launchpad.net/~gunnarhj/+archive/ubuntu/fontconfig-test

So, as a base for decision, I'd appreciate very much if you could install and test version 2.11.1-0ubuntu9~ppa. Does it fix the Chinese rendering issues as well as 2.11.94 seems to do?

Gunnar Hjalmarsson (gunnarhj) wrote :

Update: fontconfig 2.11.1-0ubuntu9 is building, and will soon be in the Ubuntu archive. So if you haven't already, there is no reason now to bother with the PPA I mentioned in comment #107. Better test the real thing instead. :)

Changed in language-selector (Ubuntu):
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package language-selector - 0.164

---------------
language-selector (0.164) xenial; urgency=medium

  * fontconfig/69-language-selector-zh-*.conf:
  * fontconfig/64-language-selector-prefer.conf:
    Dropped workaround to make "Regular" the default font weight for
    Noto Sans CJK; fixed in fontconfig 2.11.1-0ubuntu9 (LP: #1468027).
  * debian/control:
    Bump Standards-Version to 3.9.7.

 -- Gunnar Hjalmarsson <email address hidden> Tue, 05 Apr 2016 10:35:00 +0200

Changed in language-selector (Ubuntu):
status: Fix Committed → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

Since fontconfig 2.11.94 is on its way into the archive, I'd like to mention this "call for testing" message I posted to the ubuntu-devel mailing list:

https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039303.html

Changed in xubuntu-meta (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xubuntu-meta - 2.205

---------------
xubuntu-meta (2.205) xenial; urgency=medium

  * Refreshed dependencies
  * Added fonts-noto-cjk to desktop-recommends (LP: #1468027)

 -- Sean Davis <email address hidden> Wed, 06 Apr 2016 21:59:33 -0400

Changed in xubuntu-meta (Ubuntu):
status: Fix Committed → Fix Released
Shih-Yuan Lee (fourdollars) wrote :

I tried this on Firefox and it seems to work fine.

Shih-Yuan Lee (fourdollars) wrote :

But, when I tried it on Chromium, it still doesn't work.

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, Shih-Yuan. Thin? Why Thin?

Same for me with Google Chrome. Don't Chrome and Chromium care about fontconfig, but do it their own way?

Any ideas how this issue could be addressed?

Mingye Wang (artoria2e5) wrote :

Not sure. Some fontconfig tracing env vars might be useful for the Skia LegacyCreateTypeface part I guess...

* * *

In addition to the weight matching problem, the screenshot for Chromium in #113 gives the JP variant instead of TW. Perhaps I should try to get someone to reproduce this in other distros and file a report upstream... Not sure about what the title will be.

> Don't Chrome and Chromium care about fontconfig, but do it their own way?

Chrome seems to provide some level of per-script font handling[1]. Actually Google Chrome gives a link to an extension called ‘Advanced Font Settings’ (caclkomlalccbpcdllchkeecicepbmbm) in its font menu...

  [1]: https://developer.chrome.com/extensions/fontSettings

Regarding the JP problem, it seems that Google Chrome is trying to do the script recognition itself. This happens on my Windows 10 machine too -- Chinese comments on GitHub and Tweets are all rendered using ‘Inziu Roboto JP’, my default Japanese script font set with ‘Advanced Font Settings’. Webpages with explicit language/script declarations like https://zh.wikipedia.org/zh-tw/ work fine since they don't need any recognition by Chrome (will anyone confirm this on Ubuntu?)

It seems that some Chrome font settings can be pre-hacked by editing webkit.webprefs.fonts. The 'Zyyy' (default script) one found in chrome settings is stored in the file 'Preferences' -- perhaps some settings for other scripts can be filled in here too?

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-04-07 21:24, Mingye Wang wrote:
> In addition to the weight matching problem, the screenshot for
> Chromium in #113 gives the JP variant instead of TW.

I didn't even notice "JP" first. This made me fear that
/etc/fonts/conf.avail/64-language-selector-prefer.conf has something to do with it. But the issue with too thin characters in Chrome/Chromium is there also with a TC locale:

$ locale | grep LC_CTYPE
LC_CTYPE=zh_TW.UTF-8
$ fc-match
NotoSansCJK.ttc: "Noto Sans CJK TC" "Regular"
$

So it's probably unrelated to that.

Isn't this issue really weird? Shouldn't Google make sure that their own web browser handles their own fonts properly?

Changed in kubuntu-meta (Ubuntu):
status: In Progress → Fix Committed
Changed in kubuntu-meta (Ubuntu):
status: Fix Committed → Fix Released
Changed in ubuntu-seeds:
status: New → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

We have a solution to the Chrome/Chromium and "Thin" issue in sight at bug #1575555. A modified version of fonts-noto-cjk is available in this PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/fonts-noto-cjk

It would be great if a few Chinese and Japanese users could install fonts-noto-cjk (and possibly fonts-noto-cjk-extras) from the PPA and let us know the result. Please report your observations on the other bug.

Cheng-Chia Tseng (zerng07) wrote :

Using subset OTFs is suggested for OS exept MacOS and Windows by the README file from Source Han Sans (same as Noto Sans CJK).

However, as I stated previously, I believe using Super OTC is a way to find where the apps in Linux world which has some problems dealing with this "super font," and that helps shape a better Linux world in the future. People find the problem, report the problem, and the problem be fixed one day.

Both ways are fine though. The system still has some places to be improved to support Super OTC better while Subset OTFs require more space and more packages. To be the first to find the problems and work with upstreams to fix them? Or just do as the official recommendation to get the better result and serve users better first?

Any thoughts on this?

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-04-30 06:40, Cheng-Chia Tseng wrote:
> Using subset OTFs is suggested for OS exept MacOS and Windows by the
> README file from Source Han Sans (same as Noto Sans CJK).

According to the README.formats file, which is included in the fonts-noto-cjk source package, OTC "works" on recent versions of Mac and Linux but not Windows. So they don't seem to be identical.

> However, as I stated previously, I believe using Super OTC is a way
> to find where the apps in Linux world which has some problems dealing
> with this "super font," and that helps shape a better Linux world in
> the future. People find the problem, report the problem, and the
> problem be fixed one day.

Hmm.. I see now that you anticipated problems with "Super OTC" [1] long ago. At that time I hadn't a clue what you were talking about. :(

What you say is correct, but we shouldn't use the whole community of Ubuntu users as a test panel, should we?

> To be the first to find the problems and work with upstreams to fix
> them? Or just do as the official recommendation to get the better
> result and serve users better first?

Why not do both? I filed this ticket:
https://github.com/googlei18n/noto-cjk/issues/65

Hopefully it's the right place.

Can you possibly confirm that the PPA version of fonts-noto-cjk addresses the issues we have found up to now (at the expense of more disk space)?

[1] Super OTC is the font format installed with the version of
    fonts-noto-cjk which is currently in the Ubuntu archive.

tomoe_musashi (musashi) wrote :

@Gunnar, i can confirm that the PPA package addresses the Google Chrome issue.

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, tomoe_musashi. Did you try both without and with fonts-noto-cjk-extras?

tomoe_musashi (musashi) wrote :

@Gunnar, i tried both without and with fonts-noto-cjk-extras installed, and the patch addresses the chromium issue.

Cheng-Chia Tseng (zerng07) wrote :

Here is the screenshot within virtualbox, without extras.

Cheng-Chia Tseng (zerng07) wrote :

This is the screenshot within virtualbox, with extras.

They appeared to be the same, and the weight of the CJK characters is not the thin ones.

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, tomoe_musashi and Cheng-Chia Tseng. It confirms the conclusion from my rudimentary tests, and strengthens my belief that the proposed solution is a reasonable step to take.

Gunnar Hjalmarsson (gunnarhj) wrote :

Sorry to bother you again, but...

I tested to replace the single "super" OTC file with 7 weight specific OTC files, and it seems like this is sufficient to fix "the Thin issue" in Chrome/Chromium. So I have uploaded a simpler proposal to the PPA, without the additional fonts-noto-cjk-extras package.

I would of course appreciate if some could test it, to make sure I didn't overlook something.

https://launchpad.net/~gunnarhj/+archive/ubuntu/fonts-noto-cjk

(Please remember to uninstall the now obsolete, and possibly conflicting, fonts-noto-cjk-extras.)

tomoe_musashi (musashi) wrote :

I just tested the latest PPA and it fix the "Thin issue" in Chrome/Chromium, in a clean live mode of a virtual machine.
It's great that the package install all 7 weights with similar required disk space as the Super OTC one.

Cheng-Chia Tseng (zerng07) wrote :

This is what it looks like in virtualbox. It seems no problem with chrome when using the latest package as well.

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks again, tomoe_musashi and Cheng-Chia Tseng!

On 2016-05-03 18:49, tomoe_musashi wrote:
> It's great that the package install all 7 weights with similar
> required disk space as the Super OTC one.

Yeah, indeed. And it indicates that the bug resides in the "super" OTC file.

Yuan Chao (yuanchao) wrote :

On 2016-05-04, Gunnar Hjalmarsson (gunnarhj) wrote:
> Yeah, indeed. And it indicates that the bug resides in the "super" OTC file.
I thought the problem is on google-chrome as Firefox and other applications handles super OTC well?

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-05-08 11:23, Yuan Chao wrote:
> On 2016-05-04, Gunnar Hjalmarsson (gunnarhj) wrote:
>> Yeah, indeed. And it indicates that the bug resides in the "super"
>> OTC file.
>
> I thought the problem is on google-chrome as Firefox and other
> applications handles super OTC well?

What we found out is that Google's "super" OTC, unlike the other packaging formats which provide the very same Noto Sans CJK glyphs, doesn't work as expected with Google's web browser (or Chromium). So yeah, alternatively it may be Chrome/Chromium which are buggy.

tomoe_musashi (musashi) wrote :

Sorry to bother you again but there is a new update for the Noto CJK fonts.
Google and Adobe released the Serif fonts for CJK about several weeks ago
Noto Serif CJK:
http://www.google.com/get/noto/help/cjk/
It is a better serif font in consistency and glyph standard.
Ubuntu should seed the new Noto Serif CJK over the current

Gunnar Hjalmarsson (gunnarhj) wrote :

@tomoe_musashi: Can you please file a new bug about Noto Serif CJK instead of using this one which was closed long ago.

There is some related packaging discussion at Debian:

https://bugs.debian.org/862276

http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2017-May/thread.html#19499

I think it's wise to wait until we see the result of that discussion before we change anything in Ubuntu.

Displaying first 40 and last 40 comments. View all 134 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.