[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