Re: XeTeX 1.0 - request for comments

On 17 Oct 2005, at 9:46 am, Bruno Voisin wrote:

> Le 14 oct. 05 à 22:56, Jonathan Kew a écrit :
>
>
> > There are a few issues I know of already, so I'll mention those  
> > and save you the trouble. Most are things that I'm already pretty  
> > sure *won't* be done right now:
>
> The two issues that immediately came to my mind are precisely two  
> of them, alas!

Somehow this doesn't really surprise me! Sorry about that--but don't  
give up hope, see below:

> > b. Lack of .vf support in the output driver. Not a high priority  
> > for me, but I realize it further limits the selection of math  
> > fonts you can use. The other major use for .vf's relates to  
> > supporting various 8-bit font encodings, which should be a non- 
> > issue in the Unicode world; if you need to use all those  
> > traditional TeX fonts, then just use a traditional TeX!
>
> VF support would be a major bonus, allowing people to use the  
> various PS math fonts packages, such as mathptmx mathpazo etc. In  
> this way we could have math fonts looking better than CM when  
> combined with the various OS X fonts used for text thanks to XeTeX.  
> I don't have this kind of problem myself, being lucky enough to own  
> the Lucida fonts which don't require VF font features and blend  
> well with the OS X fonts, but I imagine for other people it's a  
> limitation.

You're absolutely right, of course; CM math doesn't really go very  
well with most of the text fonts we might like to use. Personally, I  
have the simplest of all solutions: I'm not a mathematician (or  
physicist, or...) and I don't need to write math! :)

For the occasional fragment that I have needed, I tend to give Euler  
a try; to my eye, that often works quite well. But I know some people  
don't care for it.

However, adding VF support would not actually be *that* difficult, if  
there's a programmer out there who'd care to do it. It requires  
absolutely no change in the xetex processor itself, only an extension  
of xdv2pdf, which is a relatively small and simple tool. The code is  
pretty messy, I admit, as it was thrown together in a hurry and kind  
of evolved as the whole project grew, but if someone wants to attempt  
it, I'd be happy to point them in the right direction.

The alternative (and the path that I expect to take in the longer  
term) is to replace xdv2pdf with a new back-end based on dvipdfmx,  
extended to support XeTeX features; this is part of the strategy I  
have in mind for taking XeTeX to other platforms, and will also have  
the benefit that we'll inherit all the existing driver features  
(like .vf support, better hyperref support, etc.).

> > f. Proper individual character metrics when using native OS X  
> > fonts. This is harder than it sounds, as TeX wants to know height,  
> > depth, and italic correction for each character, and this  
> > information is not present in fonts, only in .tfm's. And it can't  
> > be derived accurately from the glyph outlines, either.
>
> It's this problem which has prevented me so far to use XeTeX for  
> all things TeX (I don't really mind about the speed issue with  
> XeTeX compared with standard TeX). As soon as you're typing math in  
> XeTeX, especially with subscripts and superscripts, or even  
> changing fonts in the middle of a line (such as including a  
> character from Lucida Grande -- e.g. an arrow -- in text written in  
> Optima), you end up with irregular baselineskips, exactly as when  
> mixing characters from Times and Symbol in old word processors like  
> MacWrite Pro (maybe it's still the same in MS Word, I haven't tried).
>
> As a result, to get aesthetically acceptable output, I have had to  
> use tricks such as setting (in XeLaTeX) \baselinestretch to 1.2. I  
> know the problem can be partly solved by changing \lineskiplimit to  
> negative value, but I don't consider it a satisfactory fix as it as  
> it alters the spacing before and after displayed equations as well.

This is less likely to get "solved" via a small amount of work, as  
(a) it's unclear exactly what the right approach would be, given that  
the fonts don't offer the precise information that's wanted in TeX;  
and (b) having decided on the approach, it'll require XeTeX to do  
some pretty low-level digging around in the fonts (of various  
flavors) to actually find information that could be used to improve  
the behavior.

I think that in general, it should be possible to tune the output by  
use of a combination of the line-spacing parameters; the trouble is  
that the ascent and descent values in most fonts are large enough  
that people often end up (without knowing it) setting the text  
"solid", so that \baselineskip is ignored in favor of \lineskip; and  
then it's very likely that any font change or vertically-shifted  
character will disrupt the spacing.

The right solution, I think, is to set \lineskiplimit sufficiently  
negative (often several points) that all regular text can be set with  
\baselineskip, yet not so negative that it fails to kick in for  
extreme cases of large characters (or images, etc) in the line. You  
might also want \lineskip to be slightly negative, to get the proper  
spacing in the cases when \lineskiplimit is reached (if your fonts  
already have some spacing "built in" to the metrics).

Then, if necessary, adjust \above(short)?displayskip and  
\belowdisplayskip to adjust the spacing around displayed equations.

How one expresses all this in LaTeX terms is something I leave for  
the LaTeX users to figure out... :)

Thanks for the message; it's helpful to know which things people care  
most about. I'll keep thinking about them.

JK