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 <[EMAIL PROTECTED]> -----

Date: Tue, 11 Apr 2000 21:47:08 +0100
From: Nick Lamb <[EMAIL PROTECTED]>
To: Sven Neumann <[EMAIL PROTECTED]>
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.


----- End forwarded message -----

Reply via email to