EMF export glitch

Output of clipped regions to EMF with current stable Inkscape on Windows is already tracked in this earlier report:
- Bug #649744 “emf wmf export clipping path issue”
  <https://bugs.launchpad.net/inkscape/+bug/649744>
  (“(…), and export to EMF completely ignores the clipping path.”)

Inkscape trunk (and 0.91pre3) has new EMF/WMF input and output (cross-platform, no longer limited to Windows builds). Clipping support for the new EMF input/output feature is tracked in this earlier report:
- Bug #1302857 “EMF, improved clipping support”
  <https://bugs.launchpad.net/inkscape/+bug/1302857>
  (“The support for clipping on EMF input was always rudimentary, and support on output was completely absent.”)

Since the reporter did not provide the EMF file created on Windows with current stable 0.48.4 [1], I can't compare the old EMF export (Windows only) to the current state wrt to clipping (EMF export e.g. on OS X). However, opening the EMF file exported with 0.91+devel r13822 (OS X 10.7.5) in Inkscape again shows visually correct clipping of the red line, whereas opening the same exported EMF file e.g. in LibreOffice 4.3.4 and 4.3.5 does not (in LO the red line at the top extends to border of the image). The visual result seems to also depend on the features supported by the EMF viewer (?).

--
[1] Note: latest stable release is 0.48.5 (bug-fixes only)

@David Mathog - any chance you could comment on the reporter's questions wrt clipping in EMF (Inkscape export), and about the current state in trunk compared to stable?

I pulled inkscape-0.91pre2-x64.r13532.20140826 out of the Google Drive public folder. Same result!

Also inkscape-0.91+devel.r13828.20141230, for good measure. Same result!

This seems to have something to do with the units conversion on SVG to EMF. Attached is a much trimmed down version of the original test case. (I'm not going to be surprised if this traces back to yet another case where the new "units" code breaks something.) It has just the L shaped red line, the underlying white rectangle, and two black marker lines to show where the visible vertical part of the red line should be. When I open that in Inkscape trunk r13647, save as EMF, read in the EMF, save as SVG, all of the units change for things outside of <defs>, but the clippath inside <defs> is unchanged. It starts as:

      <rect
         height="200.4586875"
         width="227.43"
         x="72.81"
         y="18.81"
         id="rect6170" />

and ends up as:

         d="m 72.8245,18.8249 227.3985,0 0,200.4731 -227.3985,0 z"

which is the same thing. However the L path changes from:

     d="m 73.3786,219.269 L 129.124,219.269 L 129.124,-1"

to

     d="m 91.7243,274.048 69.6747,0 0,-275.32299"

Which accounts for what we are seeing, I think.

The same experiment with my standard EMF test file (test_libuemf_ref.emf, current version in current version of libUEMF) cycles EMF->SVG->EMF without problem - but in that case everything starts in mm and ends in mm, so there are no units conversions.

Also, I have no idea what pieces of libUEMF are in the release. I work in trunk and just cross my fingers and hope that they eventually make it into the releases.

@David Mathog - the problem AFAIU is that Powerpoint doesn't render the applied clip as expected (I had been able to confirm the result with Powerpoint 2013 on a Windows 7 system with the EMF file exported with recent Inkscape trunk on OS X (0.91+devel, see attachment to comment #2)): while Inkscape renders the exported EMF file as expected (round-trip editing), Powerpoint does not.

So the question is: does Powerpoint (or other Windows-based software) support the clipping feature in EMF files exported by Inkscape trunk (0.91+devel, 0.91pre3), or is this feature only supported by Inkscape itself when loading the EMF file? (Note: like Powerpoint on Windows, LibreOffice on OS X doesn't clip the line either, based on the EMF files attached in this report).

<off-topic>
On 2015-01-05 21:18 (+0100), David Mathog wrote:
> Also, I have no idea what pieces of libUEMF are in the release. I
> work in trunk and just cross my fingers and hope that they eventually
> make it into the releases.

AFAICT the latest changes to 'src/libuemf' in trunk:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/src/libuemf/
had been in rev 13322
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13322

The same changes are also part of the release branch for 0.91:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/files/head:/src/libuemf/
here's the commit as seen in the 0.91 commit history:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/revision/13322
</off-topic>

I can't speak for all versions of PowerPoint, but in general they do support clipping in EMF files when those are brought in with "insert image". However, no tested PPT version could convert that image to native objects with appropriate clipping by:

select imported object (EMF image)
group->ungroup

In PPT 2010, for instance, that loses all clipping information.

Test file to demonstrate this is attached.

Unfortunately, I no longer have access to that Windows system to do further tests myself (it was at my parents' place, during the last visit). Hopefully others can fill in …

This does seem to be, once again, a problem with units. Attached is work_1405292.svg. When opened in trunk, and then saved to EMF, and the EMF reopened, the drawing inside is correct. However, if these two lines are removed from the SVG

     inkscape:document-units="pt"
     units="pt"

(or the entire sodipodi:namedview structure removed) and the experiment repeated, then the clip box moves. It seems quite unreasonable that this should occur since this SVG specifies width and height explicitly in points. This is probably manifesting itself in PrintEmf::merge_PathVector_with_shape() in emf-print.cpp, or thereabouts, where the transform for the clipping object is used.

Copying the sodipodi:namedview structure from that attached example into the OP's SVG example does not "rescue" that example, there are still issues with the clipping rectangle changing size and position.

Note that the work_1405292.emf which is produced is NOT seen as clipped when "insert->image" in PPT 2003, nor in Windows XP preview.

Sorry, hit enter too early. The last sentence above suggests that even if the problem is resolved in Inkscape it may very well still not work in PPT. I have noticed in some other contexts that PPT occasionally has issues with lines that it does not have with filled shapes. For instance, PPT 2010 does not respect the simplest line width parameter in EMF files. If MATLAB can be configured to generate solid lines (polygons with fill, without stroke) those might work better.

Aargh, updated to rev 13841 (from r13647) and it totally broke the EMF read/write cycle test for clipping. (Use the test clipping EMF file posted above). The initial read is OK, but the first write loses the clipping.

The attached patch should resolve this issue - and potentially quite a few others.

The history of this has been that the "units" work on Inkscape has been repeatedly breaking the EMF import/export, and so a set of workarounds were accumulated to let EMF function despite what "units" was doing. See for instance bugs #1306138 and #1348417. Some of this was coming about because the SVG generated had never had a viewbox set, and that was added in an earlier patch a week or so ago. That worked with the revision I had at the time, but upgrading to 13841 made it all fall apart again. I think this is because somewhere in the last few revisions the issue with units not scaling things in <defs> was repaired, so the workaround to compensate for that was now compensating for no bug and itself became a problem.

Anyway, the attached patch takes out pretty much all the units related workarounds, because inkscape is now doing the right thing with the SVG that is generated, and no longer needs any patching after the fact to the doc.

Please note that pretty much alone in the emf-print.cpp code the line dash pattern had since around 1/10/2014 and revision 13135 needed an explicit scaling. That scaling is removed by this patch, since with the other parts of the patch and the current revision of trunk this extra step is no longer needed. (When the extra scaling is present now the dash sizes increase on each read/write cycle.)

This patch has been tested on linux, somebody please test it on OS X and Windows 64, as I don't have either of those to work with.

Fix from post 16 committed at revision 13913.

Tentatively adding 'backport-proposed' -> needs testing whether removing all the units-related workarounds can be safely applied there too.

The bug seems to still be present in 32bit dev rev 14423 on windows 10.
I'm trying to convert a pdf to emf with the following command
inkscape.exe map15k.pdf --export-emf=map15k.emf

The resulting emf file has some extra margin on right and bottom if opened in word or other MS software.

Also the dashed lines look wrong but this is probably another bug.

If the sample file is opened it and "Document properties" checked it says 273.33334 x 273.33334 pixels. Save to EMF and reopen and that document size is 73 x 73 mm. Are they the same? No, change units on the first one from px to mm and it says 72.31945 mm.

The EMF export functions contain code to round off certain numbers so that the file can be imported and exported with complete numerical stability _of the contents_ and the _drawing size_. To achieve that the original document size may need to be tweaked slightly, because EMF uses integer sized documents (like 28000 x 13000, or whatever). It does not, and cannot, guarantee that the document size is exactly the same as it was in SVG. Often it does manage that, if the numbers come out right. Here they do not.

If you copy the contents of the re-opened EMF file into the PDF one, and align on the left edge, you can see that the right edge lines up exactly. So the drawings contents have not been resized.

Note also that the PDF import makes the outer edge somewhat ragged, which may be in part what you are seeing. When I view the sample in PDF-Xchange viewer the white street intersecting the edge of the drawing near the final "n" in Kopmansgatan is flush with the drawing's edge. When the PDF is imported into Inkscape it is not, it protrudes outward slightly at high magnification. That suggests either a rounding error or some issue with clipping. Can you produce a simpler PDF sample that still has the edge problem? (A simple solid rectangle would be best, if that's possible.)

The dashed line is a separate issue. It looks fuzzy in the final EMF. Zoom in on it and it can be seen that it is still dashed, but the dash length relative to the width is much shorter. This is undoubtedly yet another issue related to the "units" work, here triggered by the change from px to mm. I can reproduce that and will file a new bug on it.

Thanks for looking this.
Maybe the attached pdf was a little bit confusing. I had a original pdf which dimensions should be 72,5 x 72,5 mm. Though when opened in Acrobat Reader it says it's 72,3x72,3 mm, don't know why. Does my Qt-based map design software (QGIS) produce the pdf with wrong dimensions? I then opened the pdf in Inkscape and did some little modifications and then saved it back to pdf and this saved pdf was the file that I attached in post #19.

When the original pdf is opened in Inkscape its dimensions are 72.475 x 72.475 mm.
When it is saved back to pdf and this modified pdf is opened in Inkscape its dimensions are 72.672 x 72.672 mm and the clipping mask is little bit too large.

So it seems that it is not only the emf export that is messing with the units.

Here is the original pdf attached which dimensions should be 72,5 x 72,5 mm.

The 72.5mm one is actually 72.31945 mm once Inkscape opens it. In Adobe Reader I see it as 2.85 x 2.85 inches (72.39 mm). In Inkscape trying different units finds 205.00001 pt, and not near any other nice numbers - whole integers, simple fractions in pixels, mm, or inches. Are you wedded to that size? I have not seen this resizing problem with an A4 which is 210 x 297 mm. 297/4 = 74.25 mm, which is pretty close. Can you generate the map at that size and then open it in Inkscape? If it isn't very close to 74.25 then there is something slightly off in the sizes your map software is generating.

Note that
72.39 - 72.31945 = 0.070550
0.070550/72.39 = 0.000975 = ~.001

That suggests to me that there may be a 1000px size in play somewhere and you are seeing rounding errors of that magnitude
as a result. (Speaking here from experience - EMF has a pixel size basis too and if the value is too small similar problems arise.) If you poke around in the generating software and find an adjustable number of .001 or 1000 try increasing the resolution by 10x, that might minimize the resizing issue. Otherwise, if generating an image size of 1000 px is an option, try that.

You are right that the page size is 72.31945 mm when opened. I just selected all elements and looked the width and height in the toolbar and those are 72.475 mm. So the page size is smaller than its content. Is this a bug? I'm not so familiar with different clipping masks etc. in pdf. There are some options how to clip the pdf when opened like media, crop and art box. Does that affect to the size?

I tried to make a A4 sized pdf map that showed 297x210 mm in Adobe Reader and 297.03891 x 209.90277 mm in Inkscape. I then saved to EMF and this still has some extra content on the right and bottom side when opened in Word. The green background is exactly the desired size but it seems that the clipping box is scaled to be too large so some underlying objects comes visible.
When the emf is opened in Inkscape clipping box is displayed correctly but the size of the page is 298.0 x 210.0 mm.

I even would be willing to pay something to get this bug fixed. I'm writing my master thesis and really need to get high quality vector images to my Word document. Please contact privately if you want to get some reward solving this.
I noticed that some Inkscape bugs are found from bountysource.com. Is this preferred way to give some bounty.

There are way too many variables to say for sure what is going on here. Perhaps if you could reproduce this with a very simple drawing, just a rectangle or two, we could sort it out. The current drawings are far to complex to debug. I suspect that at least one component in the size issue may be clipping, where object sizes extend beyond the edges of the document and they appear to stop there only because of clipping. Clipping support was only added to my EMF library and from there to inkscape fairly recently, and there are still some modes which are not fully supported. (In particular, complex overlays of clipped regions probably will not work.) I also suspect there is an implicit integer sized grid somewhere in your drawing generating software, so that in combination with the resolution page sizes become only approximate.

What software are you using to make the PDFs? Does it output in any other formats? Try to rule out possible glitches in the PDF generation separate from the core of the drawing software.

Moving the drawing into Word is an entirely separate issue. Microsoft has an assortment of glitches in EMF import in PowerPoint, and probably most of these appear on import into Word too, see:

   http://saf.bio.caltech.edu/PPT_G_P_I/

If you want your imports to be entirely glitch free your best bet is to save as a high resolution bitmap image and import that into Word. It will make your Word file large but at least you won't need to deal with any of these format conversion issues. You can probably get from "here" (your current drawings) to "there" (imported into Word as you want) most quickly through this route. Of course you will not be able to modify that bitmap drawing once it is in Word.

At this time I am not available for contract work on this or any other project. Sorry.

Already available in 0.92

I have tested this personally with the latest beta for windows version and it seems to work within Inkscape. However, powerpoint, paint, and windows explorer preview all fail to clip the line in the original test SVG. At this point the problem could be argued to be a windows bug, but are you sure you haven't masked a data format problem with a rendering "fix"?

I don't have time to work on this now. However, if somebody else wants to have a look, I think
that this may indicate a mismatch between the way the first clipping path is defined from EMF in inkscape and in Windows applications. In the file emf-print.cpp at line 1064 there is:

   rec = U_EMR_SELECTCLIPPATH_set(U_RGN_OR);

When Inkscape sees that on input it reads it as creating a new clip path (OR path with nothing is path). Perhaps EMF on windows is assuming an existing clip path at the outermost bounding rectangle for a new DC (drawing context). So in that environment the OR would do nothing, which would be consistent with the observed behavior. Perhaps U_RGN_AND is needed instead. If that is true then Inkscape's input logic will need to be special cased, so that if it sees a selectclippath record on input, and there is no existing clipping defined, AND and would define one (and for compatibility, OR would do nothing). There are 5 options in total (AND, OR, XOR, DIFF, and COPY)
defined in section 2.1.29 of the EMF manual. These are with respect to "the current clipping region". The definition for selectclippath is:

This record defines the current path as a clipping region for the
playback device context, combining the new region with any existing clipping region using the
specified mode.

I had read "any existing" to imply that one had to be explicitly created. Perhaps not, perhaps there is always clipping at the outer edges of the DC. Let me ask my contact in MS documentation and get back to you on that.

EMF clipping support in Inkscape is pretty recent and many of the possible variations are either not implemented or have not been tested well. Basically all that is supported for output conversion is a relatively simple clipping path (perhaps a join of several via OR) applied to some draw operation. It would not surprise me if I have some of the details messed up. (I'm pretty sure that the REGION mode of clipping is not working right, for instance.)

The EMF documentation folks wrote back. It turns out that not only is there no default clip region, but if any mode but RGN_COPY is used first GDI will combine whatever random data is sitting where the "existing" clip path is in memory with the OR, XOR, AND, or DIFF, producing undefined results.

I'm having a terrible time building the current Inkscape trunk with cmake on either my existing linux development machine or a second similar machine, both Ubuntu 14.04 32 bit. (The original 14.04, not 14.04.5, and no amount of dist-upgrade seems to be able to fix it, sigh.)

In the meantime, will somebody please try the following?

Change:

emf-print.cpp line 1064 from:

   rec = U_EMR_SELECTCLIPPATH_set(U_RGN_OR);

to

   rec = U_EMR_SELECTCLIPPATH_set(U_RGN_COPY);

and recompile. Load the test SVG file above, save it as EMF, and then look at it on a Windows system. The clipping should work.

FINALLY was able to build a working Inkscape on Ubuntu 14.04 with cmake, but only by manually entering one compile and one link command. Tested patch with SVG test file from this bug, EMF produced was properly clipped when viewed with a Windows application.

Submitted patch is revision 15235.

Note - EMF has a second form of clipping using REGIONS (records EMR_FRAMERGN, EMR_FILLRGN, EMR_INVERTRGN, etc.) which is not currently supported by Inkscape. Consequently if one examines the libUEMF test file "test_libuemf_ref.emf" in a Windows application the bottom 5 "star" figures along the right hand edge, all marked with "RgnData", will not look the same as they do in Inkscape.

Sadly the patch does not seem to be included in 0.92 release, or it is not working for me.

I forgot to post the patch here which was put into revision 15235.

Now actually backported to 0.92.x in
https://gitlab.com/inkscape/inkscape/commit/20963b1e0d6dee2eef3c12fe1302583490b7ce64

Just confirming that it works for me in 0.92.2 windows-x64 release. Thanks!