Thread: [PATCH] Disable PDF docinfo output for EPS

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Just in case you missed it, I recently posted a tiny patch to disable
PDF docinfo output for EPS:

  http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316

Thanks,
Ludovic.

On Friday 05 October 2007 02:36, Ludovic Court=C3=A8s wrote:
> Hi,
>=20
> Just in case you missed it, I recently posted a tiny patch to disable
> PDF docinfo output for EPS:
>=20
>   http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316

I consider the current gnuplot behaviour to be correct.
The pdfmark constuct allows passing metadata through to PDF, and
Adobe's PDF Reference, Third Edition states (Section 9):

   Beginning with PDF 1.4, metadata can also be speci=EF=AC=81ed
   for individual components of a document.

where "individual components" explicitly means such things as
embedded figures, exactly the normal use case for *.eps files.

This issue was raised previously with respect to use of
gnuplot *.eps files in TeX documents:
http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thr=
ead/5938f08fe95b0bdd/469c49b8f2bc57a8

=46rom my perspective, the ability to attach metadata to individual
plots is useful, and is handled correctly by several toolchains.
=46or example, it allows you to search for gnuplot-generated figures
inside a large PDF document.=20

ps2pdf was reported in that thread to mis-handle the metadata
association.  I do not know whether or not a bug report was
subsequently filed against ps2pdf.

On the other hand, the PDF Reference manual also allows an
alternate mechanism for attaching metadata in documnet subcomponents.
If someone wants to explore that and submit a gnuplot patch to use
the alternate mechanism, I would be happy to look at it.=20

=2D-=20
Ethan A Merritt

Hi,

Ethan Merritt <merritt@u.washington.edu> writes:

> On Friday 05 October 2007 02:36, Ludovic Courtès wrote:
>> Hi,
>> 
>> Just in case you missed it, I recently posted a tiny patch to disable
>> PDF docinfo output for EPS:
>> 
>>   http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316
>
> I consider the current gnuplot behaviour to be correct.
> The pdfmark constuct allows passing metadata through to PDF, and
> Adobe's PDF Reference, Third Edition states (Section 9):

The problem is not with PDF, but rather with the interpretation of the
`pdfmark' operator by "distiller" applications such as ps2pdf: the
"pdfmark Reference Manual" [0] does not specify how multiple instances
of an "Info dictionary pdfmark" should be handled.

Consider the following PostScript file:

  %!PS-Adobe-3.0
  %%DocumentMedia: A4 595 842 0 white ()
  %%PageOrder: Ascend
  %%LanguageLevel: 2
  %%BoundingBox: 0 0 595 842

  [ /Title (First Title)
     /Author (First Author)
     /Subject (First Subject)
     /DOCINFO
  pdfmark

  [ /Title (Second Title)
     /Author (Second Author)
     /Subject (Second Subject)
     /DOCINFO
  pdfmark

With GhostScript's ps2pdf and `pdfinfo' from Xpdf, I get this:

  $ ps2pdf ,,t.ps
  $ pdfinfo ,,t.pdf
  Title:          Second Title
  Subject:        Second Subject
  Author:         Second Author
  Producer:       GPL Ghostscript 8.56
  CreationDate:   Tue Oct  9 07:54:12 2007
  ModDate:        Tue Oct  9 07:54:12 2007
  Tagged:         no
  Pages:          1
  Encrypted:      no
  Page size:      595 x 842 pts (A4)
  File size:      2275 bytes
  Optimized:      no
  PDF version:    1.4

Which means that the second Info dictionary overrode the first.  Same
result with Acrobat Distiller:

  $ pdfinfo ,,t.acrobat-distiller-7.pdf 
  Title:          Second Title
  Subject:        Second Subject
  Author:         Second Author
  Producer:       Acrobat Distiller 7.0.5 pour Macintosh
  CreationDate:   Tue Oct  9 09:56:34 2007
  ModDate:        Tue Oct  9 09:56:34 2007
  Tagged:         no
  Pages:          1
  Encrypted:      no
  Page size:      612 x 792 pts (letter)
  File size:      5057 bytes
  Optimized:      yes
  PDF version:    1.4

Indeed, both PDF files only contain the second Info dictionary.

Including a GNUplot-generated EPS file in a PS file that already
contains its own Info dictionary marker is likely to lead to the same
situation, unless the PS file is arranged such that its Info dictionary
marker appears  after  the embedded EPS file.

It turns out that both LaTeX+hyperref and Lout (which is what I use) put
their Info dictionary marker at the beginning of the PS document; thus,
that Info dictionary gets overridden by the one present in the
included GNUplot-generated EPS files.  QED.

Furthermore, I question the usefulness of `pdfmark' in EPS files.  EPS
files are meant to be embedded, as the name implies, and probably not
converted to PDF.  Thus, `pdfmark' instances within EPS appear to be of
little use; `pdfmark' in *PS* files, OTOH, are admittedly useful, and my
patch preserves them.

Thanks,
Ludovic.

[0] http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creation_apis_and_specs/pdfmarkReference.pdf

On Tuesday 09 October 2007 01:25, Ludovic Court=E8s wrote:
> The problem is not with PDF, but rather with the interpretation of the
> `pdfmark' operator by "distiller" applications such as ps2pdf

I agree. Therefore I consider it a bug in ps2pdf.

> It turns out that both LaTeX+hyperref and Lout (which is what I use) put
> their Info dictionary marker at the beginning of the PS document; thus,
> that Info dictionary gets overridden by the one present in the
> included GNUplot-generated EPS files.  QED.

Yes, that was the original failure mode reported in an earlier bug report.

> Furthermore, I question the usefulness of `pdfmark' in EPS files.  EPS
> files are meant to be embedded, as the name implies, and probably not
> converted to PDF.  Thus, `pdfmark' instances within EPS appear to be of
> little use; `pdfmark' in *PS* files, OTOH, are admittedly useful, and my
> patch preserves them.

I beg to differ. An equally common path is to convert the individual
figures from *.eps to *.pdf and then assemble the document using
pdflatex.  The metadata in the individual *.eps pdfmark sections are
then attached to the individual figures, and can be used to navigate
the resulting composite pdf document.  At least, that's the intent.
If it's broken, let's fix it.

You may ask "in that case, why use gnuplot to create eps figures rather
than pdf figures"?  Until recently, creating pdf figures directly required
building gnuplot from source and linking against the proprietary PDFlib
library. So this path was not generally available.  In the CVS version of
gnuplot there is now an experimental cairo-based pdf terminal that may
obviate this problem. But until that matures and perhaps a corresponding
"pdflatex" terminal is written, I think it is disirable to continue to
support the inclusion of pdf metadata in *.eps output.  =20

If there is a better mechanism to do so, great.  But I'd rather fix the
problem by improving the support rather than by removing it altogether.
The pdfmark Reference you point to below gives a lot of suggestions how
to create more sophisticated tags; perhaps someone will be inspired to
modify post.trm to emit more sophisticated pdfmark sections.

=46inally, I note that the pdfmarkReference also provides a sample code
chunk to disable pdfmark interpretation by PostScript interpreters.
Now that gnuplot allows local customization of the PostScript prologue
files, perhaps the most straightforward immediate solution is for you=20
to add the code fragment to your local prologue file?  That has the
nice feature that it applies to all existing installations of 4.2;
it doesn't require rebuilding gnuplot.=20

> http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creatio=
n_apis_and_specs/pdfmarkReference.pdf

=2D-=20
Ethan A Merritt

Hi,

Ethan Merritt <merritt@u.washington.edu> writes:

> On Tuesday 09 October 2007 01:25, Ludovic Courtès wrote:
>> The problem is not with PDF, but rather with the interpretation of the
>> `pdfmark' operator by "distiller" applications such as ps2pdf
>
> I agree. Therefore I consider it a bug in ps2pdf.

As I said, the "pdfmark Reference" says nothing about such situations,
and ps2pdf is in agreement with Acrobat Distiller (the reference
implementation).

Thus, I'd say it's an *omission* in the specs, not a bug in the
implementations.

> I beg to differ. An equally common path is to convert the individual
> figures from *.eps to *.pdf and then assemble the document using
> pdflatex.  The metadata in the individual *.eps pdfmark sections are
> then attached to the individual figures, and can be used to navigate
> the resulting composite pdf document.  At least, that's the intent.
> If it's broken, let's fix it.

Right (I do not use `pdflatex' myself, thus I did not feel this need).

At any rate, users of PostScript document producers (LaTeX+dvips, Lout,
etc.)  are currently annoyed by a feature that is beneficial only in
fairly specific scenarios.  :-)

> If there is a better mechanism to do so, great.  But I'd rather fix the
> problem by improving the support rather than by removing it altogether.
> The pdfmark Reference you point to below gives a lot of suggestions how
> to create more sophisticated tags; perhaps someone will be inspired to
> modify post.trm to emit more sophisticated pdfmark sections.

There's only one way to create an info dictionary AFAIK.

Besides, "fixing the problem" would mean "augmenting the pdfmark
Reference", which is obviously not possible.

> Finally, I note that the pdfmarkReference also provides a sample code
> chunk to disable pdfmark interpretation by PostScript interpreters.
> Now that gnuplot allows local customization of the PostScript prologue
> files, perhaps the most straightforward immediate solution is for you 
> to add the code fragment to your local prologue file?

Hmm, I'll look into it, but that looks rather inconvenient.  A
terminal-specific "nopdfmark" option (or similar) would be nicer.

Thanks,
Ludovic.

Thread: [PATCH] Disable PDF docinfo output for EPS

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta