Comment 23 for bug 649842

Testing with EPS files from the bug tracker hasn't indicated any regressions so far (~50 EPS files created by various applications: AI, CorelDraw, gnuplot, Matlib, fig2dev, Mathematica, Inkscape, …). None of the EPS drawings smaller than US Letter showed any missing elements, OTOH files larger than US Letter are no longer clipped or cropped on import.

Differences I noted so far:

1) BoundingBox offset
Offset (in pt) from the origin (lower left corner) in the bbox definition is ignored now (the default import does respect it and places the content of bbox with the same distance from the lower left corner of the page (possibly cropping it of at the upper/right edges of the page). Since the default page size of gs has no relation to the dimensions of the individual EPS drawing, I don't think this matters for most usages.

2) Inkscape EPS export with 'Export area is page'
Importing EPS files - exported with 'export-area-page' from Inkscape - with the '-dEPSCrop' only includes elements with are fully or partially inside the page area (the bbox in the EPS file), whereas current EPS import contains all elements (even those completely outside the page area (=drawing). It seems to me that '-dEPSCrop' respects the Inkscape export options more precisely (although it fails to add a clip to the bbox so that objects overlapping the page area aren't visually bounded to the page border after import).