ttmkfdir no longer needed

[Nicholas Wourms]

Harold L Hunt II wrote:

> It looks like we no longer need ttmkfdir in order to expose the fonts 
> installed with Windows to X11.  The mkfontscale utility that is included 
> with out distribution was inspired by ttmkfdir and essentially replaces it:

That's not what it says, at least it makes no claim to be a full 
replacement.  It mentions only that it is inspired from the original 
ttmkfdir, but I don't think it in the same class as the latest version 
(ttmkfdir-3.x) from RedHat.  In fact, RedHat still retains and uses it 
to this day, even in the bleeding-edge Fedora's (which, BTW, are also 
using xorg-x11 for X11).  IIRC, Mike Harris says in specfile that while 
mkfontscale is adequate for latin font encodings, it doesn't work all 
that well with unicode and other complex encodings.  Since I speak 
English, I can't confirm nor deny if this is true, but if Mike is still 
using it for RedHat's TTF's, then I'd have to say there is some truth to it.

> You can do something like the following right now (well, not with Cygwin 
> 1.5.9 since mkfontscale will core dump, you have to use snapshot of 
> cygwin1.dll for the moment):
> 
> 1) mkfontscale /cygdrive/c/WINDOWS/Fonts
> 
> 2) mkfontdir /cygdrive/c/WINDOWS/Fonts
> 
> 3) Launch Cygwin/X
> 
> 4) In a bash shell under Cygwin/X, run:
> 
>    xset fp+ /cygdrive/c/WINDOWS/Fonts
> 
> 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' 
> category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among 
> others under the 'fmly' category.  Note also that valid chartacters 
> appear when you select these fonts.
> 
> 
> Due to this I am going to pull the link to ttmkfdir from our 'Ported 
> Software' page.  Perhaps someone would like to write a postinstall 
> script that creates symlinks to the Fonts folder for Windows under 
> /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in 
> that folder (since we can not guarantee that we have permissions to 
> create files in the actual Fonts folder for Windows).  Then it would 
> take a minor adjustment of our startup scripts to pass this additional 
> font folder to Cygwin/X on startup.
> 
> Any takers?  I'll package it if somebody works the kinks out of it.

I would *strongly* advise against any action which would work directly 
in and/or on a user's system's FONTS dir.  The first reason is that we 
can't guarantee the integrity of that link, since it could be broken due 
to some changes in CYGWIN case flags or inconsistencies in the case 
interpretation within the cygwin1.dll.  Speaking from experience, this 
has bitten me once before.  Secondly, the various utilities you want to 
use are required to open and read a significant portion of the font data 
from the font file.  Why should this be of concern?  Well if our font 
programs core dump while doing this, there is a possibility of 
corruption.  There's even the possibility of corruption even if the 
program works as expected.  Font corruption isn't always easy to detect, 
and often will lead people to make false assumptions about why they are 
getting unexpected or strange output from their fonts.  We really don't 
want to get into the business of messing around with or in end-users' 
system directories.  A better approach would be to copy the fonts to a 
predetermined Cygwin directory and work on them there.  Perhaps a C 
program, mkttwin32dir, which does as follows (this is very simplistic):

1) Check for the existence of /usr/X11R6/lib/X11/fonts/win32:

If yes, then hash the contents of that directory matching *.ttf into a 
sorted array, a[].

If no, then create the directory.


2) Check for the existence of the System font dir.

If yes, goto next step.

If no, abort and leave a textfile, README.fail, which contains some info 
on the reason it failed and to suggest user manually run the contents of 
the script.


3) Hash the contents of the system font directory for all matching *.ttf 
into a sorted array, b[].  Iterate the array, b[], converting strings to 
all-lowercase.  Put each resulting string into the corresponding second 
column of b[], which will be the target's name.  If we found a 
/usr/X11R6/lib/X11/fonts/win32 dir, then compare the contents of the 
first array, a[], with the contents of the target column of the second 
array, b[].  Discard from b[] any entries in which a font is in the 
target dir but not in the system dir.  Also, discard any entries which 
have a match both in the system and the target dir.  What is left will 
be the names fonts of needing copying and their case-converted target 
names.  Obviously, if a[] is empty, then all matches should be copied.


4) For all contents of b[], spawn cp and binary copy the source to the 
target.  Exit with a success return code.


Then we could use this program during postinstall to do the necessary 
work of keeping a user's /usr/X11R6/lib/X11/fonts/win32 dir up to date. 
  Furthermore, a user could set up a monthly cron job to do this 
automatically, so that the dirs are kept in sync.

This program could also be extended to do many other things, but this 
would be enough to get us started.  I've actually been thinking about 
this for awhile now and have been experimenting with some code to 
actually do what I suggest.  However, it isn't finished and is still far 
from proof-of-concept stage.  So, feel free to come up with 
alternatives, as this is just one suggested way.

Cheers,
Nicholas