Bug 2063714

Summary:	serif:lang=ja falls back to Droid Sans instead of Noto Sans CJK JP
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	google-noto-fonts	Assignee:	Akira TAGOH <tagoh>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	ajax, caillon+fedoraproject, fonts-bugs, gnome-sig, i18n-bugs, mclasen, petersen, pnemade, psatpute, pwu, rhughes, rstrode, sandmann, tagoh
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	google-noto-fonts-20201206^1.git0c78c8329-9.fc38	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-07 07:23:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.