Extra open path after export to EPS level 2

[Tim]

After export to the EPS level 2 (export to Level 3 have not tested) illustration contains new open path, which missing in a source file (SVG) and causes to rejection my artwork on istock ;-) .
Inkscape version 0.47 r 22583.
Source file, the result of exports, and screenshot of result of search of open paths by AI plugin are included.

[sas (sas-sas)]

Here's a modified version of Result.eps. Does the AI plugin find any open paths in this?

[Tim (tim-meremyanin)]

No. This version is ok.
Can you give me hotfix? :)

[sas (sas-sas)]

I don't know how to fix Inkscape (I think the bug may be in Cairo rather than Inkscape itself), but I can tell you what's wrong with the EPS file.

There are many lines that look like this:

123.456 314.159 m f

(The numbers vary, of course, and sometimes there's a * at the end of the line.) This line adds an empty open subpath to the path before filling the path.

To fix the file, I removed everything from these lines except the final f (or f*),

[sas (sas-sas)]

I think I've tracked this down.

In src/extension/internal/cairo-render-context.cpp there's a call to the function feed_pathvector_to_cairo() with two parameters. This function is defined in src/display/inkscape-cairo.cpp, and calls cairo_close_path(). And the documentation for cairo_close_path() - http://cairographics.org/manual/cairo-paths.html#cairo-close-path - says "any call to cairo_close_path() will place an explicit MOVE_TO element into the path immediately after the CLOSE_PATH element".

So I think that Cairo needs to supply an alternative to cairo_close_path() that doesn't include the MOVE_TO, and Inkscape needs to use this alternative function when writing PostScript. (To complicate matters, there are rare cases for which the MOVE_TO is actually required.)

[Tim (tim-meremyanin)]

It seems to me, that 046 version didnt has this bug. Or I am wrong? Do you have installed 046?

[sas (sas-sas)]

I haven't got 0.46 installed at present. Perhaps the EPS output didn't use Cairo then.

By the way, this issue has already been reported on the Cairo bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=25238 . Hopefully it can be fixed entirely within Cairo, which would be much better than my suggestion above (since it would fix it for all software that uses Cairo to write EPS).

[Tim (tim-meremyanin)]

Thanks for your investigations.
047 has many useful features i`d like to use, but unfortunately this bug makes it inapplicable for stock illustration.

[Tim (tim-meremyanin)]

I`ve rolled back to 046. Export is ok.

[sas (sas-sas)]

Here's an extension to work around this problem in Inkscape 0.47.

To install, download the two files above (eps_output_workaround.inx and eps_fixup.py) and put them in your Inkscape extensions directory (on Windows this may be C:\Program Files\Inkscape\share\extensions). The next time that Inkscape is started, there should be an "EPS workaround" option in the Save As dialog. This should produce EPS files without the extraneous movetos.

This is just a quick hack, and I haven't tested it much, but it works with the example file Source.svg above.

[Beluga (buovjaga)]

Still seeing those "m f" lines after exporting.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.91 r13725