Bug 55984 - xfs init script messes up fonts
xfs init script messes up fonts
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: ttmkfdir (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Yu Shao
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-09 16:27 EST by Tim Waugh
Modified: 2007-04-18 12:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-05 19:22:59 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)

  None (edit)
Description Tim Waugh 2001-11-09 16:27:04 EST
Description of Problem:
The xfs init script can mess up fonts.* files.  The reason is that some 
TrueType fonts can legally have many characters (more than 5) missing: 
several types of dingbats fonts that I have do.

The initscript runs ttmkfdir with no arguments when it decides it wants 
to re-create fonts.scale, but that's bad news.  When I run ttmkfdir by 
hand, I make sure to give it '-m 100' so that the dingbat fonts I have 
work.

Perhaps the init script should use -m 100 by default, or perhaps there 
should be some magic file like leave-me-alone that tells the xfs init 
script not to even try to be clever.

Version-Release number of selected component (if applicable):
XFree86-xfs-4.1.0-3

How Reproducible:
100%

Steps to Reproduce:
1. Find any font that has more than 5 characters missing: winpets1, for 
example.
2. Unpack it in your local fonts directory and run ttmkfdir -m 100 
>fonts.scale
3. Restart the xfs server, and verify that the font works.
4. Unpack another font in your fonts directory but don't run ttmkfdir yet.
5. Reboot.
6. Try to use the original font you had.

Actual Results:
You can't.

Expected Results:
You can.
Comment 1 Mike A. Harris 2001-11-12 19:55:24 EST
Well, it is a constant debate wether or not our xfs initscript
shoud do what it is doing.  One thing stands solid though, and
that is the fact that if it is removed, _I_ am the one who is
going to get all the bug reports and non stop bitching that
xfs initscript no longer automatically takes care of fonts.

Short term solution:  I will look into adding that option to
ttmkfdir calls as requested.  Sounds semi-sane to me anyways.

Long term solution:  Have xfs deal with fonts itself precluding
the need for ttmkfdir and mkfontdir.  ;o)  Windows doesn't need
them afterall.
Comment 2 Alexei Podtelezhnikov 2001-12-26 21:04:49 EST
I hereby certify that ttmkfdir does an excellent job on identifying the fonts 
and their true capabilities. It exposes all existing character sets in full 
agreement with Microsoft tools, btw. Some of them are undesirable. Then again, 
it's a problem inside *.ttf files, not in ttmkfdir.
Comment 3 Mike A. Harris 2002-01-23 15:07:34 EST
I am not sure how best to handle this situation Tim.  Not being
ultra familiar with this stuff, I would tend to apply your change
because you say it works.  owever, past changes I've made like
that in XFree86, and related stuff that I wasn't completely
in full grok mode on - I have lived to regret.

I've Cc'd Owen and bero in case they'd could provide some useful
feedback as well before any changes are made.

TIA
Comment 4 Alexei Podtelezhnikov 2002-01-23 16:38:44 EST
ttmkfdir does toogood of a job as shown in bug 57818. 
The issues are indeed complicated. TT fonts can contain numerous charsets, plus
they aparently have info on which ones to use, and which ones to avoid.
Should there be a ttmkfdir which knows how to deal with it, there would be no problem.
Comment 5 Mike A. Harris 2002-03-08 01:22:33 EST
It would be nice if we:

1) Had a clue how this crap is handled so effortlessly in Windows

2) Had someone, who had a PhD in TrueType font stuff

and

3) Had the manpower to make it DO that without screwing things up.

Any volunteers?  ;o)

Seriously.. me and yshao will be looking into some of these things soon
to try and come up with a solution.
Comment 6 Mike A. Harris 2002-08-08 06:42:00 EDT
Deferring bug for future release.
Comment 7 Mike A. Harris 2003-01-11 22:10:57 EST
ttmkfdir has been split into it's own package now, so I'm reassigning this
to the ttmkfdir component.

Some things to remember however:

1) xfs runs ttmkfdir in all ttf font directories, and uses the same
   commandline options for every directory.  This is next to impossible
   to change without amazing amount of complexity.

2) All font directories *should* work properly by default with ttmkfdir

We're going towards Xft based fonts, so legacy core server fonts are not
a critical mass like they once were.  We can't have ttmkfdir being called
with special kludge commandline options from postinstall scripts however
because when the xfs initscript runs, it WONT have these special commandline
options on it, and users will experience font inconsistency and random
behavior.

I don't profess to have the true answer, however lets make sure xfs
initscript and installation of fonts, both generate the same result.

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