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.mo...@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 ------------------------------------------------------------------------ -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex