DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2449 Version: 1.3-current I figured out the problem (I think). The original patch isn't any good because num_trans (again, I believe) is used to detect if a colourmap (indexed) PNG contains any transparent pixels. Therefore, removing it breaks indexed PNGs[1]. I have read the source for libpng 1.4.3[2] and in particular for png_get_tRNS() (pngget.c:805). It appears the png_get_tRNS does not set num_trans if info->valid doesn't have the PNG_INFO_tRNS bit set. The function itself returns zero in this case, but num_trans is left untouched. Since num_trans is not initialised when it is declared, it contains garbage. Therefore, the if-statement that decides whether or not to increment channels will succeed and channels will be set to 4 when it should be 3 (for RGB PNGs). I guess the proper, or more correct way, to do this whole channel increment would be to call png_get_valid(pp, info, PNG_INFO_tRNS) (as is done further down the code in Fl_PNG_Image prior to calling png_set_tRNS.) Or, to examine the return value of png_get_tRNS() and see if it returns non-zero. Regardless, the new patch (str2449-v2.patch) simply just initialises num_trans to zero. This way png_get_tRNS() can leave num_trans untouched which (I assume) would be the same as there is no transparent pixels. [1] I noticed that index PNGs caused the crash because I have another patch I use that adds "default.kde4" to the icondirs array in src/Fl_File_Icon2.cxx. I always get the unknown icon for files and haven't really looked into why the kde4 icons don't show in the file browser. But that is another issue not for this STR. [2] Version installed by openSUSE 11.3, KDE 4.5.3 Link: http://www.fltk.org/str.php?L2449 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
