GNOME Bugzilla – Bug 435000
Bad rendering of line-drawing characters
Last modified: 2014-04-06 17:42:27 UTC
[ Forwarded http://bugs.debian.org/421320 ] "Since upgrading to gnome-terminal 2.18, line-drawing characters no longer line up correctly. They appear to overlap or not meet. Examples include the scrollbar in the lower half of an aptitude window, the boxes around aptitude menus and dialog boxes, the volume bars in alsamixer, or many other terminal applications."
Created attachment 87359 [details] screenshot of problem I can reproduce this, and I'm attaching a screenshot of the problem, showing xterm (on top) and gnome-terminal, both using DejaVu Sans Mono size 9. The volume bars in alsamixer does not seem to line up.
That is because of this commit: 2006-04-12 Behdad Esfahbod <behdad@gnome.org> Bug 149633 – gnome-terminal messes up boxdrawing chars aligment * src/vte.c: Try to use the font first for all graphic characters. This results in better looking graphics with modern fonts. Maybe we should revert it back for the line-drawing chars. (but not for other chars like Greek Pi).
Created attachment 93558 [details] [review] proposed patch The attached patch fixes the rendering of line-drawing characters for me. The patch is against a version of vte as packaged in Debian (0.16.6-1). I originally posted this patch to the Debian bug-tracking system (http://bugs.debian.org/421320).
Ping? Any chance of the patch above being included in the official vte? Or some other fix for this problem? Each time the vte library is upgraded on my system, I have to go back and compile a new version with my patch included. I've been using it for months now with no issues, and it fixes a (for me) very visible problem. If the patch isn't acceptable for some reason, please let me know why and I'll see if I can fix it.
Why only those characters and not the full box-drawing set?
Sorry for the slow response. The original vte code was able to draw a limited set of characters, including some line-drawing characters (but not the full set) and some other assorted characters. This custom code for drawing these characters was not used if the font already included the appropriate glyph. My patch forced this built-in drawing of all the line-drawing characters for which there was already support, but I didn't try to add support for the remaining line-drawing characters. The ones already supported already covered everything in my day-to-day use (primarily, line-drawing chracters needed for mutt's threaded message display). I later discovered that installing the DejaVu fonts improved the situation markedly (previously, I believe I was using the original Bitstream Vera fonts). With the font change, line-drawing characters line up much better--not perfectly, but close enough in most cases. The main visible problem is now with U+2592 (checkerboard-filled rectangle), as shown in the earlier screenshot. At the very least, I think it is useful to do our own rendering of U+2592 and maybe U+25AE. Whether to draw the line-drawing characters ourselves depends on whether it is better to improve the rendering of these characters (marginally) at the cost of consistency with the unimplemented line-drawing characters, or whether it is worth it to add support for the currently-unimplemented characters.
I can suggest one alternative which also appears to fix the problem. The bad rendering of line-drawing characters seems to come from anti-aliasing them. If I turn off all anti-aliasing in the system-wide Appearance preferences, the line-drawing characters look perfect, though everything else looks terrible. :) So, if you turn off anti-aliasing when rendering line-drawing characters, they should look correct again.
Can you test with vte trunk? We've switched over to pangocairo backend, so it may as well have been fixed by that.
The problem still exists with vte 0.20.1 (Debian package version 1:0.20.1-1), which seems to use pango.
Created attachment 135291 [details] Screenshot of gnome-terminal with vte 0.20.1, demonstrating problem with line-drawing characters
Ping?
Re-ping? Bug still exists with gnome-terminal 2.28.2 and libvte 0.22.5.
Ping? Any news on this? vte 0.30.1 still display bad rendering of line-drawing characters. Someone have a workaround?
No one working on it AFAIK.
BTW, this is problematic when showing stuff like QR codes in a terminal using Unicode box drawing chars, like for example here: https://plus.google.com/u/0/115547683951727699051/posts/g1E6AxVKtyc
Behdad: can you give me a hint what you think is the correct solution here: - something like the attached patch, where we special-case those symbols, - use a fixed font for these that we know works correctly, - something with pango renderers? - something else? Also, I agree we shouldn't just do this for a few characters here and there but probably for the full blocks: 2500..257F; Box Drawing 2580..259F; Block Elements currently we also specialcase parts of 2400..243F; Control Pictures but I'm not sure that's required anymore. Also, in case we do want to draw these symbols ourself, should we still be using vtedraw through vte_terminal_draw_rectangle/line or can we just use cairo directly?
If we end up drawing ourselves, cairo directly... I was thinking that maybe using a tight font ascent/descent would fix this. Probably would look too tight though.
Fixed on 0-34 and next.
a developer should mark this fixed, which I can confirm
It'll be closed once vte-next lands on master.