Bugzilla – Bug 99564
xterm fonts worse than with 9.3
Last modified: 2007-06-05 11:37:13 UTC
The rendering of blue directories in xterm became significantly worse with SL10 compared to suse 9.3. I'll attach two screenshots for illustration.
Created attachment 44144 [details] xterm of suse linux 9.3
Created attachment 44145 [details] xterm of suse linux 10.0 preview3
Mike, please investigate. Thanks.
I cannot test this as I don't have a 10 environment. 'ls --color=always > /tmp/foo' gives something like ESC[01;34mFooBarESC[00m for directories, so they are boldfaced (which means double striked for core fonts). However in the example it seems to be tripe scriked.
Dirk, are you using the system defaults or do you have any resources for xterm in your ~/.Xdefaults?
You need to set the resource .vt100.boldMode to false to make xterm use bold fonts. This should be the default.
Created attachment 44199 [details] new screenshot under SL10 the only line I have in .Xdefaults is: xterm*saveLines: 1024 adding: xterm*.vt100.boldMode: false makes it look a lot better (still different though) than before. I guess I can live with that. I can not find anything else touching vt100.boldMode, so it seems the default you assume isn't really the default.. possible?
Actually I could not find any difference between 9.3 and STABLE when using only the system defaults. xterm used emboldening by overstriking by default both on 9.3 and on STABLE.
Dirk Müller> it seems the default you assume isn't really the Dirk Müller> default.. possible? Yes, something is strange, at least it doesn't work as written in the man-page.
The man-page says: boldMode (class BoldMode) This specifies whether or not text with the bold attribute should be overstruck to simulate bold fonts if the resolved bold font is the same as the normal font. [...] If the normal and bold fonts are distinct, this resource has no effect. The default is ``true.'' Apparently this resource currently *has* an effect, even if the bold and the normal fonts are different. When I use XTerm*VT100*font: -misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1 XTerm*VT100*wideFont: -misc-fixed-medium-r-normal-*-13-120-75-75-c-120-iso10646-1 and leave the boldMode resource either unset or set it to "true" xterm uses overstriking. Only when I set boldMode to "false" the bold fonts are really used.
This behavior was indeed slightly different in 9.3. If boldMode was unset, the bold fonts were used. If boldMode was set to "true", the bold fonts were not used. That means even on 9.3 it didn't behave as written in the man-page, ("boldMode: true" was not ignored when bold and normal fonts were different, but at least when boldMode was unset it worked better.
Andreas Schwab> You need to set the resource .vt100.boldMode to false Andreas Schwab> to make xterm use bold fonts. This should be the Andreas Schwab> default. Setting the boldMode resouce to "false" results in no bold at all for fonts where no bold version exists. For example, the "Small" default font *fontMenu*font3*Label: Small !*VT100*font3: 6x10 *VT100*font3: -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1 (see /usr/X11R6/lib/X11/app-defaults/XTerm) has no bold version. When boldMode is set to false, one doesn't see bold at all (no overstriking) when using that font).
The behavior should probably be: if BoldMode is unset overstriking should be used when no bold font available. When set to false bold fonts should be used and no fallback should be made when not available while true should mean always overstrike. It looks like overstriking has changed from overstrike once to overstrike twice.
Egbert> The behavior should probably be: if BoldMode is unset Egbert> overstriking should be used when no bold font available. Yes, but currently it uses overstriking even if a bold font *is* available. Egbert> When set to false bold fonts should be used and no fallback Egbert> should be made when not available Yes. Egbert> while true should mean always overstrike. Not according to the man-page. According to the man-page the "true" should be ignored if bold fonts are available.
Created attachment 44216 [details] bugzilla-99564.patch Patch to fix the problem.
The following alternative patch would fix the problem as well: diff -ru xterm-203.orig/fontutils.c xterm-203/fontutils.c --- xterm-203.orig/fontutils.c 2005-07-07 02:46:14.000000000 +0200 +++ xterm-203/fontutils.c 2005-08-01 18:01:33.000000000 +0200 @@ -721,7 +721,7 @@ } if (myfonts.f_wb == 0 && !is_double_width_font(bfs)) { - fp = get_font_name_props(screen->display, bfs, normal); + fp = get_font_name_props(screen->display, bfs, (char *) 0); if (fp != 0) { myfonts.f_wb = widebold_font_name(fp); TRACE(("...derived wide/bold %s\n", myfonts.f_wb));
fp = get_font_name_props(screen->display, a, b) is only used to get a 'fp' for deriving a wide bold font with widebold_font_name(fp); But if 'a' does not belong to the same font as 'b', 'b' will be overwritten with the name of 'a' in get_font_name_props(). That means fp = get_font_name_props(screen->display, bfs, normal); will overwrite "normal" (the name of the normal font) with the name of the bold font and then later "same_font_name()" in screen->enbolden = screen->bold_mode && ((nfs == bfs) || same_font_name(normal, myfonts.f_b)); TRACE(("Will %suse 1-pixel offset/overstrike to simulate bold\n", screen->enbolden ? "" : "not ")); will be true which causes overstriking to be used. In order not to overwrite "normal" one can either use: fp = get_font_name_props(screen->display, nfs, normal); then "nfs" and "normal" belong to the same font and widebold_font_name(fp) will find a wide bold font if available because it adds the bold attribute: static char * widebold_font_name(FontNameProperties * props) { return derive_wide_font(props, "bold"); } Or, one could use fp = get_font_name_props(screen->display, bfs, (char *) 0); or fp = get_font_name_props(screen->display, nfs, (char *) 0); which just queries without ever overwriting the last, optional argument.
Fixed package submitted to STABLE, → FIXED.
Please send the patch to thomas dickey
done.