(In reply to Frédéric Parrenin from comment #0)
> Created attachment 11413 [details]
> .eps file to reproduce the problem
> 
> Steps to reproduce:
> - download the attached .eps file
> - apply the following command:
> ps2pdf weertman-effect.eps
> - open the produced weertman-effect.pdf file
> => the image is cropped to a default paper format. The BBox should be
> automatic.

No. This isn't how PostScript works. If you want to use the Bounding Box defined in the **comments** of an EPS file, then you need to specify -dEPSCrop. Note that, because of the linear interpretation nature of PostScript, an (atend) BoundingBox can't be used either (w2hich is what your file uses). The pdfwrite device needs to know how large your media is before it starts, after its finished is too late.

So for this file, you are going to need to specify the media size you want. Or use teh EPS file as it is intended to be used, insert it into a document and print that.

Thanks for your answer.
I am not sure I fully understand what you said.
Actually, I was using inkscape and I complained that my .eps image had been cropped when imported into inkscape. Somebody told me that this was a gs issue:
https://bugs.launchpad.net/bugs/1406771

So is there a solution for inkscape to import the file completely?
Scribus *does* import the file completely.

(In reply to Frédéric Parrenin from comment #2)
> Thanks for your answer.
> I am not sure I fully understand what you said.

An EPS file is a specially crafted, limited, form of PostScript. It is intended for the production of figures, or illustrations, or other 'stored' content, which is intended to be placed onto a document containing other data. As such the page layout application treats it as a 'black box', when it creates PostScript for printing to a device it inserts the EPS directly into the PostScript it is generating. All the page layout application does is ensure that the position and scaling are correct, and to do this it reads the EPS comments from the file.

EPS files are *not* intended to be sent directly to a printer, if for no other reason than the fact that they are not permitted to contain a 'showpage' operation, so they will never actually print anything on a standard PostScript printer.

Ghostscript has 'some' ability to behave like a print processor or page layout application. Within limits it can act upon EPS comments contained in a document. However, PostScript programs are interpreted from the start to the end (as a stream, not a file, no matter what the original source, so PostScript is not seekable). One consequence of this is that, once you have started making marks on a page, you cannot change the page size (if you do the accumulated marks are discarded)

The result of all this is that in order to use the %%BoundingBox comment of an EPS file, it must appear at the start of the file. Its no good waiting till the end and *then* saying 'oh, I need you to use A3 paper, not A4'


> Actually, I was using inkscape and I complained that my .eps image had been
> cropped when imported into inkscape. Somebody told me that this was a gs
> issue:
> https://bugs.launchpad.net/bugs/1406771

The poster there did point out that you should be using -dEPSCrop, which you were not apparently doing. *most* EPS files will work that way. In fact if you edit your EPS file, take the "%%BoundingBox:...." from the end of the file and replace the "%%BoundingBox: (atend)" in the first part of the file with that line containing the actual numbers from the end of the file, you will find that Ghostscript will produce the PDF file at the size you expect.

 
> So is there a solution for inkscape to import the file completely?

Not knowing anything about Inkscape, I can't really comment. If it needs to convert EPS into PDF then it should be calling Ghostscript with -dEPSCrop anyway (which according to your Launchpad bug report, it seems is). Though that won't help you, because your EPS is constructed in a way (valid though it is) which Ghostscript, by the nature of a PostScript interpreter, can't process some of the comments from.


> Scribus *does* import the file completely.

Possibly it interprets the EPS file itself, or perhaps it pre-processes the EPS in order to extract the BoundingBox co-ordinates and uses those.

The 'correct' (ie using the format the way it was intended) way to convert this EPS file would be for a print processor to scan the file for %%BoundingBox: comments, starting at the beginning and proceeding to the end. It should then use that information to construct a 'container' PostScript program around that EPS, then send the whole of that to Ghostscript. The 'container' would contain a media size request (EPS files may not contain these) calculated from the declared BoundingBox, as well as scaling and positioning operations to place the EPS on the media.

Explaining how to do that is rather beyond the scope of a  bug answer. If you want to know more you should read Adobe's Technical note #5002, the EPS specification.

Thanks for the long answer.
But I don't understand why ps2pdf can't scan the file for %%BoundingBox: comments, and then reprocess the file using that information.

(In reply to Frédéric Parrenin from comment #4)
> Thanks for the long answer.
> But I don't understand why ps2pdf can't scan the file for %%BoundingBox:
> comments, and then reprocess the file using that information.

ps2pdf is just a simple shell script, all it does is call Ghostscript with some additional parameters (if you look at it, you'll see what it does). Ghostscript is a PostScript interpreter, it has no idea where the PostScript is coming from, so it cannot 'scan' or 'preprocess' the file.

Since you are a Unix user, consider the case where the an application produces PostScript on stdout, and that is piped directly into Ghostscript (yes this is possible, and is a potential use case for Ghostscript). Clearly there is no opportunity to examine the stream of bytes before we start to process them. This is the *normal* mode of operation for a PostScript interpreter.

That's why Ghostscript cannot handle EPS with (atend) comments.


Sending EPS to a PostScript interpreter is not 'normal' use of an EPS file, if Ghostscript conformed totally to the specification in this case it would produce no output at all. We *do* try to deal with these situations, but you've hit one we cannot handle, because of the architecture of the language. As I said, the correct way to deal with this is for a page layout application to create a full PostScript program from the EPS file, and send that to Ghostscript.


Clearly we *could* write an application, or more complex shell script, which could preprocess the EPS file and manufacture the containing PostScript program, but that's not the business we're in. We make a PostScript interpreter, we don't do page layout applications.

OK, thanks for the answer.
I will see with inkscape if they are willing to fix this issue on their side.

For reference, Scribus actually pre-scans the (E)PS file to be imported for the "%%BoundingBox:" formatted comments (and a couple of others) and uses that information to configure Ghostscript during (E)PS import.