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
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):
Steps to Reproduce:
1. Find any font that has more than 5 characters missing: winpets1, for
2. Unpack it in your local fonts directory and run ttmkfdir -m 100
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.
6. Try to use the original font you had.
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
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.
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.
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.
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
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.
Deferring bug for future release.
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
I don't profess to have the true answer, however lets make sure xfs
initscript and installation of fonts, both generate the same result.