Bug 27072 - fonts gone without suitable replacements
fonts gone without suitable replacements
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: 12223
  Show dependency treegraph
 
Reported: 2001-02-11 14:21 EST by Michal Jaegermann
Modified: 2007-03-26 23:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-16 13:07:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Image of xterm in RH 7 in 'lucidatypwriter' iso8859-2 font (58.20 KB, image/jpeg)
2001-02-14 14:37 EST, Michal Jaegermann
no flags Details
Image of xterm in Fisher in "the same" lucidatypewriter iso8859-2 font (73.42 KB, image/jpeg)
2001-02-14 14:38 EST, Michal Jaegermann
no flags Details
list of font names which "vanished" in Wolverine (35.18 KB, patch)
2001-03-02 18:11 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2001-02-11 14:21:24 EST
"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:

-biznet-fotinostypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso8859-2

(in XFree86-ISO8859-2-100dpi-fonts-1.0-12 from RH 7 and never mind
particular sizes).  A supplied instead

-b&h-lucidatypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso8859-2

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.

  Michal
  michal@harddata.com
Comment 1 Glen Foster 2001-02-12 17:59:42 EST
This defect is considered MUST-FIX for Florence Release-Candidate #1
Comment 2 Ngo Than 2001-02-12 19:54:13 EST
XFree86-ISO8859-2-100dpi-fonts-1.0 and
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
XFree86-ISO8859-2-100dpi-fonts-1.0-12.noarch.rpm.
Comment 3 Mike A. Harris 2001-02-13 17:13:57 EST
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:

XFree86-ISO8859-2-1.0-15.src.rpm

Comment 4 Michal Jaegermann 2001-02-14 14:37:18 EST
Created attachment 10041 [details]
Image of xterm in RH 7 in 'lucidatypwriter' iso8859-2 font
Comment 5 Michal Jaegermann 2001-02-14 14:38:52 EST
Created attachment 10042 [details]
Image of xterm in Fisher in "the same" lucidatypewriter iso8859-2 font
Comment 6 Michal Jaegermann 2001-02-14 14:40:00 EST
The situation is really quite simple.  I attach two screen capture
images

xterm.image7.jpg
xterm.image71.jpg

They represent an xterm using purportedly, or nominally - if you prefer,
the same font:

 -b&h-lucidatypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso8859-2

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

 -biznet-fotinostypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso8859-2

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
all.

  Michal
Comment 7 Mike A. Harris 2001-02-14 18:23:44 EST
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.
Comment 8 Michal Jaegermann 2001-03-02 18:09:51 EST
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
directories from

/usr/share/fonts/ISO8859-2/Type1/
/usr/share/fonts/ISO8859-2/100dpi/
/usr/share/fonts/ISO8859-2/misc
/usr/X11R6/lib/X11/fonts/latin2/75dpi/

to

/usr/X11R6/lib/X11/fonts/latin2/Type1/
/usr/X11R6/lib/X11/fonts/latin2/100dpi/
/usr/X11R6/lib/X11/fonts/latin2/75dpi/

(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
longer.

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".

  Michal
  michal@harddata.com
Comment 9 Michal Jaegermann 2001-03-02 18:11:29 EST
Created attachment 11660 [details]
list of font names which "vanished" in Wolverine
Comment 10 Mike A. Harris 2001-04-01 08:09:56 EDT
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.
Comment 11 Milan Kerslager 2001-06-30 04:27:27 EDT
*** Bug 12223 has been marked as a duplicate of this bug. ***
Comment 12 Mike A. Harris 2002-03-09 10:53:40 EST
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
updated.
Comment 13 Michal Jaegermann 2002-03-09 12:09:44 EST
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
badly.
Comment 14 Mike A. Harris 2002-03-16 11:09:29 EST
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
complaints.

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.
Comment 15 Michal Jaegermann 2002-03-16 13:07:01 EST
> 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.

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