Re: XeTeX 1.0 - request for comments

18/10/2005, 8pm - Jonathan Kew wrote:

> 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.

This is true, but sadly I feel it is a little too much of an  
idealistic view of the world :)

> 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!

Having remarked as above, though, I agree with what you're saying.
It would surprise me if any font vendor starts putting in variable  
spacing around punctuation in their OpenType tables, although that  
problem can be solved with active characters I suppose...

> 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.

Well, people *would* use Omega if it wasn't crippled by bugs in the  
released version, and if it wasn't effectively stagnant; if v2.0 is  
released ever it might spur the macro writers on again. Aleph has had  
a decent response from at least one major package writer, to the best  
of my knowledge (the mem project for the next generation babel; it  
was originally lambda in Omega).

All you need is a core of talented individuals to create an  
abstraction over the complexity of the original program before users  
will enjoy it. Cf. LaTeX over TeX, PSNFSS over \font, \fontspec over  
\font :), etc.

> <snip>
> 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....

This is definitely the only interesting option from my (limited)  
point of view. If you're going to implement Omega's functionality,  
why don't we just use Omega? (Give or take, the argument isn't that  
simple.)

> 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.

I agree with both statements, but the first relates back to my  
earlier point: only a few need to understand the full complexity  
until they make things easier for everyone else.

> 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).

If \mathchar could be extended relatively easily, I think we'll be  
able to "fake" simple maths relatively easily with extra macros.  
Access to the glyphs will be enough for some people, but we may as  
well wait until the STIX fonts come available, since even with  
extended maths support, it won't do us that much good besides  
bastardising the glyphs in Lucida Grande and Apple Symbol, say.

Will