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!
Finding the culprit
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 °C
as 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 <span>
with font-family: serif
on Wikipedia showed the symbol correctly, so this must be a font/fontconfig issue.
And I less
ed my own fontconfig configuration with /etc/fonts/local.conf
:
1 |
|
So the different order of font families in sans-serif
and 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
and pango-view
:
1 | 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.
Finding the way to fix it
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:
1 | <match target="scan"> |
This is just what i wanted! So I happily applied this to my mischievous WenQuanYi Micro Hei
, changing the compare
to "eq"
and setting the range to include 0x2103
(My precious degree Celsius symbol). Finally, sudo fc-cache -f && fc-cache -f
! [sigh of relief]
Nope.
This could have worked, in some time of the history, but is not working for now, on my latest Arch Linux installation.
No.
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
):
1 | <match target="scan"> |
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!
A final note
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 fontconfig
or 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 sans-serif
and monospace
families, right below the WenQuanYi Micro Hei
entry.