Sven asked me to forward this to the list, the quoted message from him is apparently in answer to my query as to why PNG should take responsibility for removing R,G,B from RGBA where A == 0. As always discussion is interesting but code speaks louder. ----- Forwarded message from Nick Lamb <njl98r@xxxxxxxxxxxxxxx> ----- Date: Tue, 11 Apr 2000 21:47:08 +0100 From: Nick Lamb <njl98r@xxxxxxxxxxxxxxx> To: Sven Neumann <neumanns@xxxxxxxxxxxxxxxxxx> Subject: Re: Export behaviour for fully transparent backgrounds On Tue, Apr 11, 2000 at 04:38:30PM +0200, Sven Neumann wrote: > Hi, > > Because I think this is a very PNG-centric problem. There might be other > fileformats that could benefit from setting invisible parts to a uniform > color Yes, probably TIFF, SGI, TGA and XCF for a start, likely also CEL and various other less common standards. In all of them it would have to be optional (there can be reasons to preserve R,G,B when A == 0) and we'd end up implementing this several times :( > but PNG seems to be the only non-indexed format supporting > transparency out there on the web. I do not think that filesize is > that important for non-web formats. Well, the web isn't really using RGBA PNG, it's only been around for a few years, and standards take longer than one remembers to become universal. Microsoft IE is working very hard to prevent PNG from gaining acceptance (*) and Mozilla doesn't have working Adam7, let alone transparency. I think this is a general problem, to be solved by Gimp itself, or in libgimp, and I'll stick by that opinion. It is not solely file size at issue - users can be caught out by the "hidden past" in their exported images. A wave of the "UnErase" brush reveals all. (*) PNG bug reports from 4.0 are still not fixed on any platform, and indeed further regressions have been reported in IE 4.5, and 5.0 on Windows 9x/ NT. Accident? I don't think so. Nick. ----- End forwarded message -----
