Re: [XeTeX] Producer entry in info dict
On Wed, Feb 29, 2012 at 12:24:11AM +0100, Zdenek Wagner wrote: > 2012/2/28 Ross Moore : > > > > On 29/02/2012, at 8:44 AM, Heiko Oberdiek wrote: > > > >> ... > > > > BTW, what about the /CreationDate and /ModificationDate ? > > Surely these should be set automatically too ? > > Doesn't pdfTeX have the means to do this? > > > Both /CreationDate and /ModDate can be added by macros and both are > required by PDF/X. PdfTeX adds both automatically including the time > zone. Dvips adds none, thus my zwpagelayout package adds them if dvips > is used. TeX does not supply at a macro level the time zone, so that > the time zone is not used. Xdvipdfmx sets /CreationDate only and > zwpagelayout sets /ModDate. The problem is that /CreationDate set by > xdvipdfmx contains time zone while /ModDate set by the macros does > not. Time information without a time zone is considered UTC. Depending > on the user's time zone upon PDF/X validation it may be reported that > the file was modified before it was created. This kind of trouble is the reason for pdfTeX's \pdfcreationdate. It expands to the string that pdfTeX uses in the info dictionary including the time zone. It can also be used in DVI mode. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Producer entry in info dict
On Wed, Feb 29, 2012 at 09:57:04AM +1100, Ross Moore wrote: > 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:2012010100Z)% > >/ModDate(D:2012010100Z)% > >/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? What's wrong with meantioning "XeTeX", for example? Another reason: PDF/A requires that the information date are duplicated in the XMP part. If a package like hyperxmp tries to write the data as XMP, then it has no chance to know the /Producer value. > The author chooses his workflow, and should pass this > information on to the appropriate package ... He can't. > > 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. That's needs implementing clearvoyance. The (x)dvipdfm(x) driver is running *AFTER* the TeX processing part. > I know that one processor cannot know in advance how its output > will be further processed, but that is not the point of XMP. Then the (x)dvipdfm(x) driver must also fix the producer entry in the XMP part. Changing it only in the information dictionary violates a requirement for PDF/A. > 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 Yes, there are users that detect that the intended producer entry is *NOT* the one that gets written in the final PDF and writing bug reports. > --- if complete > validation against an existing standard is of any importance. Violation against PDF/A, for instance. > > 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. There is no reason that the trivial stuff (pdf information entries) should not be working. > 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. I don't see any reliable way. Even if you say good bye to TeX and do the stuff by a program that fixes the PDF file afterwords, there is no warning or hint that the PDF file generated by XeTeX is wrong. You can't expect from a user that he knows how to get the version information of xdvipdfmx. He calls XeTeX and usually does not even know that he is indirectly running xdvipdfmx. Also the producer strings change from driver to driver and from version to version. Also several instances of a driver can be installed: There is no way to catch the difference between xetex -output-driver=xdvipmdfx078 and xetex -output-driver=xdvipdfmx100 at TeX macro level. > With PDF/A and PDF/UA the PDF file is not supposed to be > compressed, s/PDF file/PDF information dictionary/; With XeTeX you need a command line like: xetex -outputdriver='xdvipdfmx -V4' With pdfTeX/LuaTeX the necessary settings can be done at macro level and therefore put in a package without bothering the user with low level stuff. > BTW, what about the /CreationDate and /ModificationDate ? > Surely these should be set automatically too ? pdfTeX: /CreationDate and /ModDate are set automatically unless they are specified by the user. (x)dvipdfmx: /CreationDate is set automatically, /ModDate is not set unless they are specified by the user (see test file). The same would be nice for /Producer, easy to implement and document. > Doesn't pdfTeX have the me
Re: [XeTeX] Producer entry in info dict
2012/2/28 Ross Moore : > Hi Heiko, > > On 29/02/2012, at 8:44 AM, Heiko Oberdiek wrote: > >> Hello, >> ... > > BTW, what about the /CreationDate and /ModificationDate ? > Surely these should be set automatically too ? > Doesn't pdfTeX have the means to do this? > Both /CreationDate and /ModDate can be added by macros and both are required by PDF/X. PdfTeX adds both automatically including the time zone. Dvips adds none, thus my zwpagelayout package adds them if dvips is used. TeX does not supply at a macro level the time zone, so that the time zone is not used. Xdvipdfmx sets /CreationDate only and zwpagelayout sets /ModDate. The problem is that /CreationDate set by xdvipdfmx contains time zone while /ModDate set by the macros does not. Time information without a time zone is considered UTC. Depending on the user's time zone upon PDF/X validation it may be reported that the file was modified before it was created. -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Producer entry in info dict
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:2012010100Z)% >/ModDate(D:2012010100Z)% >/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