[Fontinst] naming font definition files

[Lars Hellström]

Dr. Clea F. Rees skrev:
> This is not strictly a fontinst issue but this list seemed more
> appropriate than the others I'm aware of. But please let me know if I
> should redirect the question.

There's also tex-fonts at math.utah.edu, which may be appropriate.

> Could somebody either tell me or point me to documentation which
> explains the requirements for naming font definition files?

fntguide.tex (part of the base LaTeX sources) is probably the primary 
reference here.

> For example, suppose I have a font and font family called ArrowsADF and
> the family has encoding U. Then in effect, I tell LaTeX to load
> U/ArrowsADF/m/n, say. What determines the name of the font definition
> file searched for and/or how should that file be named?
> 
> Originally, I used uArrowsADF.fd. This works fine for me but it turns
> out not to work everywhere. Experimentation suggests that uarrowadf.fd
> works elsewhere but whether that works everywhere is a further question.
> 
> Because it seems that what works here doesn't work elsewhere (and also
> because I'm curious :), I'd like to understand what's happening so that
> I have at least a fighting chance of using names which work everywhere.

Originally the FD name was just <encoding><family>.fd, which typically 
meant the filename was mixed-case. This caused problems when files were 
moved between monocase (in particular ISO CDs) and case-sensitive 
(UNIX) file systems however, so I believe it was changed (in LaTeX) to 
all lower case in the mid 1990's. Certainly fontinst lowercases names 
of FD files it generates. LaTeX seems to try first the lowercased name 
and then the case-preserved name:

\def\try at load@fontshape{%
    \expandafter
    \ifx\csname \f at encoding+\f at family\endcsname\relax
      \@font at info{Try loading font information for
                    \f at encoding+\f at family}%
     \global\expandafter\let
        \csname\f at encoding+\f at family\endcsname\@empty
      \nfss at catcodes
      \let\nfss at catcodes\relax
      \edef\reserved at a{%
        \lowercase{%
          \noexpand\InputIfFileExists{\f at encoding\f at family.fd}}}%
      \reserved at a\relax
           {\@input@{\f at encoding\f at family.fd}}%
    \fi}


> Looking at the log file sent from elsewhere (Debian, I think), LaTeX
> seemed to search for UArrowsADF.fd rather than uArrowsADF.fd even
> though trying to load U/pzr/m/n, for example, prompted it to search for
> upzr.fd.

Seems strange, even though Debian advocates have been very firm on 
requiring the right to fuck up their TeX distros. ;-) But the 
explanation can be that LaTeX uses \InputIfFileExists for the lowercase 
form of the name.

> The only hypothesis I can come up with is that on some systems (ie
> depending on the OS or underlying file system) LaTeX makes the encoding
> name lowercase before searching only if the family name is all
> lowercase, but on other systems, it makes it lowercase regardless. This
> seems counter-intuitive and ad hoc, so I suspect there's something here
> I just don't understand but my attempts at googling have so far yielded
> nothing helpful.

One would normally expect LaTeX to do exactly the same thing on all 
platforms (even though with Debian you never know), and special cases 
there for mixed-case names are unlikely (since it's not entirely easy 
to test for).

For TeX this rather falls in the system-dependent part of the program, 
so various heuristics on this level are not unlikely. Karl Berry would 
probably know if kpathsea-based TeXes do something special for 
mixed-case names.

Finally, the file system definitely makes a difference. The default on 
MacOS(X) is HFS+, which remembers the case of filenames but considers 
all case variations of a name to be equivalent. Trying to open 
uArrowsADF.fd will then succeed even if the file name is UArrowsADF.fd, 
but the same would not work on a UFS volume.

Lars Hellström