Path gets exorted differently in EPS level 2 and level 3

Please provide information about your OS/platform and Inkscape version (see Inkscape menu 'Help > About Inkscape').

The described issue looks like the known upstream bug in older cairo versions already tracked for Inkscape in
- Bug #759154 “Open paths with aligned endpoints are closed in cairo-based exports (PDF/PS/EPS)”
  <https://bugs.launchpad.net/inkscape/+bug/759154>

> When exporting that as EPS level 2, the box is rendered correctly (but as image).

It would be helpful if you attached samples of the exported EPS files (Level 2 and 3) - the EPS files have information about which version of cairo Inkscape uses on your system.

> When exporting that as EPS level 2, the box is rendered correctly (but as image).

Not reproduced with Inkscape 0.48.2 (tested with cairo 1.10.2, 1.12.2) and 0.48.4 (tested with cairo 1.12.2, cairo 1.12.14, cairo 1.12.16): exporting the provided sample SVG file as Level 2 Postscript does not rasterize the vector object (path): the files exported as EPS Level 2 contain vector information, and show the same error as the Level 3 files if the version of cairo is < 1.12.

> When exporting that as EPS level 2, the box is rendered correctly (but as image).

Possibly you tested with a different SVG file than the one attached to this report?

General note on PostScript export:
Rasterization (converting vector information to embedded bitmaps) in PostScript exports is usually triggered if the SVG file uses features not supported by PostScript (e.g. any kind of reduced opacity, SVG filter effects). The details vary - filter effects are rasterized by Inkscape, whereas objects with (partially) transparent fill, stroke and/or gradient stop colors are rasterized by cairo (creating embedded fallback bitmap images). Objects with reduced object (aka global) opacity in Inkscape may trigger larger areas or the complete drawing content to be rasterized on export to PostScript.

Specific differences between Level 2 and Level 3:
The most relevant difference between PostScript Level 2 and 3 wrt to Inkscape SVG files is likely that PostScript Level 3 supports gradients with solid stop colors, whereas PostScript Level 2 doesn't support any gradients (objects with gradients will trigger fallback rasterization in cairo).
Support for solid (opaque) gradients in exports to PostScript Level 3 might vary depending on the version of cairo Inkscape uses on your system.

Regarding the wrong export, I use Inkscape 0.48.2.r9819 on Windows 8.1, 64bit.
Don't know about the used cairo library. In "Help"/"About Inkscape", I don't see the version of linked libraries.
libcairo-2.dll is from 2011-08-14 21:32.

You are right, the rasterizing was happending on a SVG with gradients, even if the gradient is flowing from white to white.

%%Creator: cairo 1.10.2 (http://cairographics.org)

Seems that the cairo version in my Inkscape build is too old.

On 2013-10-28 19:09 +0200, koppor wrote:
> %%Creator: cairo 1.10.2 (http://cairographics.org)
>
> Seems that the cairo version in my Inkscape build is too old.
>
> ** Attachment added: "b.svg exported as EPS level 2"

With regard to the gradients, the version of cairo is not the problem:
PostScript Level 2 does not support vector gradients, even if all stops
have solid opaque gradients: the rasterized export is to be expected due
to the limitation of the chosen file format. Even latest cairo 1.12.16
will rasterize the image due to the radial fill gradient if export is
restricted to "PostScript Level 2".

Attached: Level 2 (fallback image) and Level 3 (vector) EPS export.

With regard to the other issue with vector-based exports (no gradients,
or Level 3): yes, cairo 1.10.2 is affected by Bug #759154 Open paths
with aligned endpoints are closed in cairo-based exports (PDF/PS/EPS)”.

The upstream fix was released with cairo 1.12.0 - AFAIK all of the
currently available Windows packages bundle cairo 1.11.2, so upgrading
Inkscape on your system to the latest stable release (Inkscape 0.48.4),
or to an unstable development snapshot build would still produce EPS
files with U-shaped paths getting closed in the PostScript file).

There are workarounds availble (combine multiple paths with the same
stroke attributes into on path (menu 'Path > Combine'), or break the
affected paths at one of the corner nodes (using the node tool)), but
these edits have to be done manually, before exporting.

Proposing to link as duplicate to Bug #759154 Open paths with aligned endpoints are closed in cairo-based exports (PDF/PS/EPS)”.