Not sure if this is considered a bug or not - but the documentation for
-dEPSCrop probably can be updated if the behavior is intentional.
I was trying to do
gs -sDEVICE=tiffg4 -dEPSCrop -dNOPAUSE -dBATCH boundbox_A4.ps
and gs cropped the output to to letter (the default paper size); adding
EPSF-3.0 in the header get the desired behavior (crop to a little inside A4).
I guess what I expect is that EPSCrop works as boundbox crop,
(with or without EPSF header; probably not relevant to pdf?).
Would a boundingboxcrop be considered a useful improvement?
The current behavior seems to be intentional, since
it depends on all the EPS hooks. But I can see for most graphic conversion,
boundingbox crop is desirable (and the input should be EPS without declaring so).
This is not a bug in that EPSCrop is intended to only do something for DSC
compliant EPSF files, with the appropriate header.
Producing images by first running a bbox on the file is something that requires
two passes on the file, and since it would slow things down, we don't want to
The section in doc/Use.htm _does_ mention Document Structuring Conventions (DSC)
but this could be improved slightly by adding a reference to Adobe's document
on DSC and explaining that EPSCrop and EPSFitPage ONLY apply to DSC compliant
I don't think Ken should be bothered with this.
Yes, I checked the actual code and it checks for "%!PS-Adobe-a.b EPSF-c.d"
headers; and the documentation did mention in
that it needs to be DSC compliant; however I think it is appropriate and
relevant to briefly mention DSC compliantness at the beginning of
Oh, the fact that it requires two passes mean that this option does not work
with pipes, right? Should mention that if that's the case....
The doc/Use.htm has this statement which should be sufficient:
An EPS file must conform to the Document Structuring Conventions