Add support for EPS files with '%%BoundingBox: (atend)'

[Frédéric Parrenin]

The shapes are correctly imported but the fonts are wrong.

[Frédéric Parrenin (parrenin-ujf)]

Sorry, I attached the wrong file. This one should be the right one.

[Frédéric Parrenin (parrenin-ujf)]

Note that the first .eps file does not import correctly in inkscape either, but maybe this is because of a malformed eps file.

[Frédéric Parrenin (parrenin-ujf)]

On the second file, I realized that un-checking the "replace font" checkbox does import the file correctly.

[su_v (suv-lp)]

Please add information about OS/platform and Inkscape version (see Inkscape menu 'Help > About Inkscape' to the bug report, and attach SVG versions saved with inkscape on your system which illustrate the reported issue (maybe also a screenshot of how Inkscape wrongly renders the fonts), to allow further investigation.

[su_v (suv-lp)]

On 2014-12-31 16:28 (+0100), Frédéric Parrenin wrote:
> The shapes are correctly imported but the fonts are wrong.

Inkscape uses ps2pdf from Ghostscript to convert PostScript-based files
to PDF on-the-fly, and then imports the PDF file using internal
(poppler-based) functions.

Attached are the two PDF files generated with the same Ghostscript
command as used by inkscape, basically:

$ ps2pdf -dEPSCrop ${file}.eps ${file}.pdf

AFAICT Inkscape's import of the EPS files is as expected, based on the
output of ps2pdf (attached). [1]

weertman-effect.eps:
====================
For this file, ps2pdf (i.e. Ghostscript) apparently doesn't treat it as
EPS format (instead - like with regular PostScript files - ps2pdf crops
the content to the default paper size used in Ghostscript;usually
portrait A4 or US letter, depending on build and runtime configuration.
Objects overlapping the page border are usually included completely,
whereas objects fully outside the page border are ommitted). Inkscape
then imports the result (the PDF file) generated based on Ghostscript's
interpretation of the original file.

The text from the PostScript file imports as text in Inkscape, using the
fonts 'Times'
(style="font-family:Times;-inkscape-font-specification:Times-Roman") and
'Symbol' (for Ω) - independent of whether or not the option 'Replace PDF
fonts by ...' is checked.

toto.eps:
=========
ps2pdf treats it as EPS file (-dEPSCrop works as expected), the text
however is not preserved as text - instead each letter actually is an
embedded bitmap image used as mask on a rectangle with black fill
(result of the PDF import).

The rendering of the text (and its fonts) in inkscape is not affected by
the import option 'Replace PDF fonts by ...' at all - there is no text
(as text) in the PDF file generated by ps2pdf (i.e. Ghostscript), thus
none in Inkscape either.

--
[1] tested with Inkscape 0.48.5 r10040 and Inkscape 0.91+devel r13847,
ps2pdf from Ghostscript 9.10 on OS X 10.7.5

[Frédéric Parrenin (parrenin-ujf)]

To summarize, I reported two bugs here:
- the original one with the wrong font being displayed is not present anymore after upgrading to inkscape-0.48.5. We can forget this one.
- the one with the graphic being truncated (first attachment) is still present in inkscape-0.48.5 on debian 8. This bug is due to a malformed .eps file, with an incorrect bounding box. In this case, inkscape truncates the graphic to the declared bounding box. I did not see any option to import the whole graphic, even outside the bounding box. By comparison, scribus was able to import the whole graphic. Moreover, when I save the file to svg, the fonts are incorrectly saved (see attached svg).

OS: debian 8
version: inkscape-0.48.5

[su_v (suv-lp)]

On 2015-01-12 11:40 (+0100), Frédéric Parrenin wrote:
> Moreover, when I save the file to svg, the fonts are incorrectly
> saved (see attached svg).

How exactly are they incorrect?

The PDF file generated by ps2pdf here (Ghostscript 9.10, OS X 10.7.5) uses exactly the same fonts as seen in use in your SVG file (output of pdffonts from poppler 0.30 attached):

- Times (Times-Roman)
- Symbol

[Frédéric Parrenin (parrenin-ujf)]

Sorry, I wrote too quickly.
The fonts appear incorrectly in eog but actually they appear correctly in firefox.
So this is an eog bug, not an inkscape bug.
So the only remaining bug I see is the truncation of the .eps file to the bounding box.

[su_v (suv-lp)]

On 2015-01-12 12:02 (+0100), su_v wrote:
> The PDF file generated by ps2pdf here uses exactly the same fonts as
> seen in use in your SVG file (output of pdffonts from poppler 0.30
> attached):
>
> - Times (Times-Roman)
> - Symbol

Correction: the SVG file attached in comment #7 uses 'Times New Roman', AFAICT as nearest match for 'Times-Roman' (as specified in the PDF file) on your system.

On the local system, I have the fonts 'Times' and 'Times New Roman' installed (system fonts, both), and Inkscape's PDF import seems to prefer 'Times' over 'Times New Roman' as font match.

[su_v (suv-lp)]

On 2015-01-12 12:03 (+0100), Frédéric Parrenin wrote:
> So the only remaining bug I see is the truncation of the .eps file to
> the bounding box.

That seems to be a Ghostscript issue (Inkscape just takes whatever result 'ps2pdf -dEPSCrop' produces), and can be reproduced independent of Inkscape by using ps2pdf on the command line to convert the EPS to PDF:

$ ps2pdf -dEPSCrop weertman-effect.eps weertman-effect.pdf
$ pdfinfo weertman-effect.pdf | grep 'Pape size'
Page size: 612 x 792 pts (letter)

The resulting PDF file is cropped to the default paper size as used by Ghostscript (see attachment to comment #6). Output of pdfinfo (from poppler 0.30) attached.

[Frédéric Parrenin (parrenin-ujf)]

OK. I reported the gs issue here:
http://bugs.ghostscript.com/show_bug.cgi?id=695784

[Frédéric Parrenin (parrenin-ujf)]

Apparently, gs people do not want to fix this issue on their side.
But they say it is possible to fix it in inkscape, by scanning the %%BoundingBox comment in the .eps file and then use it to specify the media size when invoking ps2pdf.

[su_v (suv-lp)]

On 2015-01-12 15:56 (+0100), Frédéric Parrenin wrote:
> But they say it is possible to fix it in inkscape, (…)

It would not be a "fix" in Inkscape - it would be an enhanced (new) script which works around limitations of ps2pdf (and Ghostscript) with EPS files as described in the referenced bug report.

Alternatively one might also consider to file a feature request for the software which generated the EPS file in the first place, asking for an EPS export variant which is compatible with Ghostscript (and 'ps2pdf -dEPSCrop').

For those interested:
Some time ago I started to work on an Inkscape extension which attempts to implement a basic interface for the 'gs' command itself. Still work-in-progress (it was more of a proof-of-concept what could be done, and certainly limited by my poor python skills at the time (not that they have improved much since ;-)) ...

The comments in the Ghostscript bug report are interesting (I only skimmed them quickly, not in detail) - maybe I'll take another stab to implement a 'semi-automatic' import for such special cases (here: an (atend) BoundingBox) in that custom postscript-input extension later this year.

Anyway - the extension is here (no documentation, and probably of not much use as it is without knowing details about the basic gs command and its options):
http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-extensions/files/head:/postscript-input/

[su_v (suv-lp)]

Attached is an SVG file created with the mentioned custom
postscript-input extension (used with Inkscape 0.91pre3), and a
screenshot showing the additional input options dialog with the values
manually filled in from the BoundingBox comment at the bottom of the EPS
file.

--
Note: the custom extension is not suitable in its current state for
regular usage or for getting bundled (and distributed) with the next
Inkscape version.

[su_v (suv-lp)]

Reported earlier as:
- Bug #1234405 “Incorrect EPS import: just one bit of missing text.”
  <https://bugs.launchpad.net/inkscape/+bug/1234405>

The software which created the EPS file attached there:
%%Creator: Grace-5.1.22

The software which created the EPS file in question here:
%%Creator: Grace-5.1.20

Comment 4 in bug #1234405 even offers details about a relevant export setting in xmgrace:
<https://bugs.launchpad.net/inkscape/+bug/1234405/comments/4>

@JazzyNico - should we link the older report as duplicate to newer one (which has the reference to a related Ghostscript report, with useful comments by the Ghostscript devel team)?

[jazzynico (jazzynico)]

@~suv - I'd keep the most useful report (apparently the newest one in that case) and link the relevant comments from the other one (as you already did).