Pango Unicode Characters -- Rendering Errors

[53hornet]

Greetings. I have been trying to configure a few of my applications (namely x11/rofi and x11-wm/i3-gaps) with an icon font called Material Design Icons Desktop. It's a font made up of numerous Unicode glyphs, similar to Font Awesome. The problem is those glyphs render with these strange "Unicode error" boxes next to them.



The applications in question all use pango to render this font. I was able to determine this by doing a little digging in the make build-depends-list for rofi and i3-wm and they both turn up x11-toolkits/pango. This is what their configuration is set to use to select the icon font. Combine that with the fact that other apps that don't require it render these glyphs fine and this is why I initially suspect it.

Now I did some reading in these forums and learned about something I hadn't before: my locale configuration. I made some changes and ensured that all of them were set to U.S. English, UTF-8, so I was able to rule that out. I also read on these forums about making sure my font-config is set correctly, but from what I've read I don't think the font-config gets used when you set the font by name ("Material Design Icons Desktop"). I also ensured that the font was loaded properly with fc-list (just to be sure) and it is there.

I would like to know where I should take a look next, or if there is further reading that I've missed that might help me find the answer. Thank you for considering my question.

 

[memreflect]

Pango wants to render the glyph for U+0020 (space/blank) using that font, but it can't find one, so it displays that box with the Unicode code point instead. Your problem isn't pango; it's the font.

 

[ralphbsz]

The "Material Design Icons" font that is distributed for web pages is not a "normal" font, in the sense that it does not contain the normal ASCII or Unicode characters. Instead, it contains icons, which are intended to be used in an application. For example, I see in your example that you are using the battery symbols; those are the kind of icons that it might contain. Do see what icons it contains, go to the web page for Material Design at material.io, click on the icons page, and start looking around.

You are trying to use that font to display normal text. As memreflect says, that runs into problems with spaces, but it is also not the intent of that font. Use it only for the icons it provides.

Now, I happen to only know how to use the Material Design Icons in html pages. How to use them with the Cairo, Pango or GTK libraries: no idea. I'm not a graphics or GUI person.

 

[53hornet]

Good ideas from both of you. I am aware that this is a web font that may not contain the regular ASCII set for example, however the one I'm using is distributed as a TTF by the creators (hence the "desktop" name). To handle regular Latin characters and punctuation I am using pango font fallbacks (Iosevka is handling those characters just fine). On another machine for example, this setup works, where I can specify two fonts for Pango to display with pango: Iosevka Etoile, Material Design Icons Desktop 12, with the icon font as a fallback if the unicode characters aren't found by the monospace font. That's the same config I am using here, which I should have specified in my original post. Is the problem still not with pango and the font itself if the font itself can be used in conjunction with others on other installations?

Thanks for the tip on the U+0020 code, that didn't even register in my mind.

 

[53hornet]

I did a little more digging after mulling over the botched ASCII space character. I found some issues from similar users of this icon font (as well as other emoji/icon fonts) with space characters between Unicode characters and plain ASCII text. It appears this is a known issue that was fixed in upstream Pango versions. Below is an excerpt from Pango's CHANGELOG. It looks to indicate that it was fixed in the early 1.44 releases, while x11-toolkits/pango is still using 1.42.4_3. Note the lines about "Emoji spacing" and "Don't render hex boxes for space". This makes me a little hopeful that all I would need to do is upgrade Pango (and possibly Cairo) in order to resolve this issue.

Overview of changes in 1.44.1
=============================
- ...
- Fix Emoji spacing
- ...

Overview of changes in 1.44.0
=============================
- ...
- cairo: Don't render hex boxes for space
- ...

I am also hopeful that I found the source of the issue after reading a comment (below) from a Pango developer on the subject of the Emoji One Color font doing the same thing.

If font before and after space are both the same and they support space, then we should use that. However, if the font used for before and after are different, then currently we chose the one used for before. However, we should use the one between before/after that has a higher priority. Fixing that will fix this case.

I'm not sure how to go about submitting a request to upgrade the port to align more closely with upstream Pango (or build it from scratch) but I'll look into those soon.