[XeTeX] xetex.def

[Joseph Wright]

Hello all,

Following a bug report for (x)dvipdfmx box scaling, we are talking a
look at xetex.def and dvidpfmx.def to fix that and related issues. This
raises a question: what is the reason for having two .def files here. A
quick test suggests that XeTeX (xdvipdfmx) can happily use dvipdfmx.def
with the exception of a few lines at the end of the file: those could
easily be made conditional.

Reading over the comments, I see some about the older non-xdvipdfmx
drivers for XeTeX, but these are as far as I know no longer in use
(particularly for anyone likely to use an updated .def file). Are there
any particular reasons that XeTeX needs a separate driver today?

Joseph


--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

[Akira Kakuto]

Dear Joseph,

Post by Joseph Wright
Following a bug report for (x)dvipdfmx box scaling, we are talking a
look at xetex.def and dvidpfmx.def to fix that and related issues. This
raises a question: what is the reason for having two .def files here. A
quick test suggests that XeTeX (xdvipdfmx) can happily use dvipdfmx.def
with the exception of a few lines at the end of the file: those could
easily be made conditional.

I'm not familiar with the drivers, but I think that the independent
xetex.def is definitely needed.

I think that images png, jpg, pdf, are efficiently embedded in XeTeX,
probably by using primitives, while dvipdfmx requires an external
program extractbb to obtain sizes of the images.

For example,

%
% xelatex test.tex (xetex.def)
%
\documentclass[12pt]{article}
\usepackage{graphicx}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={1-9}]{xtst.pdf}
\end{document}

is far faster than

%
% xelatex test.tex (dvipdfmx.def)
%
\documentclass[12pt,dvipdfmx]{article}
\usepackage{graphicx}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={1-9}]{xtst.pdf}
\end{document}

Best,
Akira



--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

[Joseph Wright]

Post by Akira Kakuto
Dear Joseph,

Post by Joseph Wright
Following a bug report for (x)dvipdfmx box scaling, we are talking a
look at xetex.def and dvidpfmx.def to fix that and related issues. This
raises a question: what is the reason for having two .def files here. A
quick test suggests that XeTeX (xdvipdfmx) can happily use dvipdfmx.def
with the exception of a few lines at the end of the file: those could
easily be made conditional.

I'm not familiar with the drivers, but I think that the independent
xetex.def is definitely needed.
I think that images png, jpg, pdf, are efficiently embedded in XeTeX,
probably by using primitives, while dvipdfmx requires an external
program extractbb to obtain sizes of the images.
For example,
%
% xelatex test.tex (xetex.def)
%
\documentclass[12pt]{article}
\usepackage{graphicx}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={1-9}]{xtst.pdf}
\end{document}
is far faster than
%
% xelatex test.tex (dvipdfmx.def)
%
\documentclass[12pt,dvipdfmx]{article}
\usepackage{graphicx}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages={1-9}]{xtst.pdf}
\end{document}
Best,
Akira

Image inclusion is one I'd looked at, and certainly there is some
benefit from using the primitive for bounding-box lookup. However, that
doesn't mean that the entire .def files have to be different: for
example, we might pull them 'back together' in a .dtx and have only the
image inclusion bit varying. Other operations (scaling, rotation, colour
support, ...) seem to be addressable using common code, and indeed final
image inclusion (as opposed to BB extraction) could be done using a
common path for the shared data types (probably though as the BB lookup
is separate one should stick to the primitives in XeTeX).

So the question is what are the _essentials_ of the difference: really
it's about 'how much difference do we need to look after in the .def files'.

Joseph




--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

[Joseph Wright]

Post by Joseph Wright
So the question is what are the _essentials_ of the difference: really
it's about 'how much difference do we need to look after in the .def files'.

I should add that the question arose as dvipdfmx.def and xetex.def
currently use different approaches to colour. The reasons are I think
historical: xdv2pdf didn't support the dvipdfmx approach, but xdvipdfmx
does. For maintenance *today* it would be clearer if we had a simple way
of knowing which parts have to be different between the dvipdfmx and
xetex drivers.

Joseph



--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

[Karl Berry]

what is the reason for having two .def files here.

I can't imagine an insurmountable technical reason for having two
independent .def files these days. Indeed, it would seem highly
desirable to me to merge them, with conditional parts as needed. It sure
was a pain to be applying changes to both independently, when I was
the one doing that. One of the reasons I was so happy to turn them over
to you guys :).

As I expect you know, they currently exist separately because of their
historical development. xetex.def was based on dvipdfmx.def at the time
of creating XeTeX. And that was reasonable during active XeTeX
development. And so it has continued to the present day. But nowadays,
when dvipdfmx and xdvipdfmx themselves have been (sort of) merged
(thanks always to Khaled ...), merging the .def files too seems good.

--thanks, karl.


--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex

[Joseph Wright]

Post by Joseph Wright
what is the reason for having two .def files here.
I can't imagine an insurmountable technical reason for having two
independent .def files these days. Indeed, it would seem highly
desirable to me to merge them, with conditional parts as needed. It sure
was a pain to be applying changes to both independently, when I was
the one doing that.

'Yes'

Post by Joseph Wright
One of the reasons I was so happy to turn them over
to you guys :).

Well the ideas originate from the team ... you'll see for expl3 we've
gone back to 'one definite source' as the number of drivers is nowadays
small and predictable.

Post by Joseph Wright
As I expect you know, they currently exist separately because of their
historical development. xetex.def was based on dvipdfmx.def at the time
of creating XeTeX. And that was reasonable during active XeTeX
development. And so it has continued to the present day. But nowadays,
when dvipdfmx and xdvipdfmx themselves have been (sort of) merged
(thanks always to Khaled ...), merging the .def files too seems good.

OK, I'll probably work on this but not before TL'17 release: somewhat
risky and not something I'd want to put on the DVD. (I will send the
latest update to CTAN to fix the issue concerning scaling of links.)

Joseph



--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex