Bug 2063714 - serif:lang=ja falls back to Droid Sans instead of Noto Sans CJK JP
Summary: serif:lang=ja falls back to Droid Sans instead of Noto Sans CJK JP
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: google-noto-fonts
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-14 08:32 UTC by Jens Petersen
Modified: 2023-08-07 07:23 UTC (History)
14 users (show)

Fixed In Version: google-noto-fonts-20201206^1.git0c78c8329-9.fc38
Clone Of:
Environment:
Last Closed: 2023-08-07 07:23:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2022-03-14 08:32:12 UTC
Description of problem:
In Fedora 36 when google-noto-serif-cjk-ttc-fonts is not installed
fontconfig seems to fall back to google-droid-sans-fonts
rather than google-noto-sans-cjk-ttc-fonts.

This might be related to/caused by bug 517789?

How reproducible:
100%

Steps to Reproduce:
1. boot Fedora Live image
2. fc-match serif:lang=ja

Actual results:
2. DroidSansJapanese.ttf: "Droid Sans" "Regular"

Expected results:
2. NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"

Additional info:
I get the same result with your older copr repo applied F35 fwiw.

Comment 1 Akira TAGOH 2022-03-16 11:58:34 UTC
First, no, this isn't related to Bug#517789. fontconfig is trying to estimate the score from the various properties provided by font caches. what fonts are the best font according to the request is depending on what a sort of fonts installed. strictly speaking, it is reproducible but it isn't that easy to predict which one it would be.
Usually we add a substitute rule to make it predictable. it is mostly obvious from the order of the family names. However, in this case, if no serif fonts is installed, it will be decided by other properties. thus, it doesn't care what fonts are default for sans-serif, and it could says this behavior isn't a bug.

One thing we can make it better is to add sans-serif at the end of family name list as a last resort. that may looks like (not tested):

<fontconfig>
  <match>
    <test name="family">
      <string>serif</string>
    </test>
    <edit name="family" mode="append_last">
      <string>sans-serif</string>
    </edit>
  </match>
</fontconfig>

Note the position of this config. it must be proceeded prior to other config which interacts with "sans-serif". This would gives you Noto Sans related family instead of DejaVu Sans. though adding different typefaces as a fallback sounds not a good idea.

Comment 2 Jens Petersen 2022-03-22 06:40:20 UTC
Thanks for the detailed analysis, Akira

Comment 3 Akira TAGOH 2022-12-20 09:43:01 UTC
This should be fixed in google-noto-fonts-20201206^1.git0c78c8329-9.fc38

Comment 4 Jens Petersen 2022-12-20 10:32:32 UTC
I tested the build and it LGTM now, thanks!

Comment 5 Akira TAGOH 2023-08-07 07:23:37 UTC
Unfortunately there are no plans to backport this change for some reasons. This has been fixed in f38 and f37 is going to be EOL. so closing this.


Note You need to log in before you can comment on or make changes to this bug.