"Fisher" beta for unclear reasons lost various fonts causing a sharp
decline in display quality. For example, one of few usable constant
width sanserif fonts in ISO8859-2 encoding, suitable for a terminal is:
(in XFree86-ISO8859-2-100dpi-fonts-1.0-12 from RH 7 and never mind
particular sizes). A supplied instead
to which the font in question was nominally aliased, is a totally different
font and practically unusable (makes an impression of messed up metrics).
In general on RH 7 'xlsfonts | grep -i biznet | sort | uniq | wc -l' gives
a number 227 and the same command for Fisher brings 1. An old experience
indicates that these "Biznet" guys knew a bit better what they were
doing with iso8859-2 than anybody else. A quick scan through the
system reveals that choices of passable terminal fonts in the encoding
in question are now really non-existent. I do not know about other
fonts but I suspect that the situation will be similar.
This defect is considered MUST-FIX for Florence Release-Candidate #1
XFree86-ISO8859-2-75dpi-fonts-1.0 will be excluded in RC1.
The both are now in XFree86.
Mike, i have looked at XFree86-ISO8859-2-100dpi-fonts-4.0.2-7.
This package does not include all the fonts, which are in
Please elaborate a bit. I looked at the -2 font packages after Preston
requested that I integrate the standalone font source package directly into
XFree. What I found was that the external package duplicates fonts that come
with XFree, but are slightly older versions. There are ulT1mo fonts in that
package however, so I have taken the ulT1mo fonts out and integrated them into
a new subpackage of XFree. This will be in our -8 release. This sounds like
the issue being raised in this bug report. Fixed.
If there are other issues with this font package, please reopen the bug and
let me know. Also, the source package used was:
Created attachment 10041 [details]
Image of xterm in RH 7 in 'lucidatypwriter' iso8859-2 font
Created attachment 10042 [details]
Image of xterm in Fisher in "the same" lucidatypewriter iso8859-2 font
The situation is really quite simple. I attach two screen capture
They represent an xterm using purportedly, or nominally - if you prefer,
the same font:
The first one is from RH 7 and the second one from Fisher beta. If you
want to convince me that the crappy font used in the second case is
actually useful for anything then you have better eyes then I do.
In the case of RH7 the font in question is really
and it is aliased to this 'lucidatypewriter'. If you have to specify it
explicitely, or you can do that via this alias, depends on a search
order you specified for font directories.
This is just a sample but the situation is similarly bad at least for
other iso8859-2 fonts. Unfortunately "biznet" family, which is quite
often preferable for this encoding, vanished after the latest
"cleanup". This is likely a mistake caused by the fact that the same
font names (aliases), and file names, are unfortunately used by
drastically different fonts. I do not know how this looks for other
encodings but I would be _really_ careful before trying to remove
apparent duplicates as they may be not be even close to duplicates after
The package shipped with fisher is missing fonts, yes. This was known, and
The fonts missing are from XFree86-ISO8259-2-1.0-15.src.rpm
XFree86 4.0.2 already has some of the fonts in this package - exact filenames,
filesizes, etc. The ulT1mo fonts are not in 4.0.2 however, so I have
incorporated this package into XFree86-4.0.2-8 and later. The next public
XFree86 package higher than -8 will have these fonts. It is not clear if
this will be in our Release candidate 1 however. Watch RC1, and Rawhide for
XFree86-9 or -10 for the fix and if that release does not work, please reopen.
Despite my earlier reports iso8859-2 fonts in 4.0.2-11 "test release"
are still seriously broken. While I can appreciate that moving font
(but one was lost in this process) and adding some new fonts (if they
do not have messed up metrics) is a good thing I is still claim that
replacing working fonts with completely broken "equivalent aliases"
and loosing XFree86-ISO8859-2-Type1-fonts-1.0-12 package (various
"misc" fonts - still not in Wolverine) is not a good deal and it
should NOT be contemplated. Despite of the fact that a number of new
fonts did show up a list of uniqe names for RH7 is still 43 positions
Attached is a diff on sorted names of list of all iso8859-2 between
what was in RH7 and what can be found now. You can easily note
many missing fonts. My earlier examples of messed up termninal
display are still valid. The issue is NOT "resolved in rawhide".
Created attachment 11660 [details]
list of font names which "vanished" in Wolverine
I'll have to look at the scripts which generate the fonts in X and
compare with those from the older separate package because the source
files are the same.
*** Bug 12223 has been marked as a duplicate of this bug. ***
michal - Can you confirm if this is fixed in any release now, including rawhide?
I believe the problem has been fixed for a while now, and the report not
This was "fixed" in that sense that that the current combination of
LucidaTypewriter/Xserver/ISO8859-2 does not show funnies like on pictures
from over a year ago.
OTOH all "Biznet" fonts which were present in RH 7.0 vanished without trace.
Distribution RH 7.2 has quite a bit smaller set of "ult1mo" fonts but packed
in a wrong format making them unusable (see #34913) unless you realize that
you have to gunzip these. Last time I looked at rawhide (XFree86-4.2.0-6.32)
a supply of scalable (NOT bitmap) fonts in ISO8859-2 encoding was very small.
A few fonts which happen to have multiple encodings in URW fonts and that is
nearly it. In particular in scalable fixed width ISO8859-2 there were only
Courier and Luxi Mono (which looks quite terrible in most resolutions).
I hoped that this is only rawhide property and that later some missing stuff
will reappear. But the trend seems to be to solve these problems by making
less and less available. Fonts in other encodings do not seem to suffer that
XFree86 explicitly supports gzipped pcf font files, and in fact, the
XFree86 build process itself is what compresses them. This is ordinary
behavior, and the solution is not to gunzip them. I do not yet know
what the problem is, but it is not the fact they are compressed.
The trend isn't to make less and less available at all. The trend is
to try and change the font packaging to a more useable and useful format
that is easier to maintain going forward. Along the way, problems may
occur. This is called "development process". It is not a simple process
for one person who knows little about fonts to fix every one of the
million font problems that come up, especially with font encodings that
aren't used locally to begin with.
I do my best trying to keep this stuff working. I just FOUGHT to keep
the new fonts-ISO8859-2 package in the distro since it was considered
duplication. I have finite time, and reading negative commentary like
this constantly does not make me want to focus on mastering fonts and
font related issues any sooner, nor does it make my job any easier.
What is worse, is that someone will fiddle around with things and find
a way that solves the problem for _them_. Then they will file a bug
report - also with highly negative tone jumping up and down expecting
their problem to be fixed yesterday. In a quest to make everyone happy,
I will look over someone's suggested fix, apply it, then get 10 *NEW*
bug reports from *other* people, our installer team, and other sources
telling me that the new bugfix patch to fix fonts for foo, just broke
fonts bar, and made the installer ugly, or some other random issue.
Often I find it better to leave things as they are if they work for
most people, and my changes end up causing 10 times the number of
people to cry that I broke something. The biggest single frustration is
probably reading one users "obvious" fix, that they just cant believe
how stupid we are to not apply their obvious fix, to do so and be
told by some other user how stupid we are for applying that fix and
breaking their setup.
One thing I do notice though, is wether or not if there are font issues
outstanding that are broken in some way, if I dont touch anything at all,
I get less bug reports, less complaints. It seems only in the quest
to fix this crap do I end up receiving MORE bug reports, and more
I for one will be much happier camper when Xft2 comes out with
fontconfig, and things move away from server side fonts to client side
fonts, preferably also moving to using mainly TrueType.
X severely needs to get out of the font stone ages.
> XFree86 explicitly supports gzipped pcf font files...
Well, yes, and so what? One of assorted troubles are fonts which are packed
at least with some versions of X (for example still as a part of
XFree86-4.1.0-15) and which are in a pfb format and not pcf. These do not seem
to be supported gzipped or not well enough to be usable. Without gunzipping
them they are a dead wood and, as one of side effects, Netscape (for example)
behaves in quite weird and nasty manner if some of these fonts are needed.
If I understand correctly after a long time these things are finally resolved
at least in rawhide. It remains to be seen what will happen in distributions.