[Dev-luatex] Q: Can LuaTeX produce xdv?
arthur.reutenauer at normalesup.org
Sun Jan 4 20:20:59 CET 2009
> Yes, typesetting applications need to know about included objects such as
> images (and fonts). But from there you conclude that there's a benefit in
> generating PDF directly. I don't see how this follows.
The key to understanding the “benefit in generating PDF directly” lies
in the adverb “directly”, not the noun “PDF”. We appreciate having a
single program that has all the necessary knowledge about the end
> LuaTeX does (a) and (b) at the same time.
Not at the same time, within the same program. Those actions do not
need to be carried out at the same moment, but it's useful that the
parts of the program that are responsible for them are able to
communicate with each other to exchange knowledge about the material
being typeset, without duplicating code, as Martin said.
> I see no reason why a 'special'
> that says 'do (b)' should not be written to the xdv or whatever output
Maybe it's time that we turn the question the other way round and ask
you for reasons to *do* so. What, could you please tell us, is so great
about *not* generating the end result directly that we should force
ourselves to produce an intermediate file first, and even go on about
inventing a new format, because the current extensions to DVI lack some
> [Discussion of performance snipped]
It's a pity you don't want to discuss this, because it's the only
technical advantage to producing xdv that I have seen mentioned so far.
> Well, it's not MY code, but I'm sure you're welcome to use it:
That's XeTeX's code. The LuaTeX developers are well aware of XeTeX's
existence and features, but what you may be missing here is that LuaTeX
is not XeTeX and is not destined to be, nor the other way round, for
that matter. They simply serve different purposes. Your insistence in
having LuaTeX produce xdv seems to proceed from the assumption that
XeTeX's novelty resides in xdv, which is in my opinion the wrong angle
on this issue: XeTeX's most valuable asset is XeTeX, the program,
itself, not xdv production. And xdvipdfmx, the postprocessor, doesn't
have such prominent features that couldn't be implemented within LuaTeX,
as Barry pointed out. As for LuaTeX's specific features, they would not
be very well expressed by xdv, and can be fully accounted for by
More information about the dev-luatex