Description of problem: xorg-x11-xfs still requires and uses ttmkfdir to generate fonts.scale. However ttmkfdir is not actively maintained, the code base old and buggy, and it seems other distributions are not shipping or using it anymore. It seems mkfontscale is able to generate fonts.scale files for truetype font dirs. Additional info: It would be great if this could be done for FC5.
[Note: Me and Jens discussed this a bit in IRC last week. I am triaging bugs currently, and just stumbled upon this one, so I'm summarizing our discussion here so that it's logged somewhere for the future. I'm including all aspects, so that others perhaps unaware of the reason we ship ttmkfdir, will understand why it's there more easily.] A long time ago, in a galaxy far far away... mkfontscale didn't yet exist, and 'ttmkfdir' was what was used to prepare fonts.scale files for truetype fonts. ttmkfdir has a strange history to it. Strange in that - there is not just one single application out there in the open source world named "ttmkfdir", but rather there are at least 3, if not 5 or 10 utilities all named "ttmkfdir", all of which are completely different and maintained by individual people or OS distributions. Ouch! The original ttmkfdir if memory serves me correctly, was written in C, and maintained for a short time by the original maintainer, who then went on to bigger and better things. Various distributions shipped that ttmkfdir, and added their own patches to it over time, but there was no central maintainer for the abandoned ttmkfdir, so it became a rogue application with multiple slightly-different forks. Then one day, while the death-star was under construction, an evil young jedi decided to write a new implementation of ttmkfdir from scratch in C++. This ttmkfdir was much better functionality-wise than the original, and so Red Hat and some other distros started using it instead of the original. The C++ version was also abandoned (or seemingly) by its author, and so there are various heavily patched forks of ttmkfdir/C++ floating around in different distros. Then, around XFree86 4.3.0 or so (I don't remember the exact version), Juliusz Chroboczek (sp?) wrote a new application named "mkfontscale", which was intended to completely replace all of the ttmkfdir variants floating around, as well as handling opentype and type1 scaleable fonts. The idea of having a single application to do all of this is certainly very appealing, not just to the upstream X developers, but also to Red Hat and other distros. In the mean time, while the Rebels slept in hypersleep, a disturbance in the force started to become apparent. It turned out that the fonts.scale files generated by mkfontscale were not 100% identical to those generated by the ttmkfdir shipped by Red Hat, which caused user's applications to not work as they expected. Further testing showed that mkfontscale was unable to handle certain fonts that were shipped in the distro in a sane way, as well as various 3rd party fonts. The author of mkfontscale indicated he had no time or interest in enhancing mkfontscale to deal with these problems at the time, and so Red Hat had no choice but to continue using ttmkfdir for generation of fonts.scale for .ttf, .ttc, .otf, .otc fonts. I used to be the maintainer of Red Hat ttmkfdir for a while (despite not knowing C++ <cough>), and after a number of problems arose which affected fonts used in the APAC region, Yu Shao volunteered to maintain ttmkfdir. He did a very good job of resolving various issues, and I also helped clean up the code a bit. We've shipped that version for very many OS releases now, and have had almost no bug reports for ttmkfdir or about fonts.scale related problems for a _very_ long time now. So, where does this put us with solving this one? ;o) In order for us to safely replace ttmkfdir with mkfontscale in the distribution, we need to: - Gather together a list of all font rpms in the OS that install TrueType or OpenType fonts. Also, try to gather together various 3rd party ttf/ttc/otf/otc fonts which are in very common usage, as well as fonts used in Microsoft Windows, and which come with various applications for Windows. - Run our ttmkfdir on each of the font directories containing these fonts, as well as running mkfontscale on them, and redirecting the output to a different file. - Compare the 2 files for differences. - Determine if any differences are a problem or potential problem, and if so - fix mkfontscale to resolve the problem and send patches to X.Org (and XFree86.org, as I'm sure the original author would appreciate that too). - Once it can be shown that the output of the two is as close as possible on a wide variety of fonts, including Korean, Chinese, Japanese, Arabic, Greek, various Indic fonts, and as many other multilingual fonts as possible, we can then safely consider migrating from ttmkfdir to mkfontscale. Additional considerations: Various font rpm packages have rpm scripts that currently invoke ttmkfdir to complete the installation. In general, these are hard coded invocations which will fail if ttmkfdir is not present. Additionally, there may be font rpms that use rpm triggers (which is very very bad thing to do, but some do it anyway, including official Red Hat rpms). So, we need a "ttmkfdir" binary on the system to satisfy these package dependencies, and ensure upgrades work properly without spewing out errors to the user. My suggestion, is that once we get mkfontscale to a state that it can replace ttmkfdir without difficulties, we can write a shell script or C wrapper for ttmkfdir, which simply invokes mkfontscale with the proper commandline arguments. That will provide backward compatibility into the future. We should also then indicate that ttmkfdir is "deprecated" in the OS release notes, and that we've provided a wrapper that calls mkfontscale for legacy compatibility. By following the path I outline above, we have a reasonable chance of: - Removing unnecessary code from the OS which we currently are stuck maintaining (ttmkfdir) - Reduce OS maintenance efforts - Standardize on a common tool that is officially maintained in the upstream X sources, and has actual people maintaining it to some extent. We also share bugs, and bugfixes automatically with everyone else using it. - We will minimize the likelyhood of users experiencing migration problems, by pre-testing as many fonts as we can to ensure that mkfontscale is really an adequate replacement. - We make sure that we dont migrate to mkfontscale until we are 100% positive that it is a suitable and compatible replacement, in order to avoid having to change back to using ttmkfdir. Ok, that's a little bit more than me and Jens discussed in IRC, but it is a more verbose collection of my thoughts and concerns. I think it would be great to get rid of ttmkfdir for FC5, or for any upcoming OS release, and if we can do that without causing user problems, development time setbacks, or general chaos, then we definitely should attempt it. What would be really nice though, is if we could ditch the core fonts architecture completely and get fontconfig to supply core fonts somehow. That's something that needs to brew in upstream X mailing lists etc. however. ;o) Ok, 'nuff for now...
mkfontscale does not generate the same fonts.scale file output for all fonts. Switching from ttmkfdir to mkfontscale for all ttf fonts would cause fonts to vanish for certain users using certain fonts in certain languages. mkfontscale needs to be enhanced further to support all circumstances which ttmkfdir can handle now before it is a 100% replacement. If anyone is interested in working on such enhancements to mkfontscale, the best place to discuss it is probably on the xorg.org devel list. Such code would have to be done in upstream CVS and integrated into an X release before we would include it in Fedora. Setting status to "UPSTREAM"