gnuplot eps figures overwrite latex hyperref settings

[Martin Mohr]

Hello,

I am using Gnuplot 4.2 patchlevel rc4 CVS-23Jan2007.

I generate eps files (using term post enh eps) and include them into my
LaTeX files. From the LaTeX I generate postscript (dvips -q -P pdf -t
a4) and convert it to pdf (ps2pdf14). In my LaTeX document I use the
hyperref package to set things like pdfsubject etc.

However, the eps figure generated by gnuplot contains fields like
/Subject (gnuplot plot), which overwrite my hyperref settings and appear
as subject etc. in the final pdf document.

This is new behaviour of the 4.2 version. I guess it is useful if the
eps figure itself is to be converted to pdf, but in my case it is not.
Is there a way to avoid this?

Thanks
Martin

[Ethan Merritt]

In article <erur4s$kik$1...@news.lrz-muenchen.de>,

Martin Mohr <marti...@gmx.de> wrote:
>
>I generate eps files (using term post enh eps) and include them into my
>LaTeX files. From the LaTeX I generate postscript (dvips -q -P pdf -t
>a4) and convert it to pdf (ps2pdf14). In my LaTeX document I use the
>hyperref package to set things like pdfsubject etc.
>
>However, the eps figure generated by gnuplot contains fields like
>/Subject (gnuplot plot), which overwrite my hyperref settings and appear
>as subject etc. in the final pdf document.

In the case of pdf output, the "/Subject" tag is added by the PDF_set_info
routine of pdflib. In the case of postscript output, this same tag is
added in the pdfmark section. This is all according to standard for PDF,
so far as I know. But yes, it was added to gnuplot since version 4.0.

So you're saying that a tag in an embedded figure is over-riding a
global tag in the LaTeX document? That sounds like a bug in the LaTeX
processing package, not anything in particular to do with gnuplot.
The same thing would presumably happen for any imported figure
containing such a tag, be it *.eps or *.pdf. Do I have that right?

>This is new behaviour of the 4.2 version. I guess it is useful if the
>eps figure itself is to be converted to pdf, but in my case it is not.
>Is there a way to avoid this?

File a bug report against hyperref, maybe?
Although I suppose it is possible that the confusion actually occurs
at the level of the pdf viewing program. I could imagine that in the
case of multiple embedded tags, the final one encountered would be left
showing in the title window. Did you try more than one viewer?

--
Ethan A Merritt

[Martin Mohr]

Ethan Merritt wrote:

> In the case of pdf output, the "/Subject" tag is added by the PDF_set_info
> routine of pdflib. In the case of postscript output, this same tag is
> added in the pdfmark section. This is all according to standard for PDF,
> so far as I know. But yes, it was added to gnuplot since version 4.0.
>
> So you're saying that a tag in an embedded figure is over-riding a
> global tag in the LaTeX document? That sounds like a bug in the LaTeX
> processing package, not anything in particular to do with gnuplot.
> The same thing would presumably happen for any imported figure
> containing such a tag, be it *.eps or *.pdf. Do I have that right?
>

> File a bug report against hyperref, maybe?
> Although I suppose it is possible that the confusion actually occurs
> at the level of the pdf viewing program. I could imagine that in the
> case of multiple embedded tags, the final one encountered would be left
> showing in the title window. Did you try more than one viewer?

gv shows the same (wrong) title as Acrobat Reader. It is indeed the title of
the last figure in the document (not really, it's the filename). I don't
know any other pdf viewers that allow to look at these properties.

I don't know if the same problem would occur if the tags in question were
added to another eps. Presumably yes. My other eps files don't seem to
contain such tags.

There is no chance to disable this pdfmark section somehow? I find it a bit
annoying that my thesis in now entitled "ovc_2_060321.eps". But since I'm
filtering the eps files anyway to adjust the bounding box, I will just cut
that section. After I figured that postscript out...

Ciao
Martin

[Ethan Merritt]

In article <ervouc$2bj$00$1...@news.t-online.com>,
Martin Mohr <marti...@gmx.de> wrote:

>Ethan Merritt wrote:
>
>> So you're saying that a tag in an embedded figure is over-riding a
>> global tag in the LaTeX document? That sounds like a bug in the LaTeX
>> processing package, not anything in particular to do with gnuplot.
>> The same thing would presumably happen for any imported figure
>> containing such a tag, be it *.eps or *.pdf. Do I have that right?
>>
>> File a bug report against hyperref, maybe?
>> Although I suppose it is possible that the confusion actually occurs
>> at the level of the pdf viewing program. I could imagine that in the
>> case of multiple embedded tags, the final one encountered would be left
>> showing in the title window. Did you try more than one viewer?
>
>gv shows the same (wrong) title as Acrobat Reader. It is indeed the title of
>the last figure in the document (not really, it's the filename). I don't
>know any other pdf viewers that allow to look at these properties.

I can't reproduce your problem here. Consider, for example, the LaTeX
tutorial that is part of the gnuplot distribution. The LaTeX document
includes the file eg7.eps (or eg7.pdf). Both eg7.eps and eg7.pdf
contain the "/Subject (gnuplot plot) /Title (eg7.tex)" tags.
But when "make tutorial.pdf" invokes
pdflatex tutorial
to produce a pdf document, that document does _not_ inherit the /Subject
or /Title from eg7.eps
I confirmed this using the Acrobat reader, gv, and kpdf.

So I suspect the problem is in your LaTeX->pdf conversion tool,
rather than in the contents of the component files.

--
Ethan A Merritt

[Martin Mohr]

Ethan Merritt wrote:
> So I suspect the problem is in your LaTeX->pdf conversion tool,
> rather than in the contents of the component files.

Thank you for your comments. I agree that probably my tool chain
(dvips->ps2pdf) is responsible. I don't use pdflatex, mostly for
historical reasons, and it is too late now to switch. I'll work around
the problem.

Ciao
Martin

[gual...@gmail.com]

Hi Martin,
I encounter the same problem you do. I think this should be reported
as a dvips bug, because it is the latter "pdfmark" the one that takes
precedence.
Also, pdflatex is not the only means to avoid the problem. If you use
dvipdfmx (which only requires to add the global option dvipdfmx, and
configuring the program to use, e.g., gs as ps->pdf converter), things
are also fine.
Gual

[Robert Whittaker]

I'm getting this too, with an epslatex graph in a LaTeX document with
LaTeX -> DVI -> PS -> PDF conversion. My understanding of the issues
and causes is as follows...

>From the LaTeX side, the code just adds a \special to the dvi file to
write out a pdfmark block in the postscript file, which then sets the
file-info when converted to a pdf. Unforunately any later pdfmark
blocks present in included eps files will over-write this info during
the PDF conversion.

I'm not sure that it's reasonable to expect dvips to drop pdfmark
blocks in included eps files, nor to expect ps2pdf to ignore later-
encountered pdfmark block from within included eps files. I don't know
that there's any way of saying that a particular pdfmark block should
take precedence. I image that all the conversion programs are acting
according to spec, and the issue is that the method of setting the PDF
info from within LaTeX using the \special is a bit flakey. (One kludge
that seems to work is to redefine pdfmark to do nothing at the end of
the 'correct' pdfmark block you're setting from within LaTeX. However
this might have other side-effects.)

However from a gnuplot point of view, knowing that eps files from the
epslatex termal are destined for use in LaTeX, and that there are
problems with files produced by standard tools, I think that this
should be considered a bug in gnuplot: Gnuplot knows the eps file is
likely to be included in a LaTeX document, and yet is including an
instruction which tells a ps->pdf converter that the global title of
the document should be something that it's clearly not. I think that
there should at least be an option to disable the pdfmark blocks from
the [e]ps output, and ideally this option should be activated by
default for the epslatex terminal.

Robert.

[Dan]

On Apr 11, 5:03 am, "Robert Whittaker" <robert.whitta...@gmail.com>
wrote:

> I'm getting this too, with an epslatex graph in a LaTeX document with
> LaTeX -> DVI -> PS -> PDF conversion. My understanding of the issues
> and causes is as follows...
>
> From the LaTeX side, the code just adds a \special to the dvi file to
> write out a pdfmark block in the postscript file, which then sets the
> file-info when converted to a pdf. Unforunately any later pdfmark
> blocks present in included eps files will over-write this info during
> the PDF conversion.
>
> I'm not sure that it's reasonable to expect dvips to drop pdfmark
> blocks in included eps files,

I think it would be a good idea to at least localize the definitions,
the
way the graphics state is expected to be localized in all EPS
insertions. That said, I don't know if that is, in fact, possible.

> I image that all the conversion programs are acting
> according to spec, and the issue is that the method of setting the PDF
> info from within LaTeX using the \special is a bit flakey.

It is pretty much the only possible method, and it is a reasonable
thing to do, given that pdfmark is itself a sort of special that
works
pretty much the same at the ps-->pdf step.

I think it can be argued that eps files (which are by their very
nature intended to be included in a larger document) shouldn't
be setting document-level variables in a global way. I do not
know of it is possible to localize the effect of pdfmark. If it is
not, it should be omited completely.

A work-around would be to pass a different command by \special,
then modify dvips to recognize it as something to put at the end
of the PS file.

Another alternative would be for hyperref itself to put that
information at the end. I played around with methods to do
this, but it is tricky and my understanding of hyperref and
\special was insufficient. Also, it is unclear (to me) if dvips
keeps or discards \specials on an otherwise empty page.

> However from a gnuplot point of view, knowing that eps files from the
> epslatex termal are destined for use in LaTeX, and that there are
> problems with files produced by standard tools, I think that this
> should be considered a bug in gnuplot: Gnuplot knows the eps file is
> likely to be included in a LaTeX document, and yet is including an
> instruction which tells a ps->pdf converter that the global title of
> the document should be something that it's clearly not.

I agree. In fact, I agree whether latex is the intended document
processor or something else.

Dan

[tanzte...@gmail.com]

I think I found a solution for the problem.

First of all:

When gnuplot generates an postscript eps file,
it writes a so called prologue into the eps document header
which is usually precompiled into the gnuplot binary.

The header of a corrupted eps file might look like this:

SNIP

%!PS-Adobe-2.0 EPSF-2.0
%%Title: history.eps
%%Creator: gnuplot 5.0 patchlevel 5
%%CreationDate: Fri Jan 19 12:15:48 2018
%%DocumentFonts: (atend)
%%BoundingBox: 50 50 410 518
%%EndComments
%%BeginProlog
/gnudict 256 dict def
gnudict begin
%
% The following true/false flags may be edited by hand if desired.
% The unit line width and grayscale image gamma correction may also be changed.
%
/Color true def
/Blacktext false def
/Solid false def
/Dashlength 1 def
/Landscape false def
/Level1 false def
/Level3 false def
/Rounded false def
/ClipToBoundingBox false def
/SuppressPDFMark false def


END SNIP


The last line causes the problem. If one replaces the last line with

/SuppressPDFMark true def

dvipdf stops to overwrite the hyperref pdfinfo settings with the information from the eps file.

One can manually modify the eps file,
but I also found a solution from within the gnuplot script file
which calls sed in order to replace the line in the output eps file 'output_filename':

gnuplot script > system(sprintf("sed -i 's/SuppressPDFMark false/SuppressPDFMark true/g' %s", output_filename));

So far I didn't figure out, how I can make gnuplot load the modified proluge file prologue.ps which usually is delivered with the gnuplot package.

In my distro file is located in

/usr/share/gnuplot/gnuplot/5.0/PostScript/prologue.ps

If anyone knows a solution for this, then no further efforts have to be spent to solve this annoying bug!

Cheers,

Tim Deutschmann

www.tim-deutschmann.de

[tanzte...@gmail.com]

Here comes the final solution!


1. locate the file 'prologue.ps'. In my distro it is in '/usr/share/gnuplot/gnuplot/5.0/PostScript/'

2. as root (or user) modify it such that it looks like this:

%
% Gnuplot Prolog Version 5.1 (Oct 2015)
%
/SuppressPDFMark true def
%

i.e. set /SuppressPDFMark to 'true' in the prologue file

3. locate the global or user specific gnuplotrc file.

4. edit gnuplotrc (as root or user) and refer to the modified prologue file by writing somewhere at the end of the file:

set psdir "/usr/share/gnuplot/gnuplot/5.0/PostScript/"

whereever it might be in your distro.

Cheers