[XeTeX] XeTeX maintenance

[David Carlisle]

On 27 April 2015 at 01:05, Douglas McKenna <doug at mathemaesthetics.com>
wrote:

> Joseph Wright wrote:
>
> > \def\"{0}\expandafter\def\csname^^^^^00022\endcsname{1}
> > \ifnum\"=0 \message{tex82}\else\message{newstuff}\fi
>
> When I implemented a Unicode escape sequence extension using double-caret
> notation in the JSBox TeX-language interpreter I've been working on (which
> is all 21-bit Unicode internally, all the time, but can be configured at
> run-time to be 8-bit input only), I was unaware of what XeTeX had
> implemented, so I just used
>
> ^^uxxxx (for 16-bit, BMP codes)
> ^^Uxxxxxx (for all 21-bit Unicode code points)
>
> Seemed straightforward enough.
>

Introducing incompatible syntax for functionality shared across Unicode TeX
extensions
is a major headache for package authors. Please don't use this syntax!

>
> In the first case, if any one of the four 'x's is not a lowercase hex
> digit, interpretation reverts to the standard TeX escape sequence ^^u
> (ASCII '5'), followed by four input characters, at least one of which is
> not a hex digit.  Similarly for the six hex digit case, for whatever
> character ^^U converts to, if at least one of the six characters following
> is not a hex digit.
>

In the abstract this isn't an unreasonable syntax but ^^^^,^^^^^,^^^^^^ has
been in use for years
in xetex and luatex.

>
> Given that the number of TeX input files using ^^u is likely miniscule,
> and the number of those that follow the ^^u or ^^U with four or six hex
> digits is even smaller, it seemed like a worthwhile benefit vs. cost,
> compatibility-wise.  Maybe there's something I've not thought out well.
>

Incompatible syntax makes supporting cross platform formats like latex much
more difficult than it would otherwise be,


>
> This discussion I just found is both pertinent and frightening, I suppose:
>
> http://stackroulette.com/tex/62725/the-notation-in-various-engines


that's old and relates to old bugs isn't it?

>
>
>
> Doug McKenna
>
>
>
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20150427/b9c5d032/attachment.html>