[XeTeX] The future of XeTeX

[Heiko Oberdiek]

On Tue, Jul 31, 2012 at 01:02:04PM +0200, Peter Dyballa wrote:

> 
> Am 31.07.2012 um 01:19 schrieb Zdenek Wagner:
> 
> > Yes, I know. Similarly as XeTeX can set \pdfpageheight and
> > \pdfpagewidth (or use \special{papersize=...}) there might be a
> > similar \special for setting PDF version and compression but such
> > \special's do not exist.
> 
> For very good reason! "\pdfminorversion" is not only some monadic number,
> it's also a guarantee that this document conforms to a particular
> standard. XeTeX cannot guarantee that this will be true in the future

No, XeTeX/xdvipdfmx do *NOT* (never in past, present and probably future)
analyzes the PDF data structures that it writes in order to
determine the correct PDF version number. They have no clue what
the correct PDF version would be.

\pdfminorversion does *NOT* say the PDF will be in the specified
format, it merly writes the number in the header.
But *others* can query the number already in the TeX job!
Thus a package for rich annotation media stuff can *see*
a requested version number of PDF-1.2 and say, ``Ooups, sorry,
I can't work with oder PDF versions'' (defensive politics), or
force a higher version number if possible (aggressive politics).

Keep in mind, the PDF file in the PDF world is constructed by
many parties:
* Compiler/driver itself and its features (usually destinations,
  annotations, bookmarks, ...)
* Macro software that implement some features using
  generic interfaces (\pdfobj, \special{pdf:...}, ...)
* The user by choosing the features.

The compiler (XeTeX, pdfTeX) is only responsible for their own
stuff. For example, pdfTeX complains if object streams are
requested with versions smaller 1.4.

If you want a more reliable version number, then all that
parties have to work together. Also some kind of
version management would help that mediates the 
conflicting requests:
* Use of features that need higher numbers.
* Restrictions for lower numbers such as compatibility or PDF/A.

pdfTeX, XeTeX, dvipdfm are too much cooled down for adding such
a system at the compiler/driver level. But the TeX world
is used to manage things at macro level (e.g. register management
in plain or LaTeX formats). But managing is pointless if there
is no control over the things that are managed.
* pdfTeX :-) because of \pdfminorversion.
* XeTeX: :-( annoying.

XeTeX and any other TeX compiler that I know have ever and probably
will be garantee that the version number that they have written
has something to do with the PDF file!

> \pdfpageheight and \pdfpagewidth are alternatively set to allow the XDV to
> \PDF convertor perform its job properly.

The same is needed for the PDF version. On the XeTeX side the same
mechanism could be used.

> > It is more difficult to create PDF/X
> > compliant file because I have to create XDV and then specify the PDF
> > version when calling xdvipdfmx but pdftex can set it directly.
> 
> Pdftex is the creator of the PDF file. It can assure certain things easily.

It makes the information flow easier. PdfTeX does not need
to serialize the date in an intermediate file because the
driver unit can use the data directly. But that is not an exuse
for XeTeX, just a few more bytes for the PDF version could
be added to the intermediate file. And the driver side (xdvipdfmx)
just need a function to read it from there.

Yours sincerely
  Heiko Oberdiek