Bug 99564

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.