[XeTeX] XeTeX 0.4 available

[Hans Hagen]

At 12:06 22/04/2004, you wrote:

>  dvipdfmx  was quite new at the Hawaii meeting, yes ?
>I've not worked with it yet.

not that new; long before that i mailed with the authors who picked up 
where dvipdfm had stopped (cjk support to start with); the authors wanted 
to make sure that all tricks were supported, and today (at least from the 
perspective of context) dvipdfmx is pdftex compatible in (pdf) functionality

>Now that XeTeX has proved the usefulness of interacting with Quartz
>to typeset with some fonts, and include various graphics formats,
>then the best way ahead may be to graft those features onto pdfTeX
>(when used on a Mac), rather than rework all the other features
>into an extended XeTeX.

this makes sense and since thanh is in the process of upgrading ... if the 
xetex extensions can be expressed in a change file it would be nice; thanh 
has xpdftex as experimental extensions engine so ...

>Yes, but surely this is true only when you have a "call-back" such as
>  \pdflastobject  so that you can save the number and use it,
>to be referenced while building other objects.

or symbolic refs like in dvipdfmx: @thisorthatobject

>With XeTeX's 2-part structure of
>          page-building:  .tex ---> .xdv

eh .. not that impossible: think of:

\special{startpdfobject name @whatever} ..... \special{endpdfobjext}

as constructor, after which there can be refs like:

\special{..... @whatever  }

this is not that different from the new pdftex forward object refs (reserve 
numbers) mechanism

>then a separate
>          PDF encoding:   .xdv ---> .pdf
>this is impossible.
>  pdfTeX  can do it because it keeps track of the object IDs
>while it is interpreting what needs to go on the pages.

sure, but a dvi processor can do that as well; so far i have not seen 
pdftex specific features that cannot be done in dvi+postprocessing as well, 
apart from the fact that pdftex is a one pass adventure which is quite nice 
when you have to produce 450 megabyte files

>The reason 'pdfmark' can cope with this situation is that there
>is a mechanism to assign a symbolic ID to an object, and use that
>for references to the object. These symbolic IDs get replaced later
>when the correct numbers are known --- similar to LaTeX's
>\label-\ref mechanism, but using different programs to encode
>the symbolic reference, and later do the resolution.

indeed, which can be done in specials as well; interpreting pdfmarks and 
then using some resolving mechanism is not different from interpreting 
(simpler) specials and doing the same

>I've not worked with that yet.
>How does it cope with PDF objects needing to reference each other ?
>It would need to be symbolically, similar to above.

indeed (see previous comment); works quite well (the authors made sure that 
it could do all the context trickery, so it really covers all these things)

Hans