[XeTeX] XeTeX 1.0 - request for comments

[Jonathan Kew]

On 18 Oct 2005, at 12:49 am, Will Robertson wrote:

> 17/10/2005, 10pm - William F. Adams wrote:
>
>
>
>> Sorry, the previous message was supposed to go straight to JK.
>>
>> One feature I'd like to see would be the ability to write out a  
>> font's characteristics into a .pl like file which could then be  
>> edited, and an extension to the font interface to allow one to  
>> read in such a file and use the up-dated information in lieu /  
>> addition to the extent information in the font.
>>
>> Doing this would provide a mechanism for adding math support to  
>> fonts.
>>
>>
>
> ..and also be able to fix current deficiencies in fonts, like when  
> Apple forgets to add old-style figures to Hoefler Text Roman...
>
> This would need a carefully considered interface; I remember some  
> people proposing maths font metrics table for OpenType, but I can't  
> recall if it was a formal proposition or not. The problem would be  
> that you need one sort of file for AAT fonts, another for OpenType,  
> and yet another for additional maths capabilities et al.
>
> This would also allow the type of thing that Walter Schmidt does  
> for the PSNFSS project in fixing the spacing around punctuation,  
> fixing up glyphs, and so forth, for fonts that weren't so carefully  
> put together. The fontspec package or a direct interface in XeTeX  
> could detect if such font patches were available and load them  
> automatically, so all the user sees is much nicer looking output  
> that when using, say, TextEdit.
>
> Extend ad infinitum for diacritics placement, etc.
>
> Sounds like virtual fonts gone crazy, but it would be a very  
> powerful combination with font mappings.
>
> Forgive me for saying so, but it sounds like a 2.0 feature to me :)  
> If I recall correctly, font mappings were relatively easy because  
> JK already have TECKit to work from...

Will is right, this would be a pretty big undertaking, and would  
require a lot of careful planning and design. It's not going to  
happen quickly; it'd be a long-term project.

To some extent, I feel that it runs counter to the XeTeX paradigm,  
which is to work with fonts as provided by the font designer, making  
full use of the designer's spacing, positioning, kerning, variants,  
features, etc., rather than treating a font as merely a collection of  
glyph shapes and expecting the typesetting application to explicitly  
control every aspect of glyph choice and placement.

In principle, it seems to me that if a font has glyphs that need  
"fixing up", or poor spacing around punctuation, etc., then the right  
way to deal with this is to fix the font (or pressure the designer or  
vendor into fixing the font!) rather than creating a new layer of  
software that effectively patches the font on-the-fly by overriding  
aspects of it.

Of course, I realize this isn't always so easy; it may be a  
proprietary font and the vendor may be unwilling to fix it. So I can  
understand the desire to have a way to "extend" or "patch" font  
behavior without actually touching the font -- I just can't shake off  
the feeling that it's not the clean or correct way to address many of  
these issues. If the vendor of font "X", which has poor spacing or  
lacks certain features, won't correct or update it, then consider  
finding a better font!

One of the things I worry about is that we could end up with a  
horrendous level of complexity in all this, which is one of the  
things about TeX (and more so, Omega) that scares people off and  
prevents many users making use of the tools that they have in front  
of them.

Now, all this doesn't mean it can't or won't ever happen; but I do  
think it's a large and very wriggly can of worms. There are several  
things I might consider implementing at some point:

1. Support Omega-like font metrics files (i.e, extended beyond 8  
bits), allowing traditional TeX-style processing of large fonts. This  
means the platform font becomes merely a source of glyph shapes; all  
layout is controlled by the separate font metrics file. (This is also  
a component of Unicode math support.)

2. Some way to provide replacement tables that override some of those  
in a TrueType/OpenType font. For example, use an existing OpenType  
font, but do layout using a separately-provided 'kern' table rather  
than the one in the font. (Of course, this means that to modify  
things, you need the tools/knowledge to build OpenType tables. But in  
principle, that's no worse than having to build .ofm and .otp  
files....) This allows you to "patch" various aspects of existing  
fonts, but it means that if you want to patch one detail (e.g., add a  
new kern pair), you have to re-create (without illegally copying from  
a proprietary font!) all the existing behavior in that table.

3. The most interesting, but also most difficult to design, would be  
a way to use all the existing information in the font, and yet *also*  
allow extension via additional, external tables. Understanding and  
managing all the potential interactions is going to be interesting,  
to say the least....

I predict, though, that the number of people who'd actually learn how  
to make effective use of such mechanisms will be extremely small --  
and I wonder whether it's really the right place to spend significant  
development resources.

This is separate from a couple of other issues, which I definitely  
think are worth doing, though I haven't worked on them at this point:  
supporting .vf files, so that existing (especially math) font setups  
that require .vf can be used (this is a fairly simple extension); and  
supporting true Unicode-encoded math via extended mathchar, etc.,  
codes and new, Unicode-based math font metrics (this, as I've said  
before, is a larger project).

Jonathan