GNOME Bugzilla – Bug 780068
Spaces become boxed 0020 around powerline symbols
Last modified: 2018-05-22 13:22:30 UTC
If and only if Powerline fonts [1] are installed, certain space characters near powerline symbols are rendered as a boxed 0020 (the typical rendering when a glyph is missing) rather than a space. Please see the attached text file and screenshot. The text file contains nothing but spaces, English letters, and U+E0B0 characters (encoded in UTF-8). There's a trailing space in each row. The U+E0B0 glyph is a solid triangle in powerlined fonts. I'm on Ubuntu 16.10 Yakkety, gedit 3.22.0, and I install/uninstall the "fonts-powerline" package to trigger the bug. When it's not installed, a different glyph is shown for U+E0B0, and the spaces show up as spaces as expected. The bug is present no matter which font I pick in gedit's preferences out of the ones that are available on my system _and_ are mentioned in /etc/fonts/conf.avail/10-powerline-symbols.conf. The boxed 0020 numbers are obviously not okay, spaces should be shown. I _guess_ for some reason gedit (or fontconfig?) tries to take them from the powerline extension itself rather than falling back to the actual font. [1] https://github.com/powerline/fonts -- this patches some fonts at some private Unicode codepoints
Created attachment 347961 [details] Input file
Created attachment 347962 [details] Screenshot
If it's reproducible with pango-view, you should re-assign to pango.
Yup, pango-view --font="Monospace Regular 12" filename.txt produces the same broken output. This time on Ubuntu Artful beta, with pango 1.40.12. Reassigning.
Right. Pango assumes all fonts support space... We should fix this.
Even if all fonts supported space, I _guess_ the width of the space could be different in the overriding font than in the default one, so for a nice layout, it'd still be desirable to take it consistently from one.
Someone else can argue that if we use a fallback font, we should indeed use the space from that same font. That's the thinking behind current code.
Some spaces appear properly as spaces, while some others appear as boxed 0020's. To me this suggests that the current thinking is that spaces must be identical in the override font and in the fallback one, so it doesn't matter which one we take it from. Apparently the code pseudo-randomly takes it from one or the other. Why treat space specially? Can't it (at least the width) just be looked up exactly as any other glyph?
Pango does not change fonts for spaces. The heuristic can be improved indeed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/273.