[XeTeX] XeTeX 0.4 available

[Jonathan Kew]

On 21 Apr 2004, at 11:50 am, Hans Hagen wrote:

> At 11:14 21/04/2004, Jonathan Kew wrote:
>> Very good, Bruno, I think you got everything (except that XeTeX isn't 
>> responsible for the xmltex link that your ls shows!)
>>
>> Hans, I'd have thought that after a normal install, "which xetex" and 
>> "kpsewhich xetex.pool" should have located things for you, unless 
>> your default path doesn't find the tex binaries.
>
> The problem is that i don't use the normal tetex setup (so, no tex 
> under user and so); i run multiple trees and have my own setup.
>
> (btw, it would be handy if texshop had an option for handling that: 
> running a shell script before each run that initializes my own tree 
> setup)

I think you should be able to do this using the "Personal script" 
options; instead of putting "xetex" as the name of the "TeX program", 
for example, you'd put the name of a shell script of your own, which 
can do your setup and then call the actual tool.

>
> Thanks for all the answers (bruno, ross, etc). I now know a few more 
> apple tricks and can make a context format -)
>
> Just wondering: how about making dvipdfmx xetex aware? that would give 
> a lot of pdf goodies.

My guess is that it wouldn't be all that easy to merge the XeTeX AAT 
font support stuff with existing tools such as dvipdfmx (or pdfTeX) 
that write their own PDF. In order to get AAT font behavior, we have to 
hand strings off to ATSUI TextLayout APIs. So xdv2pdf doesn't really 
know anything about PDF generation; it knows how to render in a Quartz 
graphics context (using ATSUDrawTextLayout and similar functions), and 
it simply requests a graphics context with a PDF destination. But that 
means the whole PDF-writing process isn't really in my hands, it's deep 
inside CoreGraphics.

I suppose it would be possible to create the ATSUI layout objects and 
then retrieve the final laid-out glyph arrays, and then incorporate 
these into a PDF stream being generated directly by the tool rather 
than by CoreGraphics. But this would be a considerably more complex 
job, and one that I don't have the PDF expertise (or the time) to get 
involved with at the moment. If somebody is keen to try developing an 
alternate xdv-to-pdf tool (or extending an existing dvi-to-pdf one) 
along these lines, though, I'd be happy to talk further about it.

>  Also, with regards to supporting things like this:
>
> - \pdffile is a bad name, since it may exist in macro packages, so: 
> \xtxpdffile (xtex is taken by generic pdftex extensions)
> - same for \picfile: \xtxpicfile

How do other people feel about command names for extensions like this? 
In principle, of course, any name might exist in macro packages, but 
using a prefix like that would obviously make clashes much less likely. 
But on the other hand, these are commands that users may actually type 
at times, and it's more pleasant to use (IMO) if such commands have 
"natural" names.

Not all extensions have historically used such prefixes. For example, 
MLTeX gave us things like \charsubdef, not \mlxcharsubdef; and e-TeX 
gave us \currentgrouptype, \fontcharwd, and even \middle (easy to 
imagine that in someone's macros).

I'm not strongly committed one way or the other on this; I'm certainly 
willing to consider changing the names at this stage. I'd be glad to 
hear other opinions.

>
> It may be there (i didn't look inti the pool file yet):
>
> - \xtxversion is needed as well

Yes, that would be a good idea. Expect it shortly! :-)

Jonathan