Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 112151 - xterm does not display bold text due to color setting "white" in XTerm-color
xterm does not display bold text due to color setting "white" in XTerm-color
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-12-15 08:28 EST by Andreas Luik
Modified: 2007-04-18 13:00 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-15 03:06:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andreas Luik 2003-12-15 08:28:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
As recommended in the X Toolkit Manual, I'm using a X resource setting
    #ifdef COLOR
    *customization:                         -color

Unfortunately, the XTerm-color application defaults file uses
this brain-damaged color definitions:
    *VT100*colorUL: yellow
    *VT100*colorBD: white

Since my xterm's background is the default white, I cannot read
text written in bold (because it is white), and I can hardly read
underlines text (printed in yellow).

The color definitions in XTerm-color should be changed to be the
same as in XTerm:
    *VT100*colorUL: green4
    *VT100*colorBD: blue3

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. xrdb -merge -
*customization: -color

2. xterm &

3. in xterm:
man ls -> observe that underlined text is printed in yellow
top -> observer that system information at the top is not visible


Additional info:

BTW: color resource definitions should not be in XTerm, but in
XTerm-color anyways (as they are in the XFree86 CVS HEAD now).
Comment 1 Mike A. Harris 2004-01-15 03:06:17 EST
Every time we make changes to xterm resources that differ from
what XFree86 ships, we end up fixing one user's bug and creating
another bug for some other user, or upsetting another group of
users who liked things fine the way they were.  In some cases
there is indeed a bug in the default resources and in other cases
it is purely a question of preference.  Rather than be to blame
for causing xterm resource related problems for some users
however, I have decided a year or two ago, that we will no longer
modify xterm resources from what XFree86 ships, with 3 exceptions:

1) Changes which we were already applying prior to this decision
   remain present, since changing them would modify behaviour
   that many people already have come to expect.  In some cases
   I have tried to revert some of our xterm resource changes that
   were made prior to my ownership of the XFree86 resources and
   have done so successfully with no complaints, and in other cases
   I've had complaints either externally, or internally at Red Hat,
   and so I've reverted and put our small modifications back.

2) Something that is an acknowledged bug by the upstream xterm
   maintainer Thomas Dickey, which he has already changed in his
   official xterm.  That way we can make the same change, and be
   tracking the official sources for fixes.  Anything Thomas does
   not see fit to include in his official xterm sources, I will not
   include in ours either, in order to be consistent with upstream
   as possible - aside from these 3 exceptions of course.

3) Something that fixes a _major_ bug which affects a seriously
   large portion of our userbase, and results in a large number
   of bug reports submitted by various users.  The users will be
   redirected to Thomas Dickey to have the problem resolved in the
   upstream sources first if at all possible.  If Thomas disagrees
   with the changes, and we feel that the bug is serious enough or
   affects a large enough group of users, then I may decide to make
   the change anyway.

However, I have a very strong desire and tendancy to leave xterm as
close to stock as is possible.  gnome-terminal and konsole are our
officially supported terminal applications, and xterm is provided
as-is for end user convenience only, due to the number of users who
rely on it for legacy or other reasons.  I see no reason for us to
make changes to xterm that the upstream maintainer disagrees with,
which may upset the behaviour that other users expect, and which are
not fixing major bugs, and aren't easily worked around via end user
or system administrator configuration.

This particular bug seems to be a trivial annoyance to a small
subset of users rather than a major bug, and if it is fixed in
Thomas' upstream's xterm (we do not ship xterm as part of XFree86
anymore, but rather separately), the fixes will trickle into the
distribution when we update to XFree86 4.4.0 in the future.

However, if the upstream maintainer is willing to apply the changes
that are in XFree86 CVS head into the xf-4_3-branch of 4.3.0 stable
CVS, I would consider that to be an upstream fix, and would have no
problem updating our stable branch patch to pick up this change for
future builds.  You may want to contact him to request this be
committed to the stable branch perhaps.  If it does get committed
there, feel free to reopen this report and I'll make the update.


Note You need to log in before you can comment on or make changes to this bug.