When a PostScript file fed to epstopdf does contain its bounding box at the end, epstopdf will break the PostScript file it generates and likely cause a ghostscript error. Steps to reproduce: 1. echo 'digraph { a -> b }' | dot -Tps > foo.ps 2. epstopdf foo.ps Expected result: foo.pdf should be a pdf version of the graph Actual result: Error: /undefined in or: Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop 1739 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1155/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 8.70: Unrecoverable error, exit code 1 The actual cause of the issue is in these lines here: my $pos = tell(OUT)+length($_); ... # go back seek( IN, $pos, 0) or error "Cannot go back to line \"$BBName (atend)\""; So it does determine the position to seek to based on the position of the output stream, but tries to seek the input stream instead. I guess this is because the input stream might be buffered. The output stream, however, is a pipe, and telling its position seems to be at least unportable. Adding the --debug switch to above output, I learn that it believes the output position to be 22, which is the length of $_ i.e. "%%BoundingBox: (atend)" and not the length of the header up to and including this line. Yes, I know I should have used "dot -Teps" instead of "dot -Tps", and would have gotten a BBox at the beginning in that case, but I'm investigating a problem with doxygen here, and doxygen seems to generate plain ps files although it calls them eps files. I'll file a separate report for doxygen once I find out why it's using the ps driver instead of eps. The fact remains that the (atend) handling in epstopdf is currently broken. I guess this might well be an issue for upstream. If you want me to report this, I would very much welcome any advice as to whom to contact, and in what way. Right now I don't know, and I'm very glad for this bug tracker here to keep things organized and publicly accessible. Packages involved: app-text/texlive-core-2008-r6 media-gfx/graphviz-2.24.0 app-text/ghostscript-gpl-8.70-r1 app-doc/doxygen-1.5.8-r1
Created attachment 201786 [details] Example PS file with bbox atend This is the file generated by step 1. from comment #0, so you can test it even without having (that precise version of) graphviz installed.
epstopdf.pl contains this snippet: # The only thing I have not allowed for is the case of # "%%BoundingBox: (atend)", which is more complicated. And the man page: BUGS The case of "%%BoundingBox: (atend)" is not supported. Please send reports regarding the program or this man page to tex-k@tug.org. so I suppose that answers your questions :)
(In reply to comment #2) > epstopdf.pl contains this snippet: > > # The only thing I have not allowed for is the case of > # "%%BoundingBox: (atend)", which is more complicated. But then it goes on with the History section: # 1999/05/06 v2.5 (Heiko Oberdiek) # * (atend) supported. # 2005/10/06 v2.9.5gw (Gerben Wierda) # * Fixed a horrendous bug in the (atend) handling code # 2007/05/15 v2.9.6tp (Theo Papadopoulo) # * Simplified the (atend) support Mentions a lot of support for something officially not supported. > And the man page: > > BUGS > The case of "%%BoundingBox: (atend)" is not supported. Which can either indicate that they know their code to be broken or experimental, or that that part of the man page predated the initial stab at supporting it. > Please send reports regarding the program or this man page to > tex-k@tug.org. That is one really goot quotation, will write a mail now. > so I suppose that answers your questions :) Mostly yes, thanks. I take it that we simply consider atend support as experimental, any package relying on it as broken (as doxygen per bug #282150), and the task of fixing this as UPSTREAM.
(In reply to comment #3) > That is one really goot quotation, will write a mail now. http://thread.gmane.org/gmane.comp.tex.tex-k/185
thanks for doing all the work there :) it is now included in texlive 2009 it seems