Bug 63453
Summary: | please package Latin2 fonts separately | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Jamie Zawinski <jwz> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-20 12:29:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jamie Zawinski
2002-04-14 05:12:04 UTC
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 properly. (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: http://bugzilla.gnome.org/show_bug.cgi?id=69085 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 > XFree86-4.1.0-15 Lets analyze how much space those ISO8859-2 fonts take up from that package: [root@asdf misc]# du -c *ISO8859-2* 8 10x20-ISO8859-2.pcf.gz 4 5x7-ISO8859-2.pcf.gz 4 5x8-ISO8859-2.pcf.gz 8 6x10-ISO8859-2.pcf.gz 8 6x12-ISO8859-2.pcf.gz 8 6x13-ISO8859-2.pcf.gz 8 6x13B-ISO8859-2.pcf.gz 4 6x13O-ISO8859-2.pcf.gz 4 6x9-ISO8859-2.pcf.gz 8 7x13-ISO8859-2.pcf.gz 8 7x13B-ISO8859-2.pcf.gz 4 7x13O-ISO8859-2.pcf.gz 8 7x14-ISO8859-2.pcf.gz 8 7x14B-ISO8859-2.pcf.gz 8 8x13-ISO8859-2.pcf.gz 8 8x13B-ISO8859-2.pcf.gz 4 8x13O-ISO8859-2.pcf.gz 8 9x15-ISO8859-2.pcf.gz 8 9x15B-ISO8859-2.pcf.gz 8 9x18-ISO8859-2.pcf.gz 8 9x18B-ISO8859-2.pcf.gz 144 total 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 unicode): [root@asdf 75dpi]# du -c *ISO8859-2.* *ISO8859-9.* *ISO8859-15.* |grep total 3900 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 XFree86-100dpi-fonts-4.1.0-3.i386.rpm -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 XFree86-75dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 9 root root 1092954 Sep 7 2001 XFree86-ISO8859-15-100dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 9 root root 938392 Sep 7 2001 XFree86-ISO8859-15-75dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 1039497 Sep 7 2001 XFree86-ISO8859-2-100dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 905711 Sep 7 2001 XFree86-ISO8859-2-75dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 1087967 Sep 7 2001 XFree86-ISO8859-9-100dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 936591 Sep 7 2001 XFree86-ISO8859-9-75dpi-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 1583031 Sep 7 2001 XFree86-Xnest-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 1700795 Sep 7 2001 XFree86-Xvfb-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 413810 Sep 7 2001 XFree86-cyrillic-fonts-4.1.0-3.i386.rpm -rw-r--r-- 7 root root 3787472 Sep 7 2001 XFree86-devel-4.1.0-3.i386.rpm -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 XFree86-libs-4.1.0-3.i386.rpm -rw-r--r-- 9 root root 515028 Sep 7 2001 XFree86-tools-4.1.0-3.i386.rpm -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 XFree86-xf86cfg-4.1.0-3.i386.rpm -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. (rpm) > - re-ran "mkfontdir" in each font directory. You guessed it, the postun scripts do that also upon uninstalling font packages. > - 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 files, etc. 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 >properly. That is why rpm is there. So you don't have to do all that stuff yourself. >(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 future. 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 frustration. 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 life. > 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. > (rpm) 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 solutions are: 1) Remove the font (not good if you do want it for some encodings and not others) 2) Edit the fonts.dir and remove the encodings for the font that you do not want. 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 also. 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 recoding. TTYL 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. Closing "WONTFIX" |