We have a lot of EPS files that ghostscript is failing to crop correctly. I have played around and if i remove the hiresboundingbox values it crops correctly. But if i leave it in, the image is just white (default background colour). GSView works and crops it correctly, and from much reasearch on the net, it seems that gsview rounds down the decimal values to integers of the hires values.. I have some sample EPS files that i would like to upload. if I don't get the chance, please send me an email to cameron.hodge@communitynews.com.au with a site / email address I can send them to. Would make it a lot easier on your end to reproduce the problem.
Created attachment 1484 [details] Sample EPS file that crops incorrectly.
Created attachment 1485 [details] another example
Created attachment 1486 [details] another example
Created attachment 1487 [details] another example
Command being used is ----------- gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=png16m -r300 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sOutputFile=C:\temp\2733316.png C:\temp\2733316 ----------------- If you do not include the -EPSCrop the image does get displayed in the bottom left corner. The only way I have been able to get the EPSCROP to work, is remove the HIRESBOUNDINGBOX. Thanks
The given (incorrect) test file has the following bounding boxes specified: Line 5: %%BoundingBox: 0 0 84 218 Line 5713: %%BoundingBox: 0 0 170 36 Line 5714: %%HiResBoundingBox: 0 0 169.92 36.48 The image is 1.17 x 3.03 inches. This consistent with line 5.
The EPS files are correct. At least they are correct enough for the extraction of the right %%BoundingBox comment. The header section is normally terminated by the %%EndComments comment but it can be implicitely terminated by a non-comment line. Apparently, GS doesn't handle the latter case. Probably, parsing the header can be also stopped when %%BeginProlog or %%BeginSetup is found, but this is not in the spec.
The eps files I submitted are used in a newspaper production house. Photoshop, Quark, and even GSView can render and crop the images correctly, its just when I try to output it to a image device (jpeg, png) it fails to crop correctly. I am not sure if the EPS files do confirm to any standards but all the software we use here can work with them fine. Cameron
As identified by Alex, the file is missing %%EndComments. Consequently the DSC parser is still looking for %%HiResBoundingBox and finds it in an embedded EPS. Ghostscript is clearly wrong here. The DSC parser will be aware that it is beyond the header section, but this information is not being passed to the PS code in gs_epsf.ps. A simple fix to handle those files would be to make gs_epsf.ps cease processing bounding boxes when %%BeginProlog is found. A better way would be to find out from the DSC parser whether it is still in the header section. This bug should be assigned to me. There is another patch to gs_epsf.ps (bug #687915) which has not yet been approved that could conflict with the fix for this bug. It is likely that some of this patch will assist with fixing this bug, since it allows the PS code to ask the DSC parser for the BoundingBox found in the header or trailer, and ignore all others. http://ghostscript.com/pipermail/gs-code-review/2005-April/004771.html
The customer field is reserved for Artifex customer ID's and the highest non-customer Priority is P3.
Bug still reproducible in Ghostscript 9.03
Created attachment 16630 [details] Terminate processing on %%BeginProlog and %%BeginSetup as well If the proper way to do this takes more than a decade to implement, doing it in the simpler way is probably better.
Fixed by commit: cceb68900b433e7ce518619b9dd2ceb01c4fed9d