dircha <dircha@dircha.com> wrote:
However, when I use the XTerm menu to change (as I do regularly) the
font to Huge (10x20) or anything else and then later back to 7x14
(Medium, and also Default now), text is rendered using bold characters
or overstriking (whichever of the two it is).
I can reproduce this - looks like a bug. Essentially what's happening
is that the first time it's using the resource settings, but the logic
as I rewrote it around patch #181 (2003/10/26), lost the value of the
bold font in the menu logic.
.Xdefaults contains:
!! Use colors
XTerm*VT100*colorMode: on
!! Don't overstrike when font and boldFont are the same
XTerm*VT100*boldMode: off
That should work - my trace says both are the same size:
VTRealize
xtermLoadFont normal 7x14
same_font_size height 14/14, min 7/7 max 7/7
Will use internal line-drawing characters
Will not use 1-pixel offset/overstrike to simulate bold
XTerm*VT100*font: 7x14
XTerm*VT100*boldFont: 7x14
when switching back, it shows
SetVTFont(i=4, f_n=<null>, f_b=<null>)
xtermLoadFont normal 7x14
...derived bold -Misc-Fixed-bold-R-Normal--14-130-75-75-C-70-ISO8859-1
same_font_size height 14/14, min 7/7 max 7/7
...got a matching bold font
same_font_size height 14/14, min 7/7 max 7/7
Will not use internal line-drawing characters
Will not use 1-pixel offset/overstrike to simulate bold
but see the f_b=<null>, which tells me that it isn't using the original
bold resource (will have to study & fix that).
But the choice of bold font shouldn't be directly related to color.
My trace shows me that colorAttrMode is initially off. Also colorBD
(which I assume you meant to set). Setting those, I do get color for
the bold attribute. So you can do that, and it should work. (The
bug is still a bug - I'll fix that).