EMF path rendering issues

[David Mathog]

Porting inkscape to run on libUEMF is going great - but it has turned up some problems with Inkscape path rendering.

The first problem concerns EMR_ENDPATH om emf-win32-inout.cpp. In the EMR_ENDPATH case it contains:

            tmp_path << "\"";

this must be changed to

            if(!d->path->empty()){ tmp_path << "\""; } // only terminate path if it is not empty

or the attached emf file is toxic since the trunk version results in that EMF file being converted to malformed SVG. (Sorry,
my code is so vastly diverged from trunk at this point that I can't generate a patch.)

Once that problem is fixed the next, and deeper, problem shows up. This concerns how and when Inkscape actually renders
paths, which it is doing in a manner not consistent with Windows Preview. The attached file path_test.emf does for each of
the 32 and 16 bit draw routines a series of 3 sets. These sets are, left to right:

   beginpath | drawoperation | endpath | strokeandfill

   drawoperation | strokeandfill

   drawoperation

Images of path_test.emf from inkscape and Windows preview are attached. Differences between them are:

1. Columns 3,4,5 (from the left): Preview closes the path before stroke, Inkscape does not. Preview is correct as the
documentation for EMR_STROKEANDFILL says that it is to close the current path before drawing.

2. Column 15, top row, Inkscape fills the shape, Preview does not. That apparent difference between what happens
on the top row and the bottom row in Inkscape is because for the former the next record is EMR_BEGINPATH
whereas for the latter is is EMR_ENDEOF.

The general issue here is that the decisions for:

1. when/if to close path
2. when/if to draw

are somewhat ad hoc in Inkscape. Microsoft's EMF documentation is more than a little vague on some of these issues, and I have opened a thread in Stackoverflow asking for help in sorting out the rules. No response there yet though: http://stackoverflow.com/questions/11571044/emf-file-how-to-determine-when-to-stroke-fill

[David Mathog (mathog)]

Resolved with some compliated logic. See Bug 988601 post 12.

[su_v (suv-lp)]

Branch <https://code.launchpad.net/~inkscape.dev/inkscape/emf-support> (superseded lp988601) was merged intro trunk in revision 12488:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12488>