import from EPS ignores bounding box

[Darko Veberic]

Importing an EPS file (attached) produces a misplaced drawing which is clipped away outside the A4 (Letter?) area.

It seems EPS import now goes through ghostscript convert to PDF since this "feature" can also be observed with "ps2pdf" command. In order to get a correct conversion from EPS to PDF the ps2pdf and/or gs commands should be run with the -dEPSCrop option...

[Darko Veberic (darko-veberic-kit)]

Workaround: convert EPS manually to PDF with

ps2pdf -dEPSCrop file.eps

and then import file.pdf

[su_v (suv-lp)]

Same or similar issue as reported in
Bug #264044 “inkscape import/open eps clips drawings larger than sheet width”
Bug #471199 “Importing EPS Clips Image”
and
Bug #505991 “import ps: bad paper format”

The manual page for gs (using 8.70/8.71) doesn't explicitly tell how files larger than the default US Letter Portrait are handled with '-dEPSCrop', but first tests with the file attached to this report show the expected result.

However there is a difference to the other reports: the EPS file attached to this report is _clipped_ to the default papersize (with unchanged import extension), whereas in the other reports the content is actually _cropped_ (i.e. lost and not recoverable e.g. by releasing the clip from the imported drawing).

[Darko Veberic (darko-veberic-kit)]

On my system (ubuntu 10.10 beta) the attached file also gets cropped (and is not subsequently recoverable in inkscape 0.48.0 r9654 by page resizing), possibly because i have the LC_PAPER set to en_GB.UTF-8 in order to get A4 as default. A4 is somewhat narrower than Letter and that's exactly how much the drawing gets (irrecoverably) cropped.

[su_v (suv-lp)]

The paths are still in the file though not visible (because they are clipped): switch to 'View > Display mode > Outline' to see all paths, even those outside the page border.

[su_v (suv-lp)]

You can test you proposed change by copying 'ps2pdf-ext.py' from the shared extensions directory ('/usr/share/inkscape/extensions') into '~/.config/inkscape/extensions' and changing the line calling the ps2pdf command accordingly:

- run('ps2pdf "%s" "%%s"' % sys.argv[1].replace("%","%%"), "ps2pdf")
+ run('ps2pdf -dEPSCrop "%s" "%%s"' % sys.argv[1].replace("%","%%"), "ps2pdf")

The script file in the user extensions directory will be called instead of the shared one and the modified ps2pdf command applied to all EPS files imported/opened in Inkscape.

[su_v (suv-lp)]

Reproduced with Inkscape 0.47, 0.48 and 0.48+devel r9794 on OS X 10.5.8 (with Ghostscript 9.70/9.71)

The proposed change works well when importing the attached test file. Needs testing on a wider range of EPS files from different sources.

[Darko Veberic (darko-veberic-kit)]

Ad #6: Great, this works as a charm. Now I get to see the whole drawing already in the import preview window. Thanks. It seems -dEPSCrop should be used for EPS files. But isn't this extension mod going to be used also on the PS files? For PS I don't think EPSCrop should be used since usually %%BoundingBox is not present or is just crap.

[Darko Veberic (darko-veberic-kit)]

Ad #5: It's true, the paths are visible in Outline mode. Nevertheless, in older versions of inkscape the drawing was not clipped by the page size, now it is. Furthermore, I was used to fix this problem by selecting all (Ctrl-a) and then doing 'File > Document Properties | Page | Resize page to drawing or selection'. This action now does not want to cross the original page settings and the drawing remains clipped. The only way to fix it is to manually increase the 'Custom size > Width' field in order to recover the cropped part. What is funny is that Ctrl-a still highlights only the cropped part although the page is much larger now... This problem remains even after I save the drawing as svg and then reopen it, only clipped part is shown and Ctrl-a is still partial...

[su_v (suv-lp)]

> only clipped part is shown
That's what clipping is intended for… ;)

You can release a clip via menu 'Object > Clip > Release', and you can select all clipped objects prior to using the command vie 'Edit > FInd…' (enter the string "clip-path" into the 'Attribute' field). After releasing the clips you still have to manually remove the clip-paths which are now visible as regular paths (with a black fill because the fill attribute is 'Unset') - ctrl-click allows to select a path directly without manually entering the (nested) groups it is within.

[su_v (suv-lp)]

> For PS I don't think EPSCrop should be used

You can test it with the attached extension - just drop both files into '~/.config/inkscape/extensions' - it's a quick hack to call a separate script for EPS import, also it lists as separate entry in the file formats of the 'Open…' dialog. On my system it is listed before the default EPS entry and thus used by default when opening EPS files, but still allows to use the original import script by manually choosing the other EPS file type entry before opening/import the EPS file via 'File > Open…' or 'File > Import…'.

PS import should not be affected by this change (if you remove the file I previously recommended (in comment #6) to copy into the user extensions directory (ps2pdf-ext.py).

Note: this is only a quick hack - it would be better if the python script is enhanced to - for example - allow different import options for EPS files (and hide them when opening a Postscript file).

[su_v (suv-lp)]

… and the renamed python script file with the '-dEPSCrop' option.

[su_v (suv-lp)]

@JazzyNico - what do you think about using a separate extension script for EPS import, with the '-dEPSCrop' option added? It would correspond to Inkscape's EPS export which also does not use the page size but the bounding box of the drawing content.

EPS import with '-dEPSCrop' no longer places the EPS figure on an arbitrarily sized page (US Letter Portrait for most users), but uses the bbox information for the page size, neatly fitting the drawing content.

Or would it be possible in the existing script (ps2pdf-ext.py ) to detect which output extension is calling it and use a different command string depending on its value (PS|EPS)?

[jazzynico (jazzynico)]

@~suv - I'd rather add an option (and thus a dialog such as the one which shows when importing PDF files but with only one option) when importing EPS files. Using two different extensions (and two entries for the same file format) would lead to the kind of problem we already have when importing AI files, depending on the AI version used...

[su_v (suv-lp)]

@JazzyNico - maybe my question wasn't clear: I'd only add a second python script 'eps2pdf-ext.py' called by the already existing 'eps_input.inx' instead of 'ps2pdf-ext.py' - otherwise nothing would change: no new file type needed, and the same Import dialog opens, showing the preview of the EPS file, with the same options as currently.

The result would be that the complete content of the EPS file is imported, and no longer clipped or cropped to US Letter by ps2pdf.

[su_v (suv-lp)]

…or rather: above attached files had been intended for testing, thus adding a second file type and not replacing the default EPS file format entry to allow comparison between calling ps2pdf without and with '-dEPSCrop' without affect PS import.

I'm not sure if adding an additional import extension dialog (before the one showing the preview and other options) to optionally set 'EPSCrop' as ps2pdf argument would be user-friendly. Afaiu the option can't be added to the existing dialog because it is opened after the call to ps2pdf, with the PDF file generated on-the-fly.

[jazzynico (jazzynico)]

Oh, yes, I forgot the python script was just a preliminary work...

[jazzynico (jazzynico)]

Ok, I really misread your question, sorry. And you're right, adding an additional dialog is definitely not a good idea.

The specific eps2pdf-ext.py script is the most simple option. There's nothing to do, we can reuse your work ;)
I'm not sure that commands with parameters work (see Bug #431290 "[inx] <command reldir="path">somecommand -with -arguments</command> fails").

[su_v (suv-lp)]

Bug #431290 is not an issue here if the argument is added to the command string inside the python script. I have been using several different import extensions for EPS and PS imports now for several months (with -sPapersize=A0, -dEPSFitpage and -dEPSCrop arguments), testing with files from the bug tracker, mostly. (All installed as user extensions, with different <id> and <filetypename>, alongside the original version).

Ideally we would add the additional dialog and offer similar options as when importing EPS into GIMP [1], parsing the EPS file in the python script or using ghostscript commands to query bbox, page size... and thus offering several options that can be decided before the conversion to PDF is done.

OTOH it might be worthwhile adding the '-dEPSCrop' option for EPS files as default for now, allowing a greater number of EPS files getting imported into Inkscape without cropping (or clipping) parts of the original.

[1] <https://bugs.launchpad.net/inkscape/+bug/190424/comments/25>
    <https://bugs.launchpad.net/inkscape/+bug/190424/+attachment/1115744/+files/190424-test-ss-GIMP-v2.6.8-import-dialog-osx.png>

[jazzynico (jazzynico)]

> Bug #431290 is not an issue here if the argument is added to the command string inside the python script.

Yes, but it is an issue if we want to pass the argument from the INX to the python file with the <command> element, which would be a more elegant solution.

> Ideally we would add the additional dialog and offer similar options as when importing EPS into GIMP

That's the proposal I made in #14. It"s probably not a good idea if we have only one option, but it could be very useful if we implement it the same way Gimp does. I suggest that we launch the debate on the dev list and plan this feature (if widely accepted) for 0.49.

In the meantime, I vote for an easy and invisible fix for 0.48.1. The eps specific python file works and can be committed now, and maybe improved later in the 0.48.x branch if we find a way to pass arguments without using a dialog.
The only think we need to take care of is that using the bounding box is not a regression for some users.

[su_v (suv-lp)]

So far I have tested and explicitly confirmed it with the files from this and the earlier reports (bug #264044, bug #471199) and some unrelated ones (bug #496831, #647725), with Ghostscript 8.70 and 8.71. Confirmation with ps2pdf from the most recent Ghostscript release (9.0) would be interesting, too (I won't be upgrading gs on my system in the near future, but I can test with EPS files that have been attached to other reports).

[jazzynico (jazzynico)]

> Confirmation with ps2pdf from the most recent Ghostscript release (9.0) would be interesting, too

Tested on Windows XP, no problem with the '-dEPSCrop' option.

[su_v (suv-lp)]

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).

[su_v (suv-lp)]

Exported EPS file (page area) used for testing EPS import (w/o '-dEPSCrop')

[su_v (suv-lp)]

Attaching better test file (compare exporting to EPS page|drawing-area, import w/o -dEPSCrop)

[jazzynico (jazzynico)]

I've finally found a way to reuse the same python file for ps and eps imports and silently pass a parameter for eps files with the gui-hidden="true" attribute.

Please test.

[su_v (suv-lp)]

ah, using 'gui-hidden="true"' allows to pass any parameters - great :)

AFAICT works fine, and allows in the future to possibly add an option for Postscript files too (some do suffer a similar issue, but 'EPSCrop' doesn't fix it for PS files - '-dPapersize=' or other options potentially do, but this needs further investigation -> bug #505991, also happens with PS files created by Inkscape).

[jazzynico (jazzynico)]

Is there something else we must test/do before committing to 0.48.1?

[su_v (suv-lp)]

Nothing I'm aware of right now. Maybe commit it to trunk first, and if there are no regressions reported, backport it to 0.48.1 in a week or two?

[jazzynico (jazzynico)]

Fix committed in the trunk, revision 9819.

[su_v (suv-lp)]

JazzyNico wrote:
> Is there something else we must test/do before committing to 0.48.1?

No feedback or regressions reported so far - proposing to backport to 0.48.x.

[jazzynico (jazzynico)]

Tested again on Ubuntu 10.04, 0.48.x branch, and committed in revision 9702.
Thanks for the reminder!

[jperl (johannes-perl)]

I still have the same problem on Inkscape 0.48.3.1 r9886 (Mar 29 2012) using 12.04 beta.
Shouldn't it be already fixed there?

Enclosed please find an EPS to be able to reproduce.

[Alvin Penner (apenner)]

- not entirely sure if this is exactly the same as the original bug report, but reopening anyways.
- running Windows XP, Inkscape 0.48.3.1, I open the file best5voxels_allruns_pid05.eps
to get the attached svg file best5.svg. This file is clipped to the page size.
 If I choose View->Display Mode->Outline then the full image becomes visible. Left boundary of image is at - 200 px (-160pt) Right boundary of image is at 1000 px (800 pt). These margins appear to be consistent with the original bbox in the file, which was (-204 333 802 520).

[Alvin Penner (apenner)]

- unfortunately, it appears that I do not have the authority to reopen this report
- @ jperl , could you try setting the status to New?

[jperl (johannes-perl)]

@Alvin: I do not have the rights to change the status.

The basic problem is exactly the same as in the original report. When I try to import the file from #33, the file is cropped, hence not the whole plot is imported. I have searched through other bugs concerning the boundary problem and found this one to match my problem the best.
Of course I could open a new bug, if this is desired.

[su_v (suv-lp)]

Note: the attached file 'https://bugs.launchpad.net/inkscape/+bug/649842/+attachment/3002395/+files/best5voxels_allruns_pid05.eps' does not declare itself as an EPS file (instead it's a regular PostScript file):

%!PS-Adobe-3.0
%%Creator: MATLAB, The Mathworks, Inc. Version 7.10.0.499 (R2010a). Operating System: Linux 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64.
%%Title: /home/jperl/figures/fedodata/glm_rf/best5voxels_allruns_pid05.eps
%%CreationDate: 03/25/2012 17:59:32
%%DocumentNeededFonts: Helvetica
%%+ Helvetica-Bold
%%DocumentProcessColors: Cyan Magenta Yellow Black
%%LanguageLevel: 2
%%Pages: (atend)
%%BoundingBox: (atend)
%%EndComments

This report is about importing EPS files - it makes use of Ghostscript's '-dEPSCrop' option which only works for EPS files, but not for Postscript files (changing the page size when converting PostScript files to PDF requires different command line options).

[su_v (suv-lp)]

Just a quick test - modifying the PS file like this:

$ diff 649842-best5voxels_allruns_pid05.eps 649842-best5voxels_allruns_pid05-test.eps
1c1
< %!PS-Adobe-3.0
---
> %!PS-Adobe-3.0 EPSF-3.0
10c10
< %%BoundingBox: (atend)
---
> %%BoundingBox: -204 333 802 520
$

and opening it in Inkscape, results in the attached SVG file.
(tested with Inkscape 0.48.2, 0.48.3.1 and 0.48+devel r11189 on OS X 10.7.2, with Ghostscript 9.05)

[Alvin Penner (apenner)]

thanks, ~suv, that worked perfectly!
I made the change on Windows 7, Inkscape 0.48.3.1 and it loaded correctly, thanks for the tip.

[jperl (johannes-perl)]

Thank you ~suv. Your comments helped me solve my problem.
Fixing the header to EPSF-3.0 and copying the bounding box to the top of the file worked perfectly.

The problem here seemed to be that Matlab using the 'psc2' switch did not produce a valid .eps file. Instead I would recommend using 'epsc' to generate .eps files.