GNOME Bugzilla – Bug 757785
spaces are half as long after a unicode symbol
Last modified: 2018-05-22 13:16:14 UTC
It seems that spaces are half-length after a unicode character until a non whitespace character appears. I'm using i3bar and the following appear to have the same length when displayed on my bar. A 1 A Using i3 version 4.11 (2015-09-30, branch "4.11") © 2009 Michael Stapelberg and contributors I posted this as a bug in i3 and received the response: I assume you are using a pango font? We only pass the string on to pango, pangocairo does all the rendering of the font. Please report the issue there.
Created attachment 323182 [details] Screenshot of gedit in Ubuntu 16.04 in a VM, overlaid by gedit, pango-view, and tea (a QT application) in the 14.04 host This issue is reproducible in any GTK application on my system and many others. As you know, the rendering system switches to a different font when it must render a character that's not in the existing font. The problem is AFAIK the fallback/new font's whitespace characters are used until a non-whitespace character is encountered. It should switch back to the requested font. The issue is obvious when the selected font is monospace, and the fallback characters come from a non-monospace font. The screenshot shows gedit in a 16.04-beta VM overlaid by gedit, pango-view and tea(a QT application) in the 14.04 host. All four applications are displaying the same text file. Only tea is rendering it near correctly. The third and fourth lines both contain seven 0x20 spaces, but are displayed with wildly different lengths in gedit and pango-view. The delta
Created attachment 323183 [details] Example text file used to create gedit_pango-view-gedit-tea.png Haha! Apparently bugzilla doesn't like me using unicode in the comments. The rest of my previous comment follows: comes from FreeSerif on my system, I assume that's the source of the space character width displayed. Ubuntu 14.04: $ gimp --version --verbose GNU Image Manipulation Program version 2.8.10 git-describe: GIMP_2_8_8-55-g9bb7eb0 using GEGL version 0.2.0 (compiled against version 0.2.0) using GLib version 2.40.2 (compiled against version 2.39.2) using GdkPixbuf version 2.30.7 (compiled against version 2.30.3) using GTK+ version 2.24.23 (compiled against version 2.24.22) using Pango version 1.36.3 (compiled against version 1.36.0) using Fontconfig version 2.11.0 (compiled against version 2.11.0) using Cairo version 1.13.1 (compiled against version 1.12.16) Ubuntu 16.04-Beta: $ gimp --version --verbose GNU Image Manipulation Program version 2.8.16 git-describe: GIMP_2_8_14-268-g3152b6e using GEGL version 0.3.4 (compiled against version 0.3.2) using GLib version 2.47.6 (compiled against version 2.47.3) using GdkPixbuf version 2.32.2 (compiled against version 2.32.2) using GTK+ version 2.24.29 (compiled against version 2.24.29) using Pango version 1.38.1 (compiled against version 1.38.1) using Fontconfig version 2.11.1 (compiled against version 2.11.1) using Cairo version 1.14.6 (compiled against version 1.14.4) Let me know if you need any other information.
The surrounding text influences what font gets used for the whitespace. I don't think there is a bug here.
Created attachment 323309 [details] Collage screenshots of Notepad and Notepad++ in Win10, TextEdit in OS X 10.10, and jEdit in Ubuntu 14.04 Win10, OS X, and Java all use consistent mono-spacing to display this file. Note: I had to add Windows-style line breaks to Notepad, but not Notepad++. A discussion may be warranted about how this should be handled, but is clearly at odds with every other font render system. I cannot expect extended unicode to be correctly formatted when displayed in a monospace font in GTK.
(In reply to Brad Erickson from comment #4) > Created attachment 323309 [details] > Collage screenshots of Notepad and Notepad++ in Win10, TextEdit in OS X > 10.10, and jEdit in Ubuntu 14.04 > > > Win10, OS X, and Java all use consistent mono-spacing to display this file. > Note: I had to add Windows-style line breaks to Notepad, but not Notepad++. > > A discussion may be warranted about how this should be handled, but is > clearly at odds with every other font render system. I cannot expect > extended unicode to be correctly formatted when displayed in a monospace > font in GTK. Correct. If your piecemeal fonts have differing metrics, which they seem to have in this case, you cannot expect them to be "correctly formatted".
That said, I think this case can be improved. The original intent of the code was to render space using the same font as its surrounding. 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 choose 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.
> If your piecemeal fonts have differing metrics, which they seem to have in this case, you cannot expect them to be "correctly formatted". Haha! That's why I made sure to provide a reasonable reproducible "out-of-the-box" example. A stock Fedora 22 install displays the example file using DejaVu Sans Mono, except the mathematical delta comes from FreeSerif. Your described solution would solve this issue perfectly. Thank you.
-- 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/249.