Inkscape

Bug #1419686
Comment #3

Comment 3 for bug 1419686

Revision history for this message

David Mathog (mathog) wrote on 2015-02-09:

The short answer is that EMF does not support transparency very well.

In modern bitmap formats one specifies for each pixel RGB and in addition a 4th value that sets the transparency. In such a bitmap any color can have any transparency. No EMF record type supports that. EMF format does support a more limited form of transparency where a regular RGB image is defined and in addition one color is set as "transparent". This is essentially the same thing as "green screening" in a movie, that one color is completely transparent and all others are completely opaque. (Note that EMF and WMF do support 4 byte/pixel bitmaps, but section 2.1.1.4 of the WMF manual says "The high byte in each DWORD is not used". In theory one could extend the format in an incompatible manner by storing the usual transparency byte there. However, since that byte can legally have any value whatsoever, one would have to expect to run into images produced by other applications with that number of bytes/pixel which would import with spurious transparency values.)

EMF has half a dozen "BLT" record types and the Inkscape implementation supports many of them, but not EMR_TRANSPARENTBLT, which is the one you would need for even the more limited "green screen" form of transparency. I will give this some thought - I guess it would be possible to scan the incoming image (from SVG) and IF all transparent pixels
are 100% transparent AND they are the same color AND that color exists nowhere else in the image then we could use
the EMR_TRANSPARENBLT format. Going the other way would be trivial, but it has not come up before now, since nobody has yet posted an example generated by any other application that uses this record type. I would not be surprised if we found that perfectly valid EMR_TRANSPARENTBLT records were imported poorly or not at all by other applications.

The EMF output you are seeing does appear to be correct for the current implementation. The transparent image does appear to have black pixels in the areas shown - but with an opacity of 0.

It _should_ have been possible to work around this by defining a clipping region and clipping the image, however I see that doesn't work. This is very odd, since a clipped path type object works, but adding an image and clipping both the path and the image is broken. I will look into that.

The short answer is that EMF does not support transparency very well.

In modern bitmap formats one specifies for each pixel RGB and in addition a 4th value that sets the transparency.  In such a bitmap any color can have any transparency.  No EMF record type supports that.   EMF format does support a more limited form of transparency where a regular RGB image is defined and in addition one color is set as "transparent".  This is essentially the same thing as "green screening" in a movie, that one color is completely transparent and all others are completely opaque.   (Note that EMF and WMF do support 4 byte/pixel bitmaps, but section 2.1.1.4 of the WMF manual says "The high byte in each DWORD is not used".  In theory one could extend the format in an incompatible manner by storing the usual transparency byte there.  However, since that byte can legally have any value whatsoever, one would have to expect to run into images produced by other applications with that number of bytes/pixel which would import with spurious transparency values.)

EMF has half a dozen "BLT" record types and the Inkscape implementation supports many of them, but not EMR_TRANSPARENTBLT, which is the one you would need for even the more limited "green screen" form of transparency.  I will give this some thought - I guess it would be possible to scan the incoming image (from SVG) and IF all transparent pixels
are 100% transparent AND they are the same color AND that color exists nowhere else in the image then we could use
the EMR_TRANSPARENBLT format.  Going the other way would be trivial, but it has not come up before now, since nobody has yet posted an example generated by any other application that uses this record type.  I would not be surprised if we found that perfectly valid EMR_TRANSPARENTBLT records were imported poorly or not at all by other applications.

The EMF output you are seeing does appear to be correct for the current implementation.   The transparent image does appear to have black pixels in the areas shown - but with an opacity of 0.

It _should_ have been possible to work around this by defining a clipping region and clipping the image, however I see that doesn't work.   This is very odd, since a clipped path type object works, but adding an image and clipping both the path and the image is broken.  I will look into that.