command line specific image glitch in EMF

[David Mathog]

There is a slight difference for EMF output when an image is saved interactively versus when it is run through interactively.
In the examples which will be posted in a minute:

  inkscape img1.emf

then interactively save it as imgA.emf results in an EMF which looks exactly like img1.emf. However doing the same thing
this way:

  inkscape --file img1.emf --export-emf=imgZ.emf

produces a file which has the fill image changed.

reademf shows no difference (other than the embedded file name).

Comparison of binary dumps indicates that the binary data for the image stored in the createdibpatternbrushpt record
is shifted by 1 byte.

[David Mathog (mathog)]

Version saved interactively, image doesn't change.

[David Mathog (mathog)]

The pix buffer is coming from line 303 in metafile-print.cpp:
        *epixbuf = ((SPImage *)parent)->pixbuf;

Dumping in the two locations (first 48 bytes of rgb px only):

DEBUG rbga_px hex: FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFF00FFFFFF00FF
DEBUG hatchType FFFFFFFF hatchColor 00 bkColor FFFFFF

one way and

DEBUG rbga_px hex: FF00FFFFFF00FFFFFF00FFFFFF00FFFFFFFF00FFFFFF00FF
DEBUG hatchType FFFFFFFF hatchColor 00 bkColor FFFFFF

the other. So it isn't just a one byte shift everywhere (the pattern is the same
on the trailing end, shifted on the leading end.)

It shouldn't be due to anything when the EMF loads, since both of the above had this:

inkscape --file /tmp/img1.emf

with one also having

  --export-emf=/tmp/imgZ.emf

Mysterious. Not all images do this, only the ones read from / saved to createdibpatternbrushpt records.

[su_v (suv-lp)]

Reproduced with Inkscape 0.91+devel r14059 on OS X 10.7.5.

[David Mathog (mathog)]

This one is a real puzzler. The SVG produced by the emf read is identical in the two modes. However, when trying to print to the output emf file, when the image is extracted in metafile-print.cpp to a pixbuf at line 303 with

         *epixbuf = ((SPImage *)parent)->pixbuf;

and then converted to pixels around line 480 in emf-print.cpp with

        rgba_px = (char *) pixbuf->pixels(); // Do NOT free this!!!

the value of rgba_px is different in the two cases.

CLI
DEBUG inkscape torgba_px 00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFF
DEBUG hatchType FFFFFFFF hatchColor 00 bkColor FFFFFF

Interactive
DEBUG inkscape torgba_px FFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFFFF00FFFF
DEBUG hatchType FFFFFFFF hatchColor 00 bkColor FFFFFF

Something about this 4x4 image seems to be a problem, many (many!) other images go in and out without any problems.

[David Mathog (mathog)]

Here is another test which demonstrates that the problem happens somewhere after the SVG load and the EMF write. Run the attached example like this:

inkscape --file /tmp/img1.svg --export-emf=/tmp/imgS.emf

and the colors in the image for the fill will be messed up, exactly as in the previous examples.

Hmm, running this:

inkscape --file /tmp/img1.svg --export-emf=/tmp/imgS.emf
inkscape --file /tmp/imgS.emf --export-emf=/tmp/imgT.emf

results in imgT.emf being swapped back to the original colors.

There is a section of code in emf-print.cpp:

                // Not sure why the next swap is needed because the preceding does it, and the code is identical
                // to that in stretchdibits_set, which does not need this.
                swapRBinRGBA(px, width * height);

This was compensating for a problem which I could never explain, but it was needed to keep the colors straight.
Perhaps whatever mysterious part of Inkscape which was swapping R and B is now only doing so interactively but not if the graphics never start (cli only)???

[David Mathog (mathog)]

 Krzysztof set me straight on the mailing list. There are two kinds of pixbuf, and they have R and B swapped. Added a test for PF_CAIRO and that took care of it.

committed as revision 14062.