From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020301
Description of problem:
The file /usr/X11R6/lib/X11/fonts/Type1/fonts.scale of the package
XFree86-base-fonts lists the ulT1mo fonts, with references to files like
timenrm_.pfb. Those files, however, are not included in the package. This
gives all kinds of strange behaviour. Many programs say
Warning: Cannot convert string "-ult1mo-times new
roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific" to type FontStruct
Other effects can be seen in xlsfonts, which fails to update its preview area,
leaving the menues around there.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
'-ult1mo-times new roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific
2.xfd -fn '-ult1mo-times new roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific'
1: -ult1mo-times new roman-medium-r-normal--17-120-100-100-p-0-adobe-fontspecific
2:Warning: Cannot convert string
"-ult1mo-times new roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific" to type
xfd: no font to display
Expected Results: Step 2 should have opened a window with the font displayed.
The package fonts-ISO8859-2-Type1 does contain a file named timenrm_.pfbm though
in the directory /usr/share/fonts/ISO8859-2/Type1. I did not have that package
installed when I observed this.
Added email@example.com to CC list, as this appears to be a duplicate
of his bug report of bug #60642 - Cant dupe them as one is public, one
This would explain why I could not reproduce the bug earlier, as I've
got all font packages installed.
60642 looks exactly like the problem i see in xfontsel. (I didn't find that bug
in my search before submitting. I was searching for font-related reports, and
saw the problems in xfontsel as just one symptom among others.)
No problem.. I just mentioned the other report to cross reference the
two, so when it is fixed, I can close them both as bugzilla does not allow
duping public bugs to private or vice versa.
I think that you are talking to my report bug #60641, which refers also
to bug #34913, which actually gives a solution to this problem. Unfortunately
providing all these ult1mo fonts, which _now_ I can use, has zero influence
on a problem described in #60642. Possibly some other font mess-up is
in work here but this is definitely not "ulT1mo".
BTW - this is NOT 'firstname.lastname@example.org'. You have one letter too much. :-)
[root@asdf Type1]# rpm -qf /usr/X11R6/lib/X11/fonts/Type1/fonts.scale
[root@asdf Type1]# grep -i ult1mo /usr/X11R6/lib/X11/fonts/Type1/fonts.scale
The base-fonts package does not refer to ulT1mo fonts at all.
ulT1mo fonts are part of the fonts-ISO8859-2 package, which installs
I have successfully tested ulT1mo fonts with the latest XFree86 and
fonts-* packages, and all of the tested fonts work fine for me. I am
not able to reproduce the problems described above.
On my system I am using:
[root@asdf Type1]# rpm -q XFree86-base-fonts fonts-ISO8859-2
Created attachment 51184 [details]
Screenshot of xlsfonts/xfd showing ulT1mo fonts working properly.
Created attachment 51189 [details]
I have a SLIGHTLY later build, and in my version the files ARE included. Did you try "rpm -V"?
Mike, we suffer a version skew here. You are correct about, say, current
rawhide packaging and this is, AT LAST, like it should be. That it used to
be otherwise is a bug in itself. Look at a standard 7.2 installation with
$ rpm -q XFree86
$ rpm -l XFree86
(and so on). These are ulT1mo fonts, in a wrong format, and stuck into
the main package. At least my reports #60641 and #34913 (not #60642)
were about _that_ and not the latest, finally corrected, stuff.
BTW - I think that this should be fixed when updates to earlier distributions
will happen or at least a "technical note" should be issued to their users.
At least 7.1 distribution suffers from the same problem (and earlier ones
likely as well).
There is no way at all that the ulT1mo fonts are included in XFree86 4.2.0
builds made in the last couple of months, nor will they be referenced
by any files in the 4.2.0 packaging. If it shows up for you, then you
are getting a mixup of old and new files. I should note that we do not
officially support upgrades from stable release to beta, from beta to beta,
nor from beta to official release.
Unless you can reproduce this with a fresh installation of the skipjack beta
(not an upgrade) I consider this bug to be non-reproduceable. I now have
build 4.2.0-6.50 installed and the problem just simply does not exist.
michal: I have looked at the 4.1.0 packaging, and have made a few changes which
I believe will fix this for 4.1.0 also. Are you willing to guinea pig test them?
Testing should probably be a fresh install of 7.2 plus updates, plus the new
packages I am about to produce. Let me know if you'd be willing to test it,
and I will make packages available on people.redhat.com - I've got a 4.1.0
erratum in the pipe for 7.1 and 7.2, so it would be nice to fix this as well.
Otherwise it will come in a 4.2.0 update at some future point probably.
Do I get one more chance? I think I have found the real bug now.
The fonts.scale file for in /usr/X11R6/lib/X11/fonts/Type1 is marked %ghost (and
%verify(not ..)) in package XFree86-base-fonts-4.2.0-6.47. Now, THAT's a bug,
isn't it? It would make sense for Type1/fonts.scale to be marked %config, but
not %ghost. I understand the fonts.scale is generated for TrueType fonts by
ttmkfdir in the postinstall scripts. But for Type1 fonts the postinstall
scripts only runs mkfontdir, which creates fonts.dir, but uses fonts.scale as input.
As an experiment, I moved away my fonts.scale file and did a reinstall of
XFree86-base-fonts. That gave me an empty (two bytes: a zero and a newline)
fonts.dir. Seems to confirm my conclusions.
(This explains our different contents of fonts.scale, although rpm -V didn't say
anything; the file doesn't really come with the package. I don't know how old
the fonts.scale file I had was, but it wasn't replaced when I upgraded.)
(Your comment on upgrades not supported was a bit too strong, right? I know and
understand beta-to-beta and beta-to-stable isn't important. But stable-to-beta
upgrades ought to be a relevant part of the testing of the beta.)
I've just checked the XFree86 spec file, the build tree, the installed
file tree, and the fonts.scale that is included there, and in the RPM
package are 100% correct for the fonts that come as a part of the
XFree86 package. This fonts.scale file is provided, and not calculated
at runtime like the truetype fonts.scale files are.
This is in the current 4.2.0-6.62 package. If there is any problem
remaining with this it is definitely not part of the XFree86 packaging
where the problem lay. I am going to look at the fonts-ISO8859-2-Type1
package to see what is going on there.
I just reread the whole bug report, and I think there is some confusion
from the initial report at play over what exactly a %ghost file is.
A file flagged as %ghost in an RPM file list, means that the file is
_owned_ by the given package, however it is not physically _part_ of
that package. %ghost is used to flag files which are created during
post install scripts, such as fonts.dir being created by mkfontdir
during installation. We want the package to own the file, however the
file does not exist when the package is built, it is created dynamically
when the user installs the package. %ghost is also used for files that
are not present, but which are valid to exist. For example, any font
directory can legally contain a fonts.alias file. We do not provide
a fonts.alias file however in every directory because they are not
necessary to exist in every directory. However, a user could create
a fonts.alias file in any given directory, and if they do, we want that
file to be owned by the package which owns that directory. Same goes
for the optional encodings.dir files.
In the actual XFree86 font packages, I have taken extensive care to audit
all of the font.* files, and encodings.* files very recently, and ensure
they are all listed properly, and they are flagged with %ghost, %verify,
and %config as deemed necessary.
I believe the file lists are correct in the 4.2.0-6.62 version of XFree86.
The fonts.scale file included in this package is now the static file
provided by XFree86, as I have no idea how to dynamically create them,
(nor how XFree86.org creates them in the first place). I understand there
is a type1inst program out there, but also was under the impression that
that utility is not necessary. This needs further investigation.
All of this may or may not be related to the problem reported above,
however I wanted to share the above info nonetheless so we're all on
the same page.
There may be a flaw in the fonts-ISO* package that causes the problem you
are seeing, and if so, I hope to find and fix it shortly.
I will update the report with my findings.
The fonts-ISO8859-2 package did contain very broken file lists. Ick ick ick.
Fixed in newest release. This issue should be resolved now, closing as
fixed in RAWHIDE.