Bug 61694 - fonts.scale is %ghost-marked [Was: The base-fonts package refers to ulT1mo fonts, but they are not included]
fonts.scale is %ghost-marked [Was: The base-fonts package refers to ulT1mo fo...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: 61590
  Show dependency treegraph
 
Reported: 2002-03-22 18:50 EST by Göran Uddeborg
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-11 06:21:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of xlsfonts/xfd showing ulT1mo fonts working properly. (105.46 KB, image/jpeg)
2002-03-28 10:07 EST, Mike A. Harris
no flags Details
I have a SLIGHTLY later build, and in my version the files ARE included. Did you try "rpm -V"? (3.87 KB, text/plain)
2002-03-28 10:33 EST, Göran Uddeborg
no flags Details

  None (edit)
Description Göran Uddeborg 2002-03-22 18:50:23 EST
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):
XFree86-base-fonts-4.2.0-6.47


How reproducible:
Always

Steps to Reproduce:
1.xlsfonts -fn
'-ult1mo-times new roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific
2.xfd -fn '-ult1mo-times new roman-medium-r-*-*-*-120-*-*-*-*-adobe-fontspecific'

	

Actual Results:  
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
FontStruct
xfd:  no font to display


Expected Results:  Step 2 should have opened a window with the font displayed.

Additional info:

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.
Comment 1 Mike A. Harris 2002-03-23 04:27:09 EST
Added michael@hardata.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
private.

This would explain why I could not reproduce the bug earlier, as I've
got all font packages installed.
Comment 2 Göran Uddeborg 2002-03-23 05:05:58 EST
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.)
Comment 3 Mike A. Harris 2002-03-23 08:04:27 EST
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.

Thanks.
Comment 4 Michal Jaegermann 2002-03-23 14:46:46 EST
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 'michael@harddata.com'.  You have one letter too much. :-)
Comment 5 Mike A. Harris 2002-03-28 10:06:08 EST
[root@asdf Type1]# rpm -qf /usr/X11R6/lib/X11/fonts/Type1/fonts.scale
XFree86-base-fonts-4.2.0-6.44

[root@asdf Type1]# grep -i ult1mo /usr/X11R6/lib/X11/fonts/Type1/fonts.scale
[root@asdf Type1]#

The base-fonts package does not refer to ulT1mo fonts at all.
ulT1mo fonts are part of the fonts-ISO8859-2 package, which installs
under /usr/share/fonts

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
XFree86-base-fonts-4.2.0-6.44
fonts-ISO8859-2-1.0-1

Attaching screenshot...
Comment 6 Mike A. Harris 2002-03-28 10:07:32 EST
Created attachment 51184 [details]
Screenshot of xlsfonts/xfd showing ulT1mo fonts working properly.
Comment 7 Göran Uddeborg 2002-03-28 10:33:49 EST
Created attachment 51189 [details]
I have a SLIGHTLY later build, and in my version the files ARE included.  Did you try "rpm -V"?
Comment 8 Michal Jaegermann 2002-03-28 11:07:15 EST
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
current updates:
$ rpm -q XFree86
XFree86-4.1.0-15
$ rpm -l XFree86
.....
/usr/X11R6/lib/X11/fonts/latin2/Type1/alexb___.pfb.gz
/usr/X11R6/lib/X11/fonts/latin2/Type1/alexbi__.pfb.gz
/usr/X11R6/lib/X11/fonts/latin2/Type1/alexi___.pfb.gz
/usr/X11R6/lib/X11/fonts/latin2/Type1/alexm___.pfb.gz
/usr/X11R6/lib/X11/fonts/latin2/Type1/ariab___.pfb.gz
/usr/X11R6/lib/X11/fonts/latin2/Type1/ariabi__.pfb.gz
.....
(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).

Comment 9 Mike A. Harris 2002-03-28 11:40:51 EST
goeran@uddeborg.pp.se

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.
Comment 10 Mike A. Harris 2002-03-28 11:43:51 EST
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.
Comment 11 Göran Uddeborg 2002-03-29 15:27:03 EST
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.)
Comment 12 Mike A. Harris 2002-04-11 06:20:56 EDT
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.
Comment 13 Mike A. Harris 2002-04-17 17:43:51 EDT
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.

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