[XeTeX] \font syntax

[Jonathan Kew]

On 31 Jul 2007, at 9:25 am, Hans Hagen wrote:

> Hi Jonathan,
>
> (to the list because my mails bounce)
>
> Is there a reason why
>
>    \font\test="rm-lmr7"
>
> fails, i.e. quotes are not accepted around a tfm name?
>
> The same for:
>
>    \font\test=[rm-lmr7]
>
> This fact that this gives error messages (is not accepted) makes it
> nearly impossible to implement robust interfaces (esp because i don't
> want users to be bothered by a font being tfm or otf or whatever  
> and let
> them provide quotes themselves when needed)

It seems to me that there's a pretty clear distinction between "tfm  
names", which are the usually-cryptic names of TeX-specific files  
that define a particular font *and encoding* (and are normally hidden  
from end users behind higher-level packages) and "font names" as  
normally used in XeTeX, which are the "real names" of fonts, as  
provided by the designer/vendor, independent of the file name on disk.

Traditionally, tfm names cannot contain spaces (because old TeX  
versions couldn't parse such names), and don't need quoting (which  
TeX didn't support). Font names, on the other hand, often contain  
spaces and do need quotes. So the convention in XeTeX is that when  
\font sees a quoted name, it treats it as the *font name* of a system- 
installed font (TrueType, OpenType, Type 1), whereas when it sees an  
unquoted name, it treats it as a tfm name and searches the texmf tree 
(s) in the usual way.

Given that the two types of font are often not completely  
interchangeable (e.g., they use different encodings), and are being  
identified by names of different kinds in different "namespaces", I'm  
inclined to think that maintaining a distinction is a good thing. So
   \font\A = phvr8r at 10pt
is expected to load Helvetica via a TFM file with the 8r encoding, while
   \font\B = "Helvetica" at 10pt
is expected to load the Unicode-encoded Helvetica (regardless of  
filename) on the platform. Those are two entirely separate kinds of  
name (and font); is it wise to confuse them?

The newer "[.....]" syntax, I grant, is a bit of a hybrid, as it  
allows you to load an OpenType (or TrueType) font by filename,  
regardless of the true font name; and the font need not be  
"installed" where general applications can access it. I didn't really  
expect this to be widely used; the "normal" ways to access fonts are  
via tfm names (for legacy TeX fonts) or via "real names" (for  
installed fonts on the platform). Having to install .otf files into  
the texmf tree, update ls-r files, and refer to them by their (often  
slightly cryptic) filenames rather than the human-readable font names  
seems to me to negate some of the benefits of XeTeX's approach.

Having said this, it used to be that XeTeX would try both kinds of  
font search, so if an installed font wasn't found for a "quoted"  
name, it would fall back on searching for a tfm; and if a tfm wasn't  
found for an unquoted name, it would fall back on searching for an  
installed font by name. I backed away from that behavior a long time  
ago now, as it seemed to be more confusing than helpful, but we could  
reconsider it. I'd be interested to hear other people's opinions on  
this.

If we do go that way, I guess you'd want it to try searching for  
a .ttf or .otf file by filename, too. There are actually three  
separate naming schemes: tfm name, opentype filename, or opentype  
font name. Currently, each scheme is deliberately distinguished at  
the \font declaration level; the question is whether to erase those  
distinctions. And if so, what order of precedence should we use?  
E.g., if the texmf tree contains both lmr10.tfm and lmr10.otf, should  
the declaration
   \font\lm=lmr10
load the tfm file (implying a legacy TeX encoding), or should it load  
the opentype font (Unicode)? The results will differ. (Which gets us  
back to why I think users -- or package writers -- need to be  
conscious of which they're asking for.)

JK