[tex-k] dvips possible-bug/feature-request

[Jonathan Kew]

Before anyone digs too deep into dvips, consider that this may  
actually be a ps2pdf (Ghostscript) bug.

I tried the example given, and saw the problem as described. But  
using (an old version of) Adobe Distiller instead of GS to convert  
the .ps to .pdf, the problem does not occur; therefore, it seems that  
GS is behaving differently from Adobe Distiller. It would be good for  
someone knowledgeable in this area to carefully review the PostScript  
and pdfmark specifications to see what the "proper" behavior should be.

"Tweaking" dvips to avoid this issue is non-trivial, given that the  
pdfmark commands might be constructed by arbitrary PostScript code in  
the included graphics; recognizing and skipping this automatically  
requires, in the general case, a full PostScript interpreter in the  
driver.

If someone has an up-to-date version of Adobe Distiller and can test  
with that, it would be interesting to know what happens.

JK

On 8 Mar 2007, at 8:41 am, gual News wrote:

> To whom it may concern:
>
> There is a problem with pdf files metainformation that I think  
> might be fixed in dvips (and, unfortunately, I don't know how to do  
> it).
> I reported this in the "comp.text.tex" newsgroup ( http:// 
> groups.google.com/group/comp.text.tex/browse_thread/thread/ 
> 946ed6e0d03d1ecd/21b4721c249abeff#21b4721c249abeff ), and it was  
> formerly reported by somebody else in the  
> "comp.graphics.apps.gnuplot" group, but I am filing it here as a  
> "bug report," though it might be more properly called a "feature  
> request."
> With the last gnuplot (4.2.0), when using the eps terminal (e.g.  
> "set term post eps", and I presume any postscript terminal) in  
> order to generate eps files to be included in a TeX document via  
> the graphicx macros, the "pdfmark" information included in those  
> eps files takes precedence over the pdfmark information generated  
> by hyperref (I presume because it appears later in the file) when  
> using latex + dvips + ps2pdf. I presume this might be called a  
> dvips bug, or at least it might be fixed in dvips. When using  
> "epstopdf + pdflatex" or "latex + dvipdfmx" the problem does not  
> appear. Another contributor in " comp.text.tex" confirmed that,  
> when including eps files created by a different procedure but  
> containing metainformation, he encountered the same problem.
> The problem is easy to reproduce, but so you may check it, I attach  
> here 3 files:
> (1) "gr.gp", a gnuplot script file.
> (2) "gr.eps", the resulting eps file.
> (3) "problem.tex", the LaTeX that gives rise to the problem.
> I process " problem.tex" with latex (or pdflatex --output- 
> format=dvi), then dvips (with or without -z), and finally ps2pdf.  
> Then "pdfinfo problem.pdf" yields:
> Title:          gr.eps
> Subject:        gnuplot plot
> Keywords:
> Author:         root
> Creator:        gnuplot 4.2 patchlevel 0
> Producer:       dvips + AFPL Ghostscript 8.54
> CreationDate:   Thu Mar  8 09:11:13 2007
> ModDate:        Thu Mar  8 09:33:40 2007
> Tagged:         no
> Pages:          1
> Encrypted:      no
> Page size:      612 x 792 pts (letter)
> File size:      6805 bytes
> Optimized:      no
> PDF version:    1.4
> That is, the author and title metainformation is taken from "  
> gr.eps" rather than the hyperref settings. Just looking at  
> "problem.ps", one may see that it has both "pdfmark" settings, so  
> ps2pdf just takes the last one it encounters. I presume one might  
> tweak dvips to reproduce only the hyperref information in this  
> case, or rather to ignore the metainformation coming from the  
> included graphics files.
> Thanks for your help.
> Best regards,
> Gual
> <gr.gp>
> <gr.eps>
> <problem.tex>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tug.org/pipermail/tex-k/attachments/20070308/996132b9/attachment.html