Red Hat Bugzilla – Bug 63453
please package Latin2 fonts separately
Last modified: 2007-04-18 12:41:59 EDT
Description of Problem:
Because of bugs in Gimp, I want to uninstall all fonts
that are not Latin1 from my system.
I see that you have a package "XFree86-ISO8859-2" that
I do not have installed -- and yet, I still have Latin2
fonts on my system, because there are a *ton* of them
bundled in the "XFree86" package, e.g.:
% rpm -qf /usr/X11R6/lib/X11/fonts/misc/9x18B-ISO8859-2.pcf.gz
In my opinion, the "XFree86" package should include only
the fonts "fixed" and "cursor", and all other fonts should
be in their own RPMs, with only one encoding per RPM.
There needs to be balance whatever is done. Having 100 font packages
is quite messy also. I've been working towards saner font packaging
and dividing things up more sensibly than they've been in the past, however
there are still some "issues" needing thought.
Splitting up every single font src.rpm into separate encodings results
in a _lot_ of separate font packages, which increases maintenance,
package translation, and various other issues.
I will however look into this and consider it for a future release.
I *did* finally manage to excise all the Latin2 fonts from my system, and it
wasn't easy! It turns out that simply deleting font files was not enough. So
my initial request, of splitting the RPMs, is probably insufficient to
accomplish what I actually wanted to accomplish, which was getting the
non-Latin1 fonts out of my X server.
I did succeed in doing that, and here's what I had to do:
- deleted all files in /usr/X11R6/lib/X11/fonts/100dpi/,
75dpi/, and misc/ that did not have "ISO8859-1" in their
names, except for the various "cursor" fonts;
- deleted /usr/X11R6/lib/X11/fonts/latin2/
- edited all of the "fonts.scale" files in every font directory
under /usr/X11R6/lib/X11/fonts/ and /usr/share/fonts/ (GhostScript)
to delete all non-8859-1 entries;
- re-ran "mkfontdir" in each font directory.
- restarted xfs and the X server (yes, sadly, both were needed!)
It was a huge hassle! And I'm still not sure if I did it all
(But, now that the non-Latin1 fonts are gone, finally GIMP's
GDynText plugin is actually usable.)
I would consider that to be a bug in GIMP's GDynText plugin. If it
can't work with ISO8859-2 and other fonts, what use is it to the
rest of the non-English speaking world?
I agree, and I have reported it as such:
However, the fact remains that I have no need to have any fonts other than
Latin1 on my system, and I found it awfully hard to discard the ones I don't
need. Which was the point of *this* bug.
Ok, lets try to analyze this massive disk waste problem in depth and
come up with a solution:
From your first example:
>I see that you have a package "XFree86-ISO8859-2" that
>I do not have installed -- and yet, I still have Latin2
>fonts on my system, because there are a *ton* of them
>bundled in the "XFree86" package, e.g.:
> % rpm -qf /usr/X11R6/lib/X11/fonts/misc/9x18B-ISO8859-2.pcf.gz
Lets analyze how much space those ISO8859-2 fonts take up from
[root@asdf misc]# du -c *ISO8859-2*
Wow, 144KB of fonts. What a horrible waste of disk space. This
should indeed be put into a separate RPM package. That way users
not wanting this can save a whopping 144KB. Unfortunately, users
that do want them, now get an *extra* ~= 100KB+ added to their disks
by way of the RPM changelog added to the rpm database by every package
installed on the system.
Further counting a tally of all non ISO8859-1 fonts (not including
[root@asdf 75dpi]# du -c *ISO8859-2.* *ISO8859-9.* *ISO8859-15.* |grep total
3.9Mb. A bit more than 144KB, but still negligible really. Certainly nothing
worth getting all upset about in a bug report over. And lets face it,
hard disks are not 300MB in size anymore.
>I *did* finally manage to excise all the Latin2 fonts from my system, and it
>wasn't easy! It turns out that simply deleting font files was not enough. So
Coming from your background, I would have assumed quite the opposite
personally. It is quite simple actually, as I'll demonstrate below.
>my initial request, of splitting the RPMs, is probably insufficient to
>accomplish what I actually wanted to accomplish, which was getting the
>non-Latin1 fonts out of my X server.
Indeed, as I said before, splitting the RPM's that "are not already
split" would accomplish this. The real question is "is it worth the
effort at all". SO far, we've got 4Mb of space wasted.
>I did succeed in doing that, and here's what I had to do:
> - deleted all files in /usr/X11R6/lib/X11/fonts/100dpi/,
> 75dpi/, and misc/ that did not have "ISO8859-1" in their
> names, except for the various "cursor" fonts;
Which isn't necessary if you learn how to use RPM in the first
place. The 100dpi, 75dpi fonts are already split into per
encoding font packages. The UCS masters and ISO8859-1 encodings
are together in one package.
To remove them, you merely read the rpm manpage, and use the
rpm -e command to uninstall the unwanted fonts. Problem solved.
-rw-r--r-- 9 root root 4263020 Sep 7 2001
-rw-r--r-- 9 root root 19627732 Sep 7 2001 XFree86-4.1.0-3.i386.rpm
-rw-r--r-- 9 root root 3740943 Sep 7 2001
-rw-r--r-- 9 root root 1092954 Sep 7 2001
-rw-r--r-- 9 root root 938392 Sep 7 2001
-rw-r--r-- 7 root root 1039497 Sep 7 2001
-rw-r--r-- 7 root root 905711 Sep 7 2001
-rw-r--r-- 7 root root 1087967 Sep 7 2001
-rw-r--r-- 7 root root 936591 Sep 7 2001
-rw-r--r-- 7 root root 1583031 Sep 7 2001
-rw-r--r-- 7 root root 1700795 Sep 7 2001
-rw-r--r-- 7 root root 413810 Sep 7 2001
-rw-r--r-- 7 root root 3787472 Sep 7 2001
-rw-r--r-- 7 root root 9355163 Sep 7 2001 XFree86-doc-4.1.0-3.i386.rpm
-rw-r--r-- 9 root root 2122443 Sep 7 2001
-rw-r--r-- 9 root root 515028 Sep 7 2001
-rw-r--r-- 9 root root 109550 Sep 7 2001 XFree86-twm-4.1.0-3.i386.rpm
-rw-r--r-- 9 root root 136935 Sep 7 2001 XFree86-xdm-4.1.0-3.i386.rpm
-rw-r--r-- 7 root root 249209 Sep 7 2001
-rw-r--r-- 9 root root 135614 Sep 7 2001 XFree86-xfs-4.1.0-3.i386.rpm
- deleted /usr/X11R6/lib/X11/fonts/latin2/
Again, this directory need not be deleted, it should be uninstalled
properly with RPM. Use the right tool for the job, and things become
magically so much simpler.
> - edited all of the "fonts.scale" files in every font directory
> under /usr/X11R6/lib/X11/fonts/ and /usr/share/fonts/ (GhostScript)
> to delete all non-8859-1 entries;
What a shame. The postun scripts in the rpm packages do this
automatically when you uninstall the package using the proper tool.
> - re-ran "mkfontdir" in each font directory.
You guessed it, the postun scripts do that also upon uninstalling font
> - restarted xfs and the X server (yes, sadly, both were needed!)
No, sadly, both were not needed. Read the xfs manpage.
"kill -USR1 xfs" causes a running xfs to reread its config
It is simpler however for many users to shutdown the X server and xfs
and restart it the "Windows" way, instead of doing it the "Unix" way,
as it is less explaining to do generally. Especially if a user hasn't
read the manual pages.
>It was a huge hassle! And I'm still not sure if I did it all
That is why rpm is there. So you don't have to do all that stuff
>(But, now that the non-Latin1 fonts are gone, finally GIMP's
>GDynText plugin is actually usable.)
Again - that is not X's problem. Fix GIMP.
So, to summarize the whole bug report scenario:
1) You encountered a flaw in GIMP or a GIMP plugin which annoyed you
2) This was tracked down I presume to it not liking these fonts
3) Upset about trying to get the software to work correctly you tried
to hack around the problem by deleting files with wreckless abandon
and hacking up the other auxiliarry files rather than uninstalling
the fonts that were not needed by using rpm.
4) The whole process ticked you off enough in fact to file a bug report
hoping the mostly _perceived_ problems you had could be fixed in the
Well, now the whole matter boils down to one directory, the misc fonts
directory, in which all of the fonts are installed simultaneously
instead of in separate subpackages like the other dirs are _already_
in. That dir contains 3.9Mb of fonts.
I think the main problem is not 3.9Mb of disk space, and it is not about
choice of what fonts are installed. I think it is about software
So lets not blow it up into all font packages when it is one directory
of one font package. I stated I would look into the matter and _consider_
the possibility of splitting it up in the _future_. If there are indeed
perceived technical reasons for doing that, and no major counter reasons
for not doing it, then it is likely to happen.
It's not rocket science, just a few files residing on about a dollar's
worth of hard disk real estate.
Aside from your inconvenince with the misc directory, in the future,
you might want to consider reading the rpm manpage, and familiarizing
yourself with its various options.
Some possibly helpful commands:
See what font packages are installed: rpm -qa |grep font
Erase a font package rpm -e <packagename>
Incidentally, good luck with the Gimp problem. I hope my suggestions
minimize future difficulties that may arise.
Um, hello? Thanks for repeatedly pointing out how much disk space those fonts
take up, a point about which I clearly don't care. My goal was obviously not to
recover a few K, but to get them to stop showing up in "xlsfonts".
My problem was not disk space -- it's that having fonts on my system that I
don't need and will never use is causing other programs to malfunction. Yes,
those other programs are buggy. That doesn't change the fact that I don't want
or need these fonts, and would like to have an easy to way to get them out of my
> To remove them, you merely read the rpm manpage, and use the
> rpm -e command to uninstall the unwanted fonts. Problem solved.
Thank you for your smartassed yet still entirely unhelpful "clarification."
As I pointed out in my initial bug report, I don't *have* the XFree86-ISO8859-2
RPM installed, so the magic of its postinstalls script is (wait, let me do the
math... carry the 4...) exactly *zero* help to me.
> What a shame. The postun scripts in the rpm packages do this
> automatically when you uninstall the package using the proper tool.
So please explain to me what I uninstall to get 9x18B-ISO8859-2 to go away. Oh,
gee -- I'd have to uninstall the X server. How about that. But yes, it *is*
nice that after uninstalling the X server, it will go on to run mkfontdir for me!
> No, sadly, both were not needed. Read the xfs manpage.
> "kill -USR1 xfs" causes a running xfs to reread its config
> files, etc.
Thank you again for the smartassed yet again incorrect answer. After removing
fonts from the fonts.dir file, you have to restart the X server. If you only
send xfs USR1, or if you only kill and restart XFS, then "xlsfonts" says
"pattern * unmatched" forevermore. After restarting the X server, it works again.
Really. I'm not making this up.
> It is simpler however for many users to shutdown the X server and xfs
> and restart it the "Windows" way, instead of doing it the "Unix" way,
> as it is less explaining to do generally. Especially if a user hasn't
> read the manual pages.
Yeah, and it's amazing how many developers assume that anyone reporting a bug
must be completely ignorant of how things are *supposed* to work.
Look, I submitted this bug because I have a simple request: I would like to have
my system include only Latin1 fonts, as I don't use or want or need the other
encodings. My reasons for making this request are irrelevant. I don't think
it's an unreasonable request.
If you think it's an unreasonable request, fine. Mark it WONTFIX and get on
with your life.
But if you feel the need to talk to me like I'm some kind of moron for making
the request, well, don't bother, ok?
You conveniently ignore the fact that the only package in which this problem
occurs is the one containing the misc fonts. I have already agreed that this
"problem" you are describing, is indeed present, in the sense that you cannot
uninstall JUST the font encoding you do not want from the "misc" fonts.
All other font packages are already split up.
I think we have both made our individual points, and opinions ultra clear
to each other. I understand exactly what you're asking for, and I've told
you that I will look into the matter for the future.
Yourself being a developer, you should know this already - if you would
file bug reports with a bit more positive attitude, and less negativity,
you would be returned the courtesy as well. Having a problem, then taking
out your frustrations on an upstream developer in a negative manner rarely
results in a happy Mr. Rogers style problem resolution.
I am quite reasonable all things considered, when I'm approached with
problems appropriately, rather than flamed out of frustration. Also,
for the record - you are the very first person ever to bring this
perceived problem to my attention.
Neither one of us is a saint here, so lets *both* please try to avoid
this type of negative thing in the future.
I fail to see how anything in my initial report, or comments
of 2002-04-15 05:14:52 or 2002-04-15 07:06:55, were in any
way negative, inappropriate, or flaming. (Yes, my last
reply definitely was.)
But I'm glad you're still planning on looking into it.
After a fair bit of thought, rather than making a whackload of new font
packages, which is rather inconvenient in some ways, and rather than
leaving it as it is, which is inconvenient in other ways, the real root
problem is the fact that these font files even need to exist in the first
place. The only reason they exist is because they are produced during build
time by recoding the ISO10646 unicode masters into the various 8859 encodings.
This is done because otherwise the encodings would be unavailable. The sad
thing is that the glyphs all come from the unicode masters to begin with.
If X could recode the bitmap UCS master fonts at runtime into the required
8859, etc. encodings, and perhaps cache them, then the font packages wouldn't
need to exist at all. Packaging would be simplified, as would font
installation. Simpler all around both for developer, and for end user.
So, my current plan is to implement runtime dynamic font recoding in the
bitmap backend inside libXfont, and when that is done, totally remove all of
the 8859-x encoded font files from the distribution. I believe the code
would be portable easily to older X releases, so once I've got it done,
I'll likely backport it to all of our 4.x releases and stick it in all
future erratum. That'll save disk space, CD space, download time, etc.
How's that sound?
That sounds like a fine idea.
But I hope that in this new world, where all the encodings of the master fonts
are auto-generated, there's some mechanism for me to say "I only want Latin1
encodings on my machine, please. Don't ever generate the others."
When implemented, it will work exactly like Truetype and Type1 fonts do
in X right now, as well as Microsoft Windows. The on-the-fly recoding is
not done on disk, so there is never any redundant font storage on disk.
Rather, it is done in memory via translation tables. So resources are not
a concern anymore. As far as making a font available or not available in
a particular encoding - that is the job of mkfontdir.
mkfontdir scans a dir full of fonts, and spits out a fonts.dir which shows
which encodings each font has support for. If a particular font has an
encoding which you definitely do not want available, then the various
1) Remove the font (not good if you do want it for some encodings and
2) Edit the fonts.dir and remove the encodings for the font that you do not
3) Modify the font itself to remove the encoding, or remove glyphs that cause
it to be used for that encoding.
In general, most fonts are decent, and if they show encodings that end up
being less than optimal, it is more of a problem of font path order than
anything. I suggest putting good fonts (Truetype, Type1) first in the
font path, and also ensuring that bitmap fonts are not in the fontpath as
scaled. They should all have ":unscaled" at the end. I'm working with
XFree86 upstream on changing the default for bitmap fonts to unscaled,
and adding a :scaled option instead for the drug crazed maniacs that
want scaled bitmap fonts. ;o)
There are however some fonts which are bad - they advertise encodings that
they do not have a complete glyph set for, or they do have a complete glyph
set, but the glyphs for that encoding are just horrible. In these cases,
it is the font itself which is at fault, not any software, and the font should
just not be used, or it should be modified and used. Some of the CJK fonts
are like this. One of them advertises a Cyrillic encoding, but has ugly
as sin Cyrillic glyphs. There are likely many others out there that do this
The biggest problem faced by fonts in X, are making font installation and
configuration simple for end users and system administrators. It is very
complex problem to solve _properly_ (which I define as fonts in Microsoft
Windows). Add to that the fact that many fonts do not follow published
and/or defacto standards, and many are just ugly, and the problems increase.
Keith Packard's fontconfig, and Xft2 will solve many of these problems, but
I think font issues will still remain for the time being. At least there
are a lot of us working on them to try to minimize problems. There is
just way too much braindamage out there that we're all up against. ;o/
If it is completed in time however, the goal is to have the bitmap scaler
disabled by default in our next release, and hopefully do the on-the-fly
Defering for future release
XFree86 4.3.0 will be using Truetype for bitmap fonts. When this occurs,
the 8bit encoded fonts will disappear entirely, being replaced with
unicode ttf replacements. TTF files are also fairly compressed. The
net result is that disk space usage will be minimized, and the number
of subpackages will go down significantly as well, since we wont need
to ship various 8bit encoded fonts anymore, just the unicode ones.
My understanding is that this will happen in XFree86 4.3.0, so there's not
much sense mucking with our packaging right now for these fonts. Worst
case is that it doesn't make 4.3.0, and gets into 4.4.0 or 5.0 instead.
Either way, the issue should just vanish within the next year, if not
within the next month.
I've pinged upstream to see when the conversion to .ttf will occur.
I'm told it won't happen for 4.3.0 now, but will likely occur for 4.4.0
Doesn't look like upstream is ever going to do this as it's been
over 2 years later now and nobody bothered yet.
If it ever happens, the problem will go away, but we're not going
to change the way we package fonts now. 200Gb hard disks are around $125.