[XeTeX] (x)dvipdfm(x): Link rectangle problem
Hello,
the (x)dvipdfm(x) drivers fail if the link area contains
rules or images. See the following test file (can be used
with iniTeX):
\catcode`\{=1
\catcode`\}=2
\font\rm=cmr10
\rm
\count0=1
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1mm\relax
\hss
}%
\special{pdf:bann<<%
/Type/Annot
/Subtype/Link
/A<>
>>}%
\vrule width 0mm height 10mm\relax
\kern 10mm\relax
\special{pdf:eann}%
}
\count0=2
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1pt\relax
\hss
}%
\special{pdf:bann<<%
/Type/Annot
/Subtype/Link
/A<>
>>}%
a%
\vrule width 0mm height 10mm\relax
\kern 10mm\relax
b%
\special{pdf:eann}%
}
\count0=3
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1pt\relax
\hss
}%
\special{pdf:bann<<%
/Type/Annot
/Subtype/Link
/A<>
>>}%
\ifx\XeTeXpicfile\undefined
\special{pdf:image width 10mm height 10mm (s1.png)}%
\else
\XeTeXpicfile s1.png width 10mm height 10mm\relax
\fi
\special{pdf:eann}%
}
\csname @@end\endcsname\end
Instead of s1.png an existing image file should be used.
The test file test.tex is called, e.g.:
xetex --ini --etex test
tex --ini test && dvipdfmx test
The problems:
* Page 1: no link
* Page 2: the link area only covers the rectangle with "a" and "b".
The rule in between is higher than "b".
* Page 3: xdvipmx only makes a tiny link spot at the left lower corner,
no link with dvipdfmx.
BTW, setting the width of the invisible rules from 0pt to 1mm
does not make a difference.
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 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
[XeTeX] Producer entry in info dict
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
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.
Please fix this issue in xdvipdfmx.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
