import of emf files with embedded bitmaps

Please attach a sample EMF file to allow testing of the reported issue on other systems.

Sample emf file attached. A path and both rectangles were imported correctly (although in multiple overlying copies - see bug #815977). The bitmap (an embedded png file has not been imported).

The emf file was generated using MS Powerpoint 2003 (right click on a grouped object and "save as picture...").

AFAIK the emf file can only(?) be imported on Windows. Linux version doesn't recognize this format.

Svg with imported emf file.

missing bitmap confirmed on Windows XP, Inkscape rev 10509.
Unfortunately, this is well outside my comfort zone, and I'm not aware of any efforts to include bitmaps in the emf import.

IMVVHO this bug report should receive more attention.

The issue was the very first thing I noticed in Inkscape (literally, I just started Inkscape for the first time, pasted my drawing, and watched it fail). I wonder how many people run into this error given popularity of MS tools; first time users are not very likely to come here to report it.

Raising status to 'Medium' - there seems to be no workaround in Inkscape (and no notice of known limitations - the format is not documented in the manual).

Please revert the change of importance if you don't agree.

I have been trying to get this going, and found that adding the few lines in the attached text file (NOT A PATCH!) causes EMF
files with embedded images to place the fake images at the appropriate sizes, but not at the right places (some scale issue). I can work onward from this if somebody can give me a clue how to get from the bitmap data stored in the EMF to the base64 format expected in the SVG. This section of code is a bit bizarre since the way the EMF import works is that it constructs a pseudo SVG file on the fly (minus certain parts, like the ID's in this section) and then when that is done it
converts the whole thing to a document with SPDocument::createNewDocFromMem.

I looked all over the Inkscape code and could not find an example that showed how to get from A (the EMF bitmap) to B (the base64 encoded PNG). The closest was, I guess, when a gdkpixbuf is loaded from a clipboard, saved to a PNG file, and then loaded into a document from that file. (This is the "paste" operation for an image.) The MSDN documentation indicates that various types of bitmaps can be in the EMF - presumably somewhere MS has a function that converts all of them to a full size RGB array, and from there it is just a hop skip and a jump to the base64 PNG. But I could not find that MS function.

Note in the attachment the first "xlink" line - until that was added the pseudo SVG was loading "xlink:href" as just "href", with the resulting bitmaps being invisible and unusable.

To fix the positioning problem change this line

tmp_image << " y=\"" << r << "\"\n x=\"" << l <<"\"\n ";

to this

tmp_image << " y=\"" << t << "\"\n x=\"" << l <<"\"\n ";

In the attached example the original EMF contained bitmaps exactly where the grey/blue/red rectangles
are now. Not posting that EMF as those bitmaps were very high resolution so the EMF is huge.

Still hunting around for code to actually pull the bitmaps out of the emf from within the EnumEnhMetaFile loop.

I have this working now, both for import and export. By "working" I mean that it works within the limits of what EMF can do. So long as the image is rectangular and aligned along the X,Y axes this code works. What EMF cannot do is move an image with transparency, nor can it handle a rotated image. There are some applications that appear to do this, but if you look at the EMF's they produce what they are actually doing is a series of EMR structures that mask, OR, and do other composite operations, rather than using a single EMR_STRETCHDIBITS record. It was far too messy to have Inkscape try to figure out when such an EMF was trying to create a modified bitmap. So on input it just stores every bitmap it finds. If some of these are masks or other odd things they can be deleted, or moved to gimp and merged there into a transparency and then reimported.

The differences relative to trunk from 2/29/2012 are attached, and any future changes will also be here:

http://saf.bio.caltech.edu/pub/software/windows/inkscape_changes.tar.gz

Note, there are some changes unrelated to this bug in that archive. The pieces specifically for this bug are to be found in the emf*cpp, and emf*h files, as well as in the build.xml.

Clarification of the rotation issue. It turns out that EMF can encode rotated images. To do so it rotates the system of coordinates, writes the image, then restores the coordinate system. Inkscape branch lp988601, currently being merged into trunk, imports and exports that sort of image properly. However, if it reads an EMF with the fake sort of rotation described in post 9 above, it still cannot do anything about it, as it it just sees the larger unrotated bitmap inside which the original image appears to be rotated.

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>