[tex-k] A few TeX live questions (xdvipdfmx, xetex, & Co)
jonathan at jfkew.plus.com
Tue Mar 3 17:29:17 CET 2009
On 3 Mar 2009, at 16:12, Peter Breitenlohner wrote:
> On Tue, 3 Mar 2009, Jonathan Kew wrote:
>> One approach would be to let the dvipdfmx repository be the
>> canonical upstream, and the xetex project would just maintain a
>> collection of patches that are applied in order to build xdvipdfmx.
>> Just like using WEB change files rather than editing the main
>> source. It's a pretty tedious way to write code, though, once it
>> gets beyond a few small, isolated changes.
> Hi Jonathan,
> that would be a nice idea because it would prevent these projects from
> diverging to much, or one lacking improvements applied to the other
> one. Unfortunately it is probably quite unrealistic, given past
> experience with
> etex, pdftex, and pdfetex.
Yes, I know. xetex, too, relies on a whole bunch of .ch files applied
to tex.web, in addition to the separate native-C extensions and the
glue that interfaces to various libraries. It's not pretty!
> The only realistic way to do such a thing might be to have the
> pieces surrounded by suitable "#ifdef"s, and even that may be painful.
Right. That's how xdvipdfmx started; but ChoF didn't want it happening
right there in the dvipdfmx repository (understandable, given the
potential for disrupting their existing product). So there was a time,
early on, when the xdvipdfmx repository was in such a state, but I'm
pretty sure I didn't manage to keep all my changes properly separated
like that, and meanwhile the dvipdfmx team continued to work in their
own repository, so that's where we are at the moment.
They're close enough that for the most part, merging changes from
dvipdfmx->xdvipdfmx is straightforward; the majority of the source
files are identical, or have only a few tiny, #ifdef-marked changes.
But there are of course a few trickier areas.
More information about the tex-k