Droid Sans no longer preferred font for Chinese

Bug #1335482 reported by Gunnar Hjalmarsson
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
language-selector (Ubuntu)
Fix Released
High
Gunnar Hjalmarsson
Trusty
Fix Released
High
Gunnar Hjalmarsson

Bug Description

[Impact]

In the 69-language-selector-zh-??.conf files we try to make Droid Sans the preferred font in case of a Chinese locale. However, suddenly this seems to not work any longer. The number of affected users is significant.

[Test Case]

How to reproduce:

$ sudo locale-gen zh_CN.UTF-8
$ LANG=zh_CN.UTF-8 fc-match 'sans-serif'

After the change, the response is the expected

DroidSansFallbackFull.ttf: "Droid Sans" "Regular"

Before the change, the response is something else.

[Regression Potential]

This makes the intended (and previously working) behaviour effective. No undesired side effects identified.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Changing this in utopic, but would want some feedback before possibly proceeding with trusty.

Changed in language-selector (Ubuntu Trusty):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
language-selector (0.132) utopic; urgency=low

  * fontconfig/69-language-selector-zh-??.conf:
    Replace "Droid Sans Fallback" with "Droid Sans" (LP: #1335482).
 -- Gunnar Hjalmarsson <email address hidden> Tue, 01 Jul 2014 15:41:00 +0200

Changed in language-selector (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Aron Xu (happyaron) wrote :

I confirm this affects Trusty, recommend to SRU.

Changed in language-selector (Ubuntu Trusty):
importance: Undecided → High
status: Incomplete → Confirmed
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks, Aron. It's in the queue now.

Changed in language-selector (Ubuntu Trusty):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
status: Confirmed → In Progress
description: updated
Revision history for this message
Colin Watson (cjwatson) wrote : Please test proposed package

Hello Gunnar, or anyone else affected,

Accepted language-selector into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/language-selector/0.129.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in language-selector (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

I have successfully installed and run language-selector-common 0.129.2 from trusty-proposed, and could with that verify the changed behaviour as described in the test case.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
language-selector (0.129.2) trusty-proposed; urgency=low

  * fontconfig/69-language-selector-zh-??.conf:
    Replace "Droid Sans Fallback" with "Droid Sans" (LP: #1335482).
 -- Gunnar Hjalmarsson <email address hidden> Sun, 06 Jul 2014 21:49:00 +0200

Changed in language-selector (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Adam Conrad (adconrad) wrote : Update Released

The verification of the Stable Release Update for language-selector has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Cheng-Chia Tseng (zerng07) wrote :

Hi Gunnar,

I just installed ubuntu 14.04.1 today. :)

However, in my system, the output of the fc-match is

$ LANG=zh_TW.UTF-8 fc-match 'sans-serif'
DroidSans.ttf: "Droid Sans" "Regular"

and the sorted matching font list is
$ LANG=zh_TW.UTF-8 fc-match -s 'sans-serif'
DroidSans.ttf: "Droid Sans" "Regular"
uming.ttc: "AR PL UMing TW" "Light"
uming.ttc: "AR PL UMing HK" "Light"
ukai.ttc: "AR PL UKai TW" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
Waree.ttf: "Waree" "Book"
DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular"

And you can see Droid Sans Fallback is far away from Droid Sans, so the CJK characters of sans-serif style will display as AR PL UMing which is a serif style font. Any edit to font family name of "Droid Sans Fallback" won't make it become real "Droid Sans". They are still two instances.

If we DO want to use "Droid Sans" instead of "Droid Sans Fallback" here. The only way is to bind them together to make them as one font.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Can't reproduce on an updated 14.04.

$ dpkg-query -W language-selector-common fonts-droid
fonts-droid 1:4.3-3ubuntu1
language-selector-common 0.129.2
$ LANG=zh_TW.UTF-8 fc-match -a 'sans-serif' | head -n 20
DroidSansFallbackFull.ttf: "Droid Sans" "Regular"
DroidSans.ttf: "Droid Sans" "Regular"
DroidNaskh-Regular.ttf: "Droid Sans" "Regular"
DroidSansEthiopic-Regular.ttf: "Droid Sans" "Regular"
DroidSansHebrew-Regular.ttf: "Droid Sans" "Regular"
DroidSansThai.ttf: "Droid Sans" "Regular"
DroidSansArmenian.ttf: "Droid Sans" "Regular"
DroidSansGeorgian.ttf: "Droid Sans" "Regular"
DroidSansJapanese.ttf: "Droid Sans" "Regular"
DroidSansHebrew-Bold.ttf: "Droid Sans" "Bold"
DroidSans-Bold.ttf: "Droid Sans" "Bold"
DroidNaskh-Bold.ttf: "Droid Sans" "Bold"
DroidSansEthiopic-Bold.ttf: "Droid Sans" "Bold"
uming.ttc: "AR PL UMing TW" "Light"
uming.ttc: "AR PL UMing HK" "Light"
ukai.ttc: "AR PL UKai TW" "Book"
ukai.ttc: "AR PL UKai HK" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSansCondensed.ttf: "DejaVu Sans" "Condensed"

On 2014-07-30 13:58, Cheng-Chia Tseng wrote:> Any edit to font family name of "Droid Sans Fallback" won't make it
> become real "Droid Sans". They are still two instances.
>
> If we DO want to use "Droid Sans" instead of "Droid Sans Fallback" here.
> The only way is to bind them together to make them as one font.

Well, the whole idea is to get DroidSansFallbackFull.ttf to the top of the list, and the reason why I changed it is that the "Droid Sans Fallback" strings in the 69-language-selector-zh-??.conf files were ignored.

Do you possibly have own fontconfig configuration files that might affect this?

Revision history for this message
Cheng-Chia Tseng (zerng07) wrote :

No, I don't have any other fontconfig configuration files because this is a fresh installation and a new user. I have enabled all updates-repo and done 'apt-get upgrade'.

That's strange we don't have the same results!

Revision history for this message
Cheng-Chia Tseng (zerng07) wrote :

However, if I change "Droid Sans" to "Droid Sans Fallback", and I can get sas-serif as "Droid Sans Fallback" although it is still different from yours.

$ LANG=zh_TW.UTF-8 fc-match -a 'sans-serif' | head -n 20
DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular"
uming.ttc: "AR PL UMing TW" "Light"
uming.ttc: "AR PL UMing HK" "Light"
ukai.ttc: "AR PL UKai TW" "Book"
ukai.ttc: "AR PL UKai HK" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
n019003l.pfb: "Nimbus Sans L" "Regular"
n019043l.pfb: "Nimbus Sans L" "Regular Condensed"
n019004l.pfb: "Nimbus Sans L" "Bold"
n019044l.pfb: "Nimbus Sans L" "Bold Condensed"
n019023l.pfb: "Nimbus Sans L" "Regular Italic"
n019063l.pfb: "Nimbus Sans L" "Regular Condensed Italic"
n019024l.pfb: "Nimbus Sans L" "Bold Italic"
n019064l.pfb: "Nimbus Sans L" "Bold Condensed Italic"
Waree.ttf: "Waree" "Book"
Waree-Bold.ttf: "Waree" "Bold"
Waree-Oblique.ttf: "Waree" "Oblique"
Waree-BoldOblique.ttf: "Waree" "BoldOblique"
Loma.ttf: "Loma" "Book"

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Yeah, this is strange. When I first changed to "Droid Sans Fallback" in 69-language-selector-zh-tw.conf, I got this:

$ LANG=zh_TW.UTF-8 fc-match -s 'sans-serif' | head -n 20
uming.ttc: "AR PL UMing TW" "Light"
uming.ttc: "AR PL UMing HK" "Light"
ukai.ttc: "AR PL UKai TW" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
Verdana.ttf: "Verdana" "Normal"
Arial.ttf: "Arial" "Normal"
Waree.ttf: "Waree" "Book"
DroidNaskh-Regular.ttf: "Droid Sans" "Regular"
DroidSansEthiopic-Regular.ttf: "Droid Sans" "Regular"
DroidSansHebrew-Regular.ttf: "Droid Sans" "Regular"
DroidSansJapanese.ttf: "Droid Sans" "Regular"
DroidSansFallbackFull.ttf: "Droid Sans" "Regular"
ukai.ttc: "AR PL UKai CN" "Book"
uming.ttc: "AR PL UMing CN" "Light"
NotoSansDevanagari-Regular.ttf: "Noto Sans Devanagari" "Regular"
KhmerOS.ttf: "Khmer OS" "Regular"
MuktiNarrow.ttf: "Mukti Narrow" "Regular"

I.e. fontconfig seemed to not understand at all.

Then, after I had changed things back and forth when working with bug #1351092, suddenly I was able to reproduce the behaviour you describe! Now I fear that the fix of this bug report was a mistake. :(

I suggest that we leave this bug report, and continue talking at bug #1351092. Your comments on the idea there would be much appreciated.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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