[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@lists.freedesktop.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"