GNOME Bugzilla – Bug 54926
Should try bold version of font before pseudo-bolding
Last modified: 2009-02-12 05:33:49 UTC
gnome-terminal doesn't attempt to use the bold version of the terminal font to indicate bold on the console. It simply repaints the same unbolded font offset by one pixel, which results in making the bold sections of the console unreadable when using certain fonts that don't lend themselves to this sort of "pseudo-bolding" (for instance, when glyphs contain a lot of 1-pixel spaces and those get covered up in pseudo-bolding). These fonts already have a bold version, and that version should be used before trying pseudo-bolding. gnome-terminal should only fall back to pseudo-bolding if a bold version of the selected font is unavailable.
libzvt issue
This may be fixable on the gnome-terminal level as well, gnome-terminal could pass in a bold font, using the information from the font selector.
Any progress on this? Move to libzvt or gnome-terminal or both?
Main problem with trying bold fonts first is that they typically have wider glyphs and wider metrics, so creeping them into the cell array may make them look /very/ bad.
Does that apply to monospaced fonts? For an example, bold Consolas looks great in XTerm.
(In reply to comment #5) > Does that apply to monospaced fonts? It does. There was this bug about that, in the context of syntax highlighting (using bold faces) in gedit with monospaced fonts. > For an example, bold Consolas looks great in XTerm. That's probably a bitmap font.
> > Does that apply to monospaced fonts? > > It does. There was this bug about that, in the context of syntax > highlighting (using bold faces) in gedit with monospaced fonts. Ah. I'll dig that up then. > > For an example, bold Consolas looks great in XTerm. > > That's probably a bitmap font. No, it's purely vector. It's MS's monospace font for Vista. I'd give a link but I don't know about the legality. Thanks for your replies.
xterm has a separate bold font and uses char_width=MAX(normal, bold).
I've implemented bold font handling. It required a certain level of refactoring, so I've split up the patches: vte-xft-locking-with-font.patch - xft: move font locking into the font struct vte-xft-bold-font-selection.patch - xft: perform bold font choosing vte-has_bold_font.patch - core: add "has_bold_font" logic vte-choose-bold.patch - core: request bold font when available vte-xft-draw-bold.patch - xft: draw with bold font when bold requested
Created attachment 113185 [details] [review] vte-xft-locking-with-font.patch
Created attachment 113186 [details] [review] vte-xft-bold-font-selection.patch
Created attachment 113187 [details] [review] vte-has_bold_font.patch
Created attachment 113188 [details] [review] vte-choose-bold.patch
Created attachment 113189 [details] [review] vte-xft-draw-bold.patch
Hmmm. Something is wrong with the font locking change. I'm seeing crashes, but haven't narrowed down the cause yet. It's crashing here, with a NULL deref, so I assume I wrecked the array management somehow:
+ Trace 201080
I'll keep digging -- maybe I shouldn't have refactored it to begin with :)
Steps to reproduce: 1) close all gnome-terminals 2) open one, then another 3) close the latter one 4) type into the first -- crash At a glance, I think this is due to _vte_xft_get_char_width needing to check both the normal and bold font sizes and the locked font arrays aren't fully initialized.
Created attachment 113214 [details] [review] vte-xft-locked-font-fixes.patch This seems to fix the crashes I was seeing before. At the very least, they are memory leak clean ups from the original refactoring of the font locking code.
Tried Kees' patches and they work well for me. vte is stable and my fixed width font is bolded rather than pseudo-bolded.
Should be fixed in more than just Xft. Chris, feel like hacking on this?
It certainly should be fixed in more than just Xft. I didn't want to do too much more work on this problem unless it's approach was going to be "approved". Since the framework allows for other backends to declare that they don't support real bolding, the patches as-they-are should work for now.
For note, Ubuntu is shipping with this patch to VTE: https://launchpad.net/ubuntu/+source/vte http://launchpadlibrarian.net/16310046/vte_1%3A0.16.14-1ubuntu1_1%3A0.16.14-1ubuntu2.diff.gz
Setting patch statuses; the xft backend is gone on trunk.
Created attachment 123225 [details] [review] support bold fonts Here is the patch reworked for the pangocairo backend. Note that I haven't tested this yet, but I wanted to get something into the tracker so this bug doesn't continue to age. :)
This patch causes problems with some fonts. See bug #567856
This may be hard to test without the actual font. I wouldn't expect this patch to break fonts without a bold face (it explicitly uses the non-bold bold when the bold font isn't available -- the old behavior).
I removed the patch from the Ubuntu package and it’s back to normal. Dunno.
(In reply to comment #25) > This may be hard to test without the actual font. I wouldn't expect this patch > to break fonts without a bold face (it explicitly uses the non-bold bold when > the bold font isn't available -- the old behavior). This is why: + *width = MAX(data->font->width, data->font_bold->width);
If the fonts are the same (neither bold), why would this be any different?
e.g.: $ fc-match 'Sans' DejaVuSans.ttf: "DejaVu Sans" "Book" $ fc-match 'Sans:style=Bold' DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold" $ fc-match 'Pragmata' pragmata.ttf: "Pragmata" "Medium" $ fc-match 'Pragmata:style=Bold' pragmata.ttf: "Pragmata" "Medium"
You get the same font indeed, but with FreeType pseudo-bolding, which increases the font width.
Isn't it quite likely that whether the bolding is freetype's pseudo-bolding, or use of a separate bold font, that it will be wider? (and for that matter, shouldn't the current double-stamping method make it wider too?) Could the kerning/tracking of the bold font be reduced to compensate? The current upstream method of bolding can make fonts illegible below a certain size, so one has to wonder if trading off the spacing for legibility is the better compromise.
Created attachment 127339 [details] [review] support bold fonts and double-strike I realize I had dropped the double-strike completely, which isn't appropriate. This patch restores the double-strike behavior when there is no bold font available. Behdad: how can we detect the FT pseudo-bolding of a font and either get rid of it in favor of the old-style double-strike, or compensate in some other way?
I think the way this should work is: 1. Decide whether to use a bold font or double-strike 2. Do that. Step 1 happens like this: - If the computed cell width of the bold font is more than 110% of the width of the normal font, use double-strike, otherwise use the bold font. In any case, use the width of the normal font as the cell width regardless. Now, there's also this factor that we may want to use in our decision-making process: - If the family name of the normal and the bold fonts is not the same, use the double-strike. behdad
Created attachment 128428 [details] [review] selective font bolding with fallback to double-strike This patch disregards bold fonts that exceed a 10% difference in cell width, causing a fallback to double-strike mode. Tests show it falling back correctly for the commercial font that lacked a bold face, and correctly using a bold face for fonts that support one. e.g.: (gnome-terminal:24091): Vte-WARNING **: bold font too wide (12 not within 10% of normal width 10), falling back to double-strike
Thanks for the update. A few points before it can go in: - No warning please. - In a few places you pass FALSE for the bold parameter. It should really come from the real cell being drawn. It's plain wrong otherwise. - I like to see the double-strike moved to the pangocairo layer. Thanks behdad
Created attachment 128514 [details] [review] selective font bolding with fallback to double-strike - warning in vteskel.c eliminated (if there are others, I could not find them; please advise). - the FALSE passed for the bold parameters comes from the graphics-drawing code; I did not see any bold attribute associated with those actions, so I used "FALSE" (which also match the original behavior, which had no knowledge of bold for those actions). I am open to suggestions for handling it in a different way. - I disagree about the location of double-strike: it needs to be done by the top-level vte for backends that don't support it (yes, there is only one currently, but it is a generally useful routine to keep at the top-level, as it was originally). This is why the vte backend gained the has_bold() capability to report up the chain.
(In reply to comment #36) > Created an attachment (id=128514) [edit] > selective font bolding with fallback to double-strike Thanks. > - warning in vteskel.c eliminated (if there are others, I could not find them; > please advise). > > - the FALSE passed for the bold parameters comes from the graphics-drawing > code; I did not see any bold attribute associated with those actions, so I used > "FALSE" (which also match the original behavior, which had no knowledge of bold > for those actions). I am open to suggestions for handling it in a different > way. Well, in the original code it didn't matter as the "bold" variant and normal font had the same coverage. It's not necessarily true anymore. You need to add a "bold" parameter to the functions that are calling with FALSE now and pass the proper cell attribute to those functions. > - I disagree about the location of double-strike: it needs to be done by the > top-level vte for backends that don't support it (yes, there is only one > currently, but it is a generally useful routine to keep at the top-level, as it > was originally). This is why the vte backend gained the has_bold() capability > to report up the chain. Well, doesn't matter that much, but for the sake of abstraction it should be moved to vtedraw for the least. It's not the widget's business really. We're actually very close to removing the vtedraw abstraction and hardcode the single backend at hand. With these addressed, I'll go ahead and commit the patch :). Thanks again, behdad
Created attachment 128527 [details] [review] selective font bolding with fallback to double-strike This passes bold information from cells in all places they're available, and moves double-striking into vtedraw. Tests look ok for bold and non-bold fonts, as before. Should I add a ChangeLog commit? I don't want to miss out on attribution for a nearly 8 year old bug. :)
Committed with proper attribution. Thanks! 2009-02-12 Behdad Esfahbod <behdad@gnome.org> Bug 54926 – Should try bold version of font before pseudo-bolding Patch from Kees Cook <kees@outflux.net> * src/vte.c (_vte_invalidate_cell), (_vte_invalidate_cursor_once), (vte_terminal_unichar_is_local_graphic), (vte_terminal_draw_graphic), (vte_terminal_draw_cells), (vte_terminal_draw_rows), (vte_terminal_paint_cursor): * src/vtedraw.c (_vte_draw_get_char_width), (_vte_draw_text), (_vte_draw_char), (_vte_draw_has_char): * src/vtedraw.h: * src/vtepangocairo.c (_vte_pangocairo_set_text_font), (_vte_pangocairo_get_char_width), (_vte_pangocairo_has_bold), (_vte_pangocairo_draw_text), (_vte_pangocairo_draw_has_char): * src/vteskel.c: Try bold font before pseudo-bolding.