Clipboard Copy and Paste issues via EMF metafile

[David Mathog]

Krzysztof added code a while back to enable cut/paste to from/to the clipboard using EMF metafiles. There are a few issues that show up when going from PowerPoint to Inkscape, some easily fixed, others not so much.

Some small emf test files were made, entered into PowerPoint slides with "Insert Picture from file...", copy, then paste
into a drawing window in Inkscape. Inkscape had been modified so that the temporary file, holding the clipboard contents, was not erased. (comment out one of the unlink()'s in clipboard.cpp).

Issues:

1. In some images the Compression enumeration was changed from BI_RGB to BI_BITFIELDS. (WMF manual, section 2.1.1.7 for definitions.) In the cases seen so far there is no difference in the image encoding for those two compression modes, but since BI_BITFIELDS had not been previously encountered, there was no code to handle it. Result was that image contents were replaced with the default image pattern (used when images go south). A patch for this issue is attached to this post. (probs1a.emf is source, probs1a_copy.emf is captured paste from powerpoint, before patch a funny looking white and red image is tiled, afterwards it is an RGB gradient.)

2. EMF has a record CreateMonoBrush which is used, among other things, to describe small bitmaps that have two colors. When PowerPoint saved these it was changing the "usage" parameter from DIB_RGB_COLORS to DIB_PAL_COLORS. The former puts the colors in the image or indexed into the attached color lookup tables. The latter uses the image values as indices into a Palette. Unfortunately, elsewhere the EMF file sets the Palette to the Default_Palette, and that is a device specific table that is not portable. So there is no way to look up what the two colors are supposed to be. (This is similar to a font substitution issue.) Inkscape currently falls back to using a solid color in these instances. The only other alternative would be to pick two colors at random, or a fixed pair, and use those. Bottom line, there is not sufficient information in this type of EMF file to handle the record properly. (probs1b.emf is source, probs1b_copy.emf is captured paste from powerpoint, bug converts what should be a striped image to a solid one.)

3. EMF StretchDibits records allow some odd combinations of src (a coordinate in the source image) and cSrc (a width, height pair in the source image). PowerPoint can save one of the more obscure combinations with an erroneous cSrc of {2,0}, which makes no sense - a ource image has no height. This results in warnings from libpng like:

  libpng warning: Image height is zero in IHDR

This issue probably only comes up because the test file I used pushes on all the edge cases for this record type. Probably in normal usage this bug will never be triggered. (no examples provided.)

4. When a clipboard from PowerPoint is pasted into Inkscape it ends up about 3.4X smaller than it should be. If the clipboard contents in the temporary file are intercepted, and that file is opened, it opens at the expected size. As far as I can tell when this happens execution never enters either _getscale or pastsize in clipboard.cpp, so I am at a loss for where this scale factor is being applied. (Demonstrate by opening probs1a.emf in powerpoint, copy, paste into inkscape, then import probs1a_copy.emf into the same drawing. When the bug is present the former will be about 3.4X smaller than the latter.)

[David Mathog (mathog)]

I neglected to mention that some of these record conversions only occur when PowerPoint opens a file that it cannot ungroup. The next two examples have almost the same content, however the test_libuemf_ref.emf file does not ungroup, whereas probs1d.emf does. Insert these into separate power point slides, copy, paste into the same Inkscape drawing, and you can see the differences. Both of the pasted images will have the scale problem.