Ghostscript already interprets the EPS bounding box comments
with -dEPSCrop command line option.

Probably, this option should be enabled by default for EPS files.

If EPSCrop is to be enabled by default, then we need to change the gs_epsf
logic to allow it to accept -dEPSCrop=false

      //systemdict /EPSCrop known {
        EPSBoundingBoxCrop
      } {
        //systemdict /EPSFitPage known {
          EPSBoundingBoxFitPage
	} {
           ...
        } ifelse
      } ifelse

above would be problematic since if EPSCrop were the default, EPSFitPage would
never be looked at.

I think we should change this logic, as for usability -dEPSCrop should be the
default, as this is what users expect and users usually do not know about the
-dEPSCrop option.

Therefore I am reopening this.

Created attachment 3103 [details]
patch

Change the default to cropping EPS to the bounding box. Drop EPSCrop option.
Add EPSPlace option to select backward-compatible behavior.

All EPS files in Comparefiles suite render to different page sizes.

This is a full list of the files that renders differently.
They are all EPS files despite the .ps extension.

Bug687156.ps
Bug687546.ps
Bug687660.ps
Bug687984.eps
Bug688000.ps
Bug688327.ps
Bug688453.ps
Bug688822.eps
Bug688895.ps
Bug689269.ps
FIG3.eps
Type3FontTexture.ps
golfer.eps
muur.eps
ridt91.eps
tiger.eps
type3xshow.eps

Tested with the File attached to the Ubuntu bug report and it works.

The EPSPlace option is not a very good option since it doesn't (at least
in English) associate with the action.

"Placing" is usually thought of as specifying the location of place (an object),
as in -sEPSPlace=123x456 to place an EPS origin at a specific place on the page.
Note the use of '-s' instead of -d to allow horizontal (X) and vertical (Y)
origin point since -d only allows a single value and we shouldn't rely on
extensions like -dEPSPlace=\[123\ 456\] since this won't work the same across
all platforms and shell implementations.

Alternatitvely, please consider -dEPSCrop=false or -dEPSNoCrop.

Just to make things more confusing I prefer -dNoEPSCrop

Note that this will cause confusion if the requested command line PAPERSIZE
is also specified and is ignored now because -dEPSCrop is the default.

We have discussed this and think that if the command line option sets the
PAPERSIZE (or DEVICEWIDTH.../DEVICEHEIGHT) that EPSCrop should not occur
and override the page size (returning to the previous behavior)

So let "-dEPSCrop" only be the default if non of "-dNoEPSCrop",
"-sPAPERSIZE=...", or other options setting the page size are given.

The PAPERSIZE option sets the initial page size. This size can be changed
by a setpagedevice operator. This behavior is not considered confusing.

So the question is: Can EPS change the page size? With EPSCrop option,
which is a proposed default, EPS can change paper size. EPSCrop option
existed before and nobody complained about the interaction with PAPERSIZE.

What PAPERSIZE comes from a script, or an environment variable and the user
is unaware of it. Suddenly, the default doesn't work. But what if we override
PAPERSIZE when -dEPSCrop is given explicitly ? Now, that's confusing.

EPS can not change the page size.  Conforming EPS files can not use the
setpagedevice operator or change the imageable area through statusdict or
userdict.  See Adobe document 5002, "Encapsulated PostScript File Format
Specification", Version 3.0, 1 May 1992, section 2.4 "Illegal and Restricted
Operators".
The size for the PDF should probably come from the BoundingBox comment with an
option to override it on the command line.

Any news of this bug?

Alex requested clarification of the options.

-sPAPSERSIZE= (or -dDEVICEWIDTHPOINTS= -dDEVICEHEIGHTPOINTS=) are defined as
setting a default paper (media) size that can be overridden by later PS
or PDF actions unless -dFIXEDMEDIA is also specified.

The -gWWWxHHH option sets the device width and height in pixels and is defined
to imply -dFIXEDMEDIA.

This is all documented in:
   http://www.artifex.com/gs-current-release/Use.htm#Paper_size
   http://www.artifex.com/gs-current-release/Use.htm#Page_parameters
and
   http://www.artifex.com/gs-current-release/Use.htm#Parameters

Note that the last reference should probably be moved since it is currently
in the 'Setting Parameters' section and should probably be in one of the
other two sections.

As far as the use of -dEPSCrop, my reading of:
   http://www.artifex.com/gs-current-release/Use.htm#EPS_parameters
is that this option allows the EPS file BoundingBox to automatically act like
a 'setpagedevice' that sets the PageSize and the initial graphics state
"translate" (using Install) accordingly.

Therefore, the -dEPSCrop should be ignored if -gwWWxHHH or -dFIXEDMEDIA was
set, otherwise it is allowed to override the default page/media size set
by other methods, including execution of a PS 'setpagedevice'. Thus using 
this option on other than a single EPS file will result in the page being
resized -- too bad, so sad.

The -dEPSCrop is only really useful for a single EPS file, not as a default
or general option since it might cause strange effects when a PS file 'runs'
an EPS file in order to "place" it.

Since EPSCrop is implemented in the "run" operator, I don't think it will
interefere with EPS files embedded with a PS file that is itself "run" so
that normal EPS placement in PS files should work OK.

IMHO, making -dEPSCrop the default is misleading and results in non-conforming
behavior. I think this bug should be closed as "WONTFIX" since changes will
change the documented behavior (that has been in place for YEARS).

As far as the original bug report, someone wanting to convert an EPS to a
PDF such that the EPS BBox will be the PDF MediaBox should use -dEPSCrop.
Others should not use this option.

Ray, thank you for clarification.
I'm closing the bug as "WONTFIX".

[Just a side note, while I’m in bug replying mode -JimC]

I can’t imaging *ever* wanting to run gs(1) myself (as opposed to how gv(1) et
al run it) on an eps file w/o cropping to the (intersection of the) bounding box
(with the physical display).

(Perhaps a *bit* larger than the physical display, but certainly less than twice
the physical display’s linear size.)

I think most users would agree.

For converting to pdf, I think *all* users would prefer that the eps’s bounding
box is used as the media box in the pdf.

It is just what people expect.

With conversion to PDF, would it matter if you were creating a PDF to print or a
PDF/X to pass to another application?