I’m thinking that your only option is going to be option #1, or render the transparent image over another solid color image with tools that allow you to do that.
I don’t know whether this is the problem with PNG, but one issue could be that Clarion uses the 80000000h bit as a switch to indicate that this is a system color (such as COLOR:BtnFace, etc). So any notion of transparency in a bitmap goes out the window, unless Alpha channel is supported.
The PNG decoder in the CW RTL uses the incorrect color depth value for your test image. As result, “unused” pixels are displaying/printing without blending. The image is displaying in a WINDOW incorrectly too. I know how to fix this problem. The fix is being sent to SV.
Windows metafiles do not support the AlphaBlend function. If a report is not printing directly to the printer, the RTL uses the StretchBit function for images with alpha channel. Of course, result of printing such controls is unexpected but there is no other way until switching to EMFs.
Additionally, there seems to be a problem with that particular image. It is color type 6 (RGB with Alpha channel) but Alpha channel is 0 in every pixel (both the intended to be transparent and the intended not to be). You can see in Windows Explorer preview of the file that it is also showed as a black rectangle.
PrintImage PROCEDURE(STRING p_FileName, WINDOW p_Window, LONG p_ImageFeq)
Problem solved. Thanks ALL and EVERYONE for pointing me to the right direction. Much appreciated!
This is not so. Most pixels, yes, have the alpha channel value equal to 0 => they shouldn’t be displayed/printed. But some pixels have not-0 alpha channel values after unpacking the tRNS block to RGBA. Only these pixels form the image.
Really, the test image is quite unusual. It has no the IDAT block which usually contains information about pixels. Moreover, the single PNG file can contain multiple IDAT blocks. The test image codes pixels as conjunction of palette from the PLTE block and transparency parameters from the tRNS block.
If I recall correctly rules for naming PNG image blocks, the 1st upper-cased characters means that the block is mandatory. If so, the format of the test image is incorrect. I have several image processing programs that display it as fully black. Even Corel’s program (PaintShop Pro X9) among this list.
It is interesting. We were looking at two similar but internally different images. Oleg dual posted here and on SV newsgroup. My test were using the one from newsgroup, which is colortype 6 (RGB with Alpha channel) while the one here is colortype 3 (Palette) + tRNS chunk. Perhaps Discourse made that change automatically.
This value is in the file header. The PNG_COLOR_MASK_ALPHA mask is adding to the color_type value during processing the tRNS chunk - in pnglib this is doing in the png_read_transform_info function.
Probably, some programs do use the color_type value from the header only before the PNG stuff finished processing all the data. The problem in CW is that parameters for the producing stream of pixels in RGB/RGBA for building a DIB calculated incorrectly for the test image because its data is really unusual.