[XeTeX] Mac OS X Savoye

[Jonathan Kew]

On 28 Nov 2005, at 6:43 am, Adam Twardoch wrote:

> Jonathan Kew wrote:
>> Ugh -- I've never seen an actual font name with a colon in it! (Or  
>> period, I think.) Both of those may present problems.
> Unfortunately, some of the older Letraset/ITC fonts have such names  
> and they're still being sold. They were bundled with a variety of  
> products so they will be around for quite some time. Altogether, I  
> believe allowing esacpe sequences (\., \:) or alternatively,  
> allowing to address a font by its path name would be a remedy.

Path name would be a problem in the case where the file is actually a  
suitcase containing several fonts.

On the other hand, I've been somewhat interested in allowing XeTeX to  
use fonts that aren't actually installed, and specifying pathnames  
would be one way to indicate such fonts. Something to think about.

Escape sequences are not as straightforward as one might expect,  
because users would also expect to be able to "escape" the character  
used to quote the name. But in a case like (hypothetically):

	\font\x = "Font Name \:1\.0 With \"Embedded\" Version:feature=setting"

there are two levels of scanning going on. The \" would need to be  
handled while TeX is scanning the name (which is done by the filename- 
scanning routines) and looking for the closing quote character, while  
\: would need to be passed on to the next stage, when XeTeX's font- 
loading routine examines the name for feature information.

In any case, \ would probably not be a good choice, as TeX is still  
happily expanding macros while scanning the name. So \", \:, \. are  
all TeX macros (assuming the default catcode regime) and may expand  
to all kinds of unexpected stuff! Getting literal backslashes into  
the scanned string is of course possible, but hardly straightforward  
for the average user. But I'm also a bit hesitant to create a new  
magic escape character for this context.

By the way, this name actually illustrates two entirely distinct  
problem cases! Both "." and ":" will cause trouble, but for different  
reasons. Font names are scanned as filenames, and so "." is taken as  
starting the extension. But TeX actually discards filename extensions  
when processing \font, as can be demonstrated by:

	*\font\xx=ccr10.foobar at 12pt
	
	*\show\xx
	> \xx=select font ccr10 at 12.0pt.
	<*> \show\xx

(The ".tfm" extension actually used when loading font metrics is hard- 
wired.) So that's why the error messages people have cited drop the  
final ".0" here. Obviously, I can (and should) fix this, so that the  
"extension", if any, is included as part of the name XeTeX uses.

The colon, on the other hand, is accepted as part of the name; but  
then XeTeX interprets it as marking the end of the font name itself  
and takes everything following as feature specifiers.

>> The "1.0" looks suspiciously like a version number, which  
>> shouldn't normally be included in a font name; there's a separate  
>> field for version information in the fonts. So (assuming this is  
>> indeed version information, not really part of the actual name,  
>> conceptually), one could argue that the font is incorrect.
> It is correct. Colon and period are legal characters in terms of  
> the font format specification. So they can appear in family or full  
> names, though it's obviously not recommended. They should not  
> appear in PostScript font names. In this particular case, the PS  
> Font Name is "SavoyeLetPlain", the family name is "Savoye LET" and  
> the full name is "Savoye LET Plain:1.0".

I realize it's legal; there's no violation of the spec. That doesn't  
mean it's the right data to put in that field. After all, they could  
have put "Foo Bar Baz" or even "Times New Roman" :) into the Full  
Name field without violating the spec, but it's clearly the wrong data.

The correct Full Name would have been "Savoye LET Plain"; the "1.0"  
should have been part of the Version and Unique Name fields, but not  
the Full Name.

But in any case, XeTeX clearly needs a solution to this. I've always  
been aware that the way names were being handled had some  
limitations, but it was convenient and we've gotten away with it for  
a good while! :)

JK