Incorrect EPS import: just one bit of missing text

[Martin Gelfand]

I am using xmgrace (very old software now, but still works!) on linux to produce graphs which I sometimes import into inkscape for decoration. When the attached file is imported into inkscape (windows or linux, latest release), the tick label "150" in the lower right does not appear.

Windows version 0.48.4-1 [on Win7]
Linux version 0.48.3.1 r9886 (Jan 29 2013) [on Kubuntu LTS]

Is the problem defective EPS produced by xmgrace? Or incorrect EPS import routine?
The "150" shows up using ghostview on windows as well as okular on kubuntu.

[su_v (suv-lp)]

Inkscape uses ps2pdf from Ghostscript to convert the EPS file to PDF [1], and then imports the PDF file using internal routines.

You can test on the command line yourself:
$ ps2pdf -dEPSCrop VariousGammaA5.eps VariousGammaA5-ps2pdf.pdf

and view that PDF file with your preferred PDF viewer: same result as what is imported in Inkscape (elements overlapping the borders of the portrait page (Ghostscript uses a system default for the page size) sometimes are clipped, those completely outside appear to be omitted completely).

Ghostscript manual:
<quote>
-dEPSCrop
    Crop an EPS file to the bounding box. This is useful when converting an EPS file to a bitmap.
</quote>
<http://ghostscript.com/doc/current/Use.htm#EPS_parameters>

(I get the same cropped PDF file as result when testing each of the two other EPS-specific options which Ghostscript offers).

--
[1] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/view/head:/share/extensions/ps2pdf-ext.py#L28>

[Martin Gelfand (gelfand)]

The cropped PDF that results from using ps2pdf is not the same as what I see in inkscape!
ps2pdf -dEPSCrop (or with other EPS-specific options) crops the entire figure, slicing it
vertically at around t=125 on the plot. What I see in inkscape (can anyone else verify?) is the entire graph, just
the one tick label "150" is missing. You can't get rid of that one tick label by cropping.
It is true that this tick label is the only "part" of the figure that is entirely in the
portion that is cropped by ps2pdf.

So a workaround may be to "shrink" the original EPS (I should be able to change settings in
the grace print-to-eps routine, I think) so that p2pdf doesn't crop it at all?
I'll give that a try.

[Martin Gelfand (gelfand)]

Quick follow up: I found in the grace EPS output settings a switch for "tight bounding box", which is
on by default. Disabling that setting solves the problem importing the figure into inkscape.

So not a bug, just unexpected behavior. Or, more precisely, inconsistent behavior among various applications
that display EPS files, all of which use gs under the hood.

[su_v (suv-lp)]

On 2013-10-03 04:00 +0200, Martin Gelfand wrote:
> The cropped PDF that results from using ps2pdf is not the same as
> what I see in inkscape! ps2pdf -dEPSCrop (or with other EPS-specific
> options) crops the entire figure, slicing it vertically at around
> t=125 on the plot. What I see in inkscape (can anyone else verify?)
> is the entire graph, just the one tick label "150" is missing.

Did you open the PDF file generated with ps2pdf on the command line in Inkscape? Maybe we used different Ghostscript versions, but in my test, the PDF file looked identical to the EPS import of the original file in Inkscape.

AFAIU that label is "dropped" because it's entirely outside the area of the default page (A4, or US Letter, Portrait) Ghostscript normally uses for the conversion (unless e.g. -dEPSCrop is specified for EPS files).

Not sure what to do about this report - turn it into a feature request to either
 a) implement PS/EPS import internally based on a suitable library which parses the PostScript file to extract the important instructions wrt to bbox, page size and orientation
 b) enhance the default PS/EPS import i.e. add additional Ghostscript options to that dialog which allow more fine-grained control of the conversion PS/EPS -> PDF
or close it based on "not a bug, just unexpected behavior"?

With regard to option b):
Earlier this year I made an attempt to write an enhanced python-based PostScript input extension, but the interface is confusing (as are the GhostScript options), and successful import is somewhat of a 'trial and error' routine:
<http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-extensions/files/head:/postscript-input/>

I'm attaching an SVG version of the original EPS file which was imported forcing a preset page size (US Letter, Landscape) using this custom extension.

[ Final note on that custom extension: it was developed with current Inkscape trunk and the some of the tabs look terrible with current stable 0.48 because the widgets are not as tightly packed as in trunk ]

[su_v (suv-lp)]

Closing based on the reporter's earlier feedback:
«o not a bug, just unexpected behavior. Or, more precisely, inconsistent behavior among various applications that display EPS files, all of which use gs under the hood.»