Do any of you recall having seen code in Inkscape which swaps the bytes for colors R and B, but leaves the bytes for G and A alone?
In emf-print.cpp there has long been a section with this code (sorry about the wrap):
(void) RGBA_to_DIB(&px, &cbPx, &ct, &numCt, rgba_px, width, height, width * 4, colortype, 0, 1); // 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);
A bug has turned up
https://bugs.launchpad.net/inkscape/+bug/1447850
where the swap is needed for interactive work, but NOT needed for cli work. As the note indicates, I never knew why those two bytes were reversed, they should not have been, it was always a workaround for unexplained behavior. Now it seems that these bytes are not always swapped. Here is what happens: (bytes are swapped in output routine: Y/N)
image fillimage gui Y Y cli Y N
Fillimage refers to an image used in a fill operation, image is just the usual sort of image in the SVG drawing.
The EMF input/output has no idea what mode it is operating in. The pixel array rgba_px comes from this line in emf-print.cpp:
rgba_px = (char *) pixbuf->pixels(); // Do NOT free this!!!
and the contents of rgba_px are not the same for the fillimage test case in gui and cli modes. pixbuf comes via a call from metafile-print.cpp:
*epixbuf = ((SPImage *)parent)->pixbuf;
So, as far as I can tell the R<->B swapping has occurred elsewhere in Inkscape, long before it hits the EMF output code. Any suggestions where that might be? Or why that might be?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech