Bug 27072
Summary: | fonts gone without suitable replacements | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Michal Jaegermann <michal> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 7.1 | ||
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: | 2002-03-16 18:07:06 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: | |||
Bug Depends On: | |||
Bug Blocks: | 12223 | ||
Attachments: |
Description
Michal Jaegermann
2001-02-11 19:21:24 UTC
This defect is considered MUST-FIX for Florence Release-Candidate #1 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. 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 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 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 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 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 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 updated. 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. 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. > 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.
|