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.
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.
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. TIA
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 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.
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 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.