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 do it. 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 EPSF files. 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 doc/Use.htm#EPS that it needs to be DSC compliant; however I think it is appropriate and relevant to briefly mention DSC compliantness at the beginning of doc/Use.htm#EPS_parameters also?
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