New issue
Advanced search Search tips

Issue 610289 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Fontconfig fallbacks ignored for missing glyphs

Reported by ter...@gmail.com, May 9 2016

Issue description

Chrome Version       : 50.0.2661.94
URLs (if applicable) : http://jsbin.com/towazexetu/edit?html,output
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari:
    Firefox: OK
         IE:

What steps will reproduce the problem?
(1) Configure your fontconfig with a set of fallbacks, e.g.:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<alias>
    <family>serif</family>
    <prefer>
        <family>Merriweather</family>
        <family>cwTeXMing</family>
        <family>Symbola</family>
    </prefer>
</alias>
<alias>
	<family>sans-serif</family>
	<prefer>
		<family>Merriweather Sans</family>
		<family>Source Han Sans CN</family>
		<family>Symbola</family>
	</prefer>
</alias>
</fontconfig>
(2) Visit the URL: http://jsbin.com/towazexetu/edit?html,output

What is the expected result?
The glyphs not found for the serif font Merriweather should fallback to cwTeXMing and eventually Symbola.

What happens instead?
If a glyph is not found in Merriweather it takes another route and ends up fallbacking to Source Han Sans CN.

So basically it assumes the font cannot be used an continues in the list of font-families as soon as a glyph is not found, instead of going through all the fonts according to the fontconfig. I have tried putting a font after serif that has the glyph and then it will use that one. I assumes that the browser fall backs to sans-serif if no font-family matches and that is how it ends up matching the Source Han Sans CN.

 
chromium.png
11.6 KB View Download
firefox.png
15.4 KB View Download
Components: Blink>Fonts
Labels: Needs-Feedback
Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.4 using chrome version 50.0.2661.102 and canary 52.0.2735.0 .Not able to find difference when compared with firefox.
Please find the attached screen shot for the same.

Request you please try the issue by upgrading chrome to latest stable version and update the thread if the issue still persists.

thanks,
610289.png
239 KB View Download

Comment 2 by ter...@gmail.com, May 14 2016

I have upgraded to the latest version and the problem still persists.

I am running Archlinux.

In your screenshot you managed to reproduce the issue , as you can see in the window in the behind, the chinese font is different and correct.

While in the front window it is using the Han Sans.
Project Member

Comment 3 by sheriffbot@chromium.org, May 14 2016

Labels: -Needs-Feedback Needs-Review
Owner: kavvaru@chromium.org
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by e...@chromium.org, May 17 2016

Labels: OS-Linux
Status: Available (was: Unconfirmed)
Labels: ArchLinux
Owner: ----

Comment 7 by cda...@chromium.org, Mar 13 2017

Labels: -Needs-Review
Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919
Project Member

Comment 8 by sheriffbot@chromium.org, Apr 13 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by e...@chromium.org, Apr 18 2018

Status: Available (was: Untriaged)

Sign in to add a comment