For years OpenWeather has been my favorite GNOME extension for quick and beautiful weather information. However today when I looked at my top bar again for weather, I had the impression as if something is missing:
And this is what it used to be like:
My degree Celsius symbol is missing!
The first thing I thought was, is this specific to OpenWeather? And I was surprised to find out that when I googled “degree Celsius symbol”, the
U+00B0 ° degree sign plus
U+0043 C latin capital letter c is present, while ℃ as
U+2103 ℃ degree celsius is simply empty. However a
font-family: serif on Wikipedia showed the symbol correctly, so this must be a font/fontconfig issue.
lessed my own fontconfig configuration with
So the different order of font families in
serif might be the issue. I googled a while for finding out the font selected by
fontconfig for a glyph, and found an article suggesting the use of
FC_DEBUG=4 pango-view -q --font='<YOUR_FONT_FAMILY>' -t '<YOUR_CHARACTER>' 2>&1 | grep -o 'family:"[^"]+' | cut -c 10- | tail -n 1
The latter part basically filters out the last printed family name from the tedious debug output. And when I run this for my degree Celsius symbol (
℃), I found:
What’s wrong with
WenQuanYi Micro Hei? I’ve been using it for years, and now it’s giving me nothing for degree Celsius symbol? And why did fontconfig ever choose it seemed to have no such glyph?
Confused by this I opened my
wqy-microhei.ttc with FontForge, and was again surprised to find out that my
WenQuanYi Micro Hei is providing an empty glyph (instead of nothing) for certain codepoints!
This is crazy, and I’m left wondering how my degree Celsius symbol ever worked in the past few years.
There must be some configuration that allow me to blacklist certain glyphs in a font. And after another round of digging around, I found some interesting results.
The first one is a bug on fontconfig Bugzilla which requested such support back in 2006 and was marked fixed in 2011. Feeling excited, I scrolled down and found a single line of comment from the dev:
This is fixed in master with target=scan charset editing.
After all the hard work, why didn’t he or she celebrate the moment of closing this bug with a more detailed explanation, or at least a helpful pointer? Even after reading though
man fonts-conf, I found nothing describing how I can edit the charset of a font family. After all, the
<charset> element says it must contain one or more integer, however the whole charset normally contains a huge amount of hexadecimal integers.
So I searched harder and found another answer on StackOverflow. It suggested an undocumented way of configuration that’s mentioned somewhere in a RedHat bug thread, which was its only appearance on the whole Internet:
This is just what i wanted! So I happily applied this to my mischievous
WenQuanYi Micro Hei, changing the
"eq" and setting the range to include
0x2103 (My precious degree Celsius symbol). Finally,
sudo fc-cache -f && fc-cache -f! [sigh of relief]
This could have worked, in some time of the history, but is not working for now, on my latest Arch Linux installation.
But wait. I did saw something mentioning, we have a
<charset> element and it must contain some integers? So I started to coin my own solution (You should also do the same for
WenQuanYi Micro Hei Mono):
sudo fc-cache -f && fc-cache -f,
pango-view again to confirm, and
Alt+F2 r to restart my GNOME shell. It worked! After all these hours, my degree Celsius symbol is back and alive again!
The above solution is only a workaround, and to actually fix this, The
Wenquanyi Micro Hei font itself should be patched. In fact this was what I first tried when I surprisingly found out those empty glyphs.
However, when I went to wenq.org, there latest update was posted in late 2011 (We are in 2018 now), and their forum is giving me a blank page with certain resources returning 404. Their SourceForge issue tracker is also unattended for years with that notorious hangul advance bug still open. Sadly, the whole project seems dead. So I decided to work around instead of fixing this.
And one sentence I encountered during my search kept lingering in my mind:
When you gaze long into fontconfig, fontconfig also gazes into you.
Update: With another link on their official website, I was able to find their real bug tracker and this bug, and a similar bug. The dev said it’s fixed, but maybe some recent
freetype changes brought it back. Maybe some day I should fork it and try to actually fix these bugs.
And according to the dev’s comment, those glyphs existed in
Droid Sans Fallback, so a proper fix to my configuration should also include adding
Droid Sans Fallback to the
monospace families, right below the
WenQuanYi Micro Hei entry.