From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
At initial installation, Anaconda chooses console font
"latarcyrheb-sun16" for installed system. It is 512-glyph font
containing symbols for several languages.
Unlike usual 256-glyph fonts, such "big" fonts cause some
restrictions. Due to VGA hardware limitation, it is impossible to use
"intensity" bit when 512-glyph font is used. In other words, instead
of usual two groups of colors (0-7 and 8-15), we have only one (0-7).
As a result, console colors on installed system are spoiled. First
of all, yellow color completely disappears! Besides there is no
possibility to choose two kinds of intensity.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Load some 512-glyph font, for example:
2. Run "ntsysv", "mc" or some another console (curses/slang) applications.
Actual Results: In "ntsysv", service names are reddish (or
red-brown) instead of pure yellow.
In "mc", the same is for panel headers. Additionally, subdirectory
are not highlighted (but should be).
Expected Results: Expected results may be seen just after loading
of any normal 256-glyph fonts:
Now "ntsysv" and "mc" has yellow, subdirectory in "mc" are highlighted.
More evident test is possible:
Run "mc" on one virtual console, then switch to another and load
256/512 fonts on it. After loading, switch back, type Ctrl-L (to
redraw MC, because consoles are damaged immediately after "setfont")
and see the difference.
Solution is simple -- just switch to traditional 256-glyph font. By
the way, it shows why such issue does not arise after upgrade --
anaconda does not change existing /etc/sysconfig/i18n .
But for initial installed systems, it is a real problem. Some UNIX
users whom I wanted to transfer on RedHat, have told that "Midnight
Commander at your Linux looks worse!". I have spent some hours to
understand who has eaten yellow color on my just bought computer. My
company has many console applications (electric power schemes etc.),
and at bad colors it is impossible to work with them. Etc, etc, etc.
IMHO, support on the console of several languages simultaneously is
not necessary for the majority of users. Normaly, they want ascii, or
ascii and native language only.
Therefore we got an unneeded feature by the cost of worse console
colors and complaints of console-oriented users.
Anyway, must be some notes (in the documentation, or even at
installation time) about possible color issues to avoid troubles for
Created attachment 107048 [details]
Simple patch, trying to solve quickly this bug
Anaconda chooses parameter SYSFONT (for /etc/sysconfig/i18n in the installed
system), according to file "/usr/share/anaconda/locale-list". This file is
auto-generated at rpmbuild time by "scripts/genlocalelist.py" from anaconda`s
source. Therefore, the patch is against this script.
Currently, only "latarcurheb-sun16" can be chosen for "utf8" charmap. The
idea of my patch is try to guess appropriate per-language sysfont by "old"
non-utf8 data still exists in this script.
Of couse, it is not a final correct variant for the described problem. But,
IMHO, it is not worse than current behavior -- one common font under utf8 for
This is required to support UTF-8 locales, sorry.
Have you correctly understood my report?
Nothing should be changed for anaconda install itself. UTF-8 for
installed system is not changed too. Just the default console font for
new systems should be 256-glyph...
The maximum number of glyphs in a console font is 512. Anyway, it is
impossible to put all the world languages in one font. Except for lat,
arabic, cyrillic and hebrew ("latarcyrheb"), still is Greek, Georgian
and many other "simple", "non-like-a-china" languages. It is
impossible to put all of them into one, even 512-glyph font.
It can be considered as precedent.
If there are some reasons to use "latarcyrheb" glyphs, then may be
better to split it to several 256-glyph fonts? But there are already
such a fonts (lat0-sun16, cyr-sun16 etc.), and this fonts work well
even under UTF8 locale.
Can you write some additional words about this problem? It is
important for us as we want to promote Fedora and RHEL for the people
which use another distros, and this people are afflicted with bad
Yes, but the goal is to get maximal coverage. Yes, we can't get it
all but doing the best possible is the goal. Also, eg, lat0-sun16
isn't actually good enough for UTF-8 latin1 languages (I don't
remember exactly which glyphs it was missing as it's been ~ 2 years now)