[XeTeX] Producer entry in info dict
Ross Moore
ross.moore at mq.edu.au
Tue Feb 28 23:57:04 CET 2012
Hi Heiko,
On 29/02/2012, at 8:44 AM, Heiko Oberdiek wrote:
> Hello,
>
> the entries in the information dictionary can be controlled
> at TeX macro level except for /Producer:
>
> % xetex --ini
> \catcode`\{=1
> \catcode`\}=2
> \shipout\hbox{%
> \special{pdf:docinfo<<%
> /Producer(MyProducer)%
> /Creator(MyCreator)%
> /Author(MyAuthor)%
> /Title(MyTitle)%
> /Subject(MySubject)%
> /Keywords(MyKeywords)%
> /CreationDate(D:20120101000000Z)%
> /ModDate(D:20120101000000Z)%
> /MyKey(MyValue)%
>>> }%
> }
> \csname @@end\endcsname\end
Surely /Creator is (La)TeX, Xe(La)TeX, ConTeXt, etc.
while /Producer is the PDF engine:
Ghostscript, xdvipdfmx, pstopdf, Acrobat Distiller, etc.
and /Author is the person who wrote the bulk of
the document source.
Why should it be reasonable that an author can set the
/Producer and /Creator arbitrarily within the document
source?
The author chooses his workflow, and should pass this
information on to the appropriate package ...
>
> The entry for /Producer gets overwritten by xdvipdfmx,
> e.g. "xdvipdfmx (0.7.8)". Result:
>
> * Bug-reports/hyperref: pdfproducer={XeTeX ...} does not work.
> * hyperxmp is at a loss, it *MUST* know the value of the
> /Producer, because the setting in the XMP part has to be
> the same.
... via options to \usepackage[...]{hyperxmp}
and the package should be kept up-to-date with the exact strings
that will be produced by the different processing engines, in all
their existing versions.
I know that one processor cannot know in advance how its output
will be further processed, but that is not the point of XMP.
The person who is the author, or production editor, *does* know
this information (at least in principle) and should ensure that
this gets encoded properly within the final PDF --- if complete
validation against an existing standard is of any importance.
>
> Please fix this issue in xdvipdfmx.
I'm not sure that it is xdvipdfmx's duty to handle this
issue; though see my final words below.
My initial thoughts are as follows:
The nature and purpose of XMP is such that an author
cannot just \usepackage{hyperxmp} with no extra options,
and expect the XMP information to be created automagically,
correctly in every detail.
The alternative is to have an auxiliary file that contains
macro definitions, to be used both in the docinfo and XMP.
This auxiliary file needs to be created either manually,
or automatically extracting the information from a PDF,
first time it is created.
With PDF/A and PDF/UA the PDF file is not supposed to be
compressed, so automating this is not so hard --- though
it may well be platform-dependent.
(Not sure about other flavours of PDF/??? .)
>
> Yours sincerely
> Heiko Oberdiek
BTW, what about the /CreationDate and /ModificationDate ?
Surely these should be set automatically too ?
Doesn't pdfTeX have the means to do this?
Of course when it is a 2-engine process, such as
XeTeX + xdvipdfmx
then which time should be encoded here?
XeTeX cannot know the time at which xdvipdfmx will do
its work. Maybe it can extrapolate ahead, from information
saved from the previous run ?
So maybe what is really desirable is for xdvipdfmx to write
out an auxiliary file containing all relevant metadata, including
timings, that can then be used by the next run of XeLaTeX .
A \special{ ... } command could be used to trigger the need
for such an action to be performed.
Is that what you had in mind?
Hope this helps,
Ross
------------------------------------------------------------------------
Ross Moore ross.moore at mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
------------------------------------------------------------------------
More information about the XeTeX
mailing list