[XeTeX] The future of XeTeX

Adam Twardoch (List) list.adam at twardoch.com
Tue Jul 31 00:08:56 CEST 2012

On 12-07-30 23:40, Philip TAYLOR wrote:
> OK, thank you Adam.  I think perhaps I was being unrealistic in
> asking whether the two PDFs would be visually identical; for the
> very reasons you adduce, it is clear that this can never be the
> case.  But differences at the syntactic level are a far greater
> concern : I think one should accept that if one passes an extant
> XeTeX source through LuaTeX, line and page breaks may well differ,
> but if LuaTeX barfs on valid XeTeX source, that is (for me, at
> least) a far greater concern (and a reason against adoption, to
> be honest).
I believe that the TeX world needs a "policy" on naming engine-specific
commands. This is akin to the CSS browser-specific prefixes, such as 
"-webkit-text-security" or "-moz-font-features". XeTeX already does
this: all the XeTeX-specific commands are prefixed with "XeTeX". Some of
those commands are of general use (in such case, the XeTeX and LuaTeX
developers should communicate to standardize a new command) while others
may really not be of general use at all, as they're more-less "hacks" or
ways to achieve certain effects in a way tied very much to the specific
implementation of the engine.

For example, there is the XeTeX command:

\XeTeXfonttype ‹font›
Expands to a number corresponding to which renderer is used for a ‹font›:
0 for TEX (a legacy TFM-based font);
1 for ATSUI (usually an AAT font);
2 for ICU (an OpenType font);
3 for Graphite.

which really is very much tied to how XeTeX works.

*** BTW: HarfBuzz has several backends, so if it gets integrated into
XeTeX, I'd advise reserving several numbers for it, e.g.:
4 for HarfBuzz native OTL
5 for HarfBuzz Uniscribe
6 for HarfBuzz Graphite ***

Many other XeTeX commands such as \XeTeXfindselectorbyname also only
make sense in the XeTeX environment.

However, I'd say -- perhaps the LuaTeX developers could create a special
"stub xetex" macro package which reimplements the XeTeX-native commands
as macros that follow the same syntax as XeTeX. Many of those macros
would not necessarily need to "work" i.e. do anything effectively -- but
at least they would be ignored gracefully rather than failing. But I
don't really know whether this is a good idea -- my knowledge of "good
practices in TeX" is close to null :) As you know, I'm not really a "TeX
person", i.e. I try to follow the developments but don't participate
actively or use TeX.



May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)

More information about the XeTeX mailing list