Comment 13 for bug 1335482

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.