trunk: Incorrect clipPath definition in SVG file based on EMF import

@David - would you mind taking a closer look at the attached EMF file, and the resulting SVG file?

Interesting. emf-inout creates the string:

<clipPath
        clipPathUnits="userSpaceOnUse"
id="clipEmfPath1" >
<rect
   x="0"
   y="0"
   width="743.93487"
   height="1052.1365" />
   transform="matrix(1,0,0,1,0,0)"
</clipPath>

but something elsewhere in Inkscape changes the double quotes around matrix to &quot;. If the bad svg is edited back to the preceding form it converts again when it is read in. The transform should be in the rect though, so that's probably the root cause.

On linux this seems to resolve this issue. It moves the transform into the <rect> element.

However, something else is now dreadfully wrong, as the "testew.sh" script is failing. Not just failing, but crashing on the 2nd iteration. (That script opens libuemf_ref.emf saves as EMF, opens again, rinse and repeat 3 times.) gdb is saying that an entire loop around line 1112 in emf-inout.cpp has been "optimized out" when that code _cannot_ be optimized out (the program has no way of knowing a priori how many dash entries there are, the loop must exist). It looks like gdb's internal structures are being corrupted, since before anything happens a breakpoint can be set there and works.

This crash has nothing to do with the present bug, it happens even if the entire U_EMR_INTERSECTCLIPRECT section from roughly line 2148 to 2172 in emf-inout.cpp is commented out.

> This crash has nothing to do with the present bug

Agreed - I'll file that separately (maybe I'll find a better test case for what triggers it).

Patch tested successfully with r13165 on OS X.

[ Note: when reopening the same EMF file a second or third time in the same inkscape process (launch, open EMF file, close window, open EMF file from recent menu, close window, …) the rectangle is no longer clipped at all (with patched or unpatched Inkscape). ]

Patch committed in r13166 - thx a lot!

@~suv Regarding opening the same EMF file, did you save on window close? That most definitely will lose the clip, because currently EMF only supports one type of clipping record (INTERSECTCLIP) and then only on input. I tried what you said in post 9, but without saving on closing, and the EMF opened the same each time.

Correction, the one supported EMF record type is "INTERSECTCLIPRECT".

The crash referred to in post 7 is entered as bug #1294840. A patch to fix it is posted there.

> (…) did you save on window close?

No. I used these steps:

1) launch trunk with default (new) prefs
2) open 'Untitled 2.emf' via 'File > Open'
3) select the blue shape and check via message in the status bar where it is clipped or not
--> yes
4) close window (Ctrl+W)
5) open 'Untitled 2.emf' (via 'File > Open' or 'File > Open Recent'
6) select the blue shape and check via message in the status bar where it is clipped or not
--> no

(Same results when checking the content via XML Editor after step 5: no clip-path attribute nor a clip-path definition in the <defs>).

OK, I see it now. There seems to be a problem with the initialization of the clipping region. Will look into it.

This patch seems to fix it.

Patch 'changes_2014_03_19d_emfonly.patch' tested successfully with r13167 on OS X 10.7.5, using 'Untitled 2.emf' attached in comment #1. Any side-effects to watch out for, or other sample files you'd recommend to run a quick test on with the patched build?

Unfortunately I never had a very good test file for that type of EMF record. My test cases come from powerpoint output and from the libUEMF test file. The former never generated that type of record, and the latter only had a single instance of a cliprect record (which I never tried to unclip, obviously). However you constructed "Untitled 2.emf" could you make a test case like it but with multiple rectangular clipped regions? Verify that all of the clipped regions load OK, and that once loaded, if one is unclipped that the others stay clipped. Note that when you unclip one you may see a fill from the underlying now no longer clipped object over the entire page. That big object will likely need to be deleted to check/see the other objects.

> However you constructed "Untitled 2.emf"

See bug description. The original drawing was a stroked rectangle drawn in a default new document in LibreOffice Draw (LO 4.2.2), and then exported to EMF. I didn't add the clip to the object in LO Draw myself - that was apparently done during export.

> could you make a test case like it but with multiple rectangular
> clipped regions?

I don't know how to control or verify this - if I export in LO Draw a simple drawing with multiple rectangles to EMF, I can "inspect" the result only with Inkscape (where just the rectangle drawn first (bottom-most in stack order) has a clip-path applied).

Looked into "Untitled 6.emf" with "reademf" from libUEMF and it shows only a single INTERSECTCLIPRECT record which is the size of the entire drawing. Everything drawn after that falls between the next SAVEDC and RESTOREDC, so it should all be clipped, not just the first one. In this example the clipping does nothing useful, since all 3 rectangles are within the drawing.

Clearly I need to revisit this code. In its present incarnation it will only clip the first graphic element that follows the definition of the rectangular clipping region, but at least it no longer blows up when unclipping, and when it fails, it fails by doing no clipping. Not great, but better than clipping the wrong thing.

> Clearly I need to revisit this code.

What about 'changes_2014_03_19d_emfonly.patch' right now? Would it be better to move the patch to a new report which tracks the refactoring of how clipping in EMF files is handled on import, or would you prefer to have it commit to trunk anyway?

Go ahead and commit it.

The clipping code currently in emf-inout.cpp goes all the way back to bug #383180 and revision 10193. It was very rudimentary but before I can do it right I will first need to code (into the libUEMF test program) the appropriate test cases, so it may be a while before a more complete clipping version is available.

I looked into the loss of clipping information on EMF output and found that was just never implemented. It will take a fair amount of work to add that.

When all of this is ready it will be posted in a new thread.

New clipping code: see bug #1302857