Strange behaviour of fontconfig priority for 'Lohit Devanagari'
Some days ago, I installed Lohit Devanagari font on my MX 19.3 box. Since then, I am experiencing strange behavior of fontconfig priority. I seen that Lohit Devanagari is set default for Devanagari script, but not all apps obeying this rule. Instead of Lohit Devanagari, buggy FreeSans font is being preferred, causing broken rendering of Devanagari. This issue is mainly affecting Chromium and Chromium based browsers.
The package fonts-lohit-deva has two config files -
/etc/fonts/conf.avail/59-lohit-devanagari.conf
/etc/fonts/conf.avail/66-lohit-devanagari.conf
In these files, the first one is just a family substitution rule. The second one is responsible for setting Lohit Devanagari as default font for Devanagari script. It has the following syntax -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match>
<test name="lang" compare="contains">
<string>hi</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>mr</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>kok</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>ks@devanagari</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sd@devanagari</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>mai</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>ne</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>brx</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>doi</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sa</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sat</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<alias>
<family>Lohit Devanagari</family>
<default>
<family>sans-serif</family>
</default>
</alias>
</fontconfig>
I couldn't figure out what causing this problem, because, even things are set correctly to use Lohit, unifont is preferred over it. I have previously used Ubuntu 20.04.1 & Arch. They have no such issue, and Lohit is correctly preferred. I checked Ubuntu and Arch fontconfig rules for any syntax changes but found that the code I am using is very similar to them...!
This issue seems to be affecting many Linux distros, because such problems have been discussed earlier on internet, especially for browsers.
Is it a bug ? Is it fixed previously in upstream ?
Edit - I have currently solved this problem by creating a local fonts.conf
file. But, it should not require to do so.