User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: see: http://homepage.ntlworld.com/bobosola/ http://support.microsoft.com/default.aspx?scid=kb;en-us;294714 http://www.koivi.com/ie-png-transparency/ the solution does not work for backgrounds. DOH! made the padlock a GIF. Reproducible: Always Steps to Reproduce: Expected Results: transparency...
this issue was caused by bug 252810
Comment on attachment 159428 [details] [diff] [review] patch I'm okay with this, though working around an MSIE bug sucks.
Clearing approval flag when no review+ flags are available.
Since it went into 2.18 as well...
Comment on attachment 159428 [details] [diff] [review] patch If you're going to deny review, I need to know why. Care to explain?
"IE sux. Tell them to get Firefox." ;) yeehah. Holding approvals pending finding out what vladd doesn't like about it.
IBM's GIF patent will expire on 11 August 2006 - see http://www.gnu.org/philosophy/gif.html#venuenote . This might be outdated, by the way, but I still think GIF is not the way to go. Proprietary patents should something that must be avoided. We need to take a step back and look at the bigger picture and at this project's goal: be the best open source bug tracking system on the market. Open source means MPL, which implies a bunch of legal stuff. Been able to "deliver" the code-base is much more important than UI. Having a nice UI in IE6 and a code that violates a bunch of patents is less preferable than one that does not violate the patent. Especially since we can have both (nice UI in IE6 and GIF-free) with a little trouble. The 3rd link posted in comment 0 gives nice solutions (if it's not available, try its Google cache: http://188.8.131.52/search?q=cache%3Ahttp%3A%2F%2Fwww.koivi.com%2Fie-png-transparency%2F&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official ) The GIF patent might be expired by now in all countries, or maybe not (and only one of those lawyer guys could research all countries and the actual status). IBM still seems to own the LZW compression algorithm, but even if it doesn't, I still think moving away from GIF is a very good idea. Of course Dave has the final word on this :)
I have a license from Adobe Systems to use Adobe Photoshop, this inturn has a license to encode GIF files, which is where I did it. Here is what I did. open the PNG in MS Photo viewer (adobe reports it as broken) select all copy in photoshop new, paste wand tol 0, select border, add select inside shackle, delete. save for web, GIF, transparency LICENSE valid... no patents infringed. as to that code in link 3 to much hack to put in BZ
1. This means that developers won't be able to modify the gif file, so developers won't be able to contribute to our CVS code base. 2. GIFs are derived work of the LZW compression algorithm. Just because they are nice guys doesn't mean that they won't be able to charge on the derived work in the future. Since not everybody can afford an Adobe license, I'd prefer to move away from the GIF patent piradigm. CCing Gerv for patent-related comments.
Comment on attachment 159428 [details] [diff] [review] patch agreed, overriding the review-. The patent covers encoding of GIFs, it does not cover transmission of pre-encoded ones.
(In reply to comment #9) > IBM's GIF patent will expire on 11 August 2006 - see > http://www.gnu.org/philosophy/gif.html#venuenote . This might be outdated, by > the way, but I still think GIF is not the way to go. > Proprietary patents should something that must be avoided. We need to take a > step back and look at the bigger picture and at this project's goal: be the best > open source bug tracking system on the market. Open source means MPL, which > implies a bunch of legal stuff. this has nothing to do with OWNING a gif file. BZ does not render it on the fly. (In reply to comment #11) > 1. This means that developers won't be able to modify the gif file, so > developers won't be able to contribute to our CVS code base. yes they can, just get a ligit GIF editor or viewer and save as other format > 2. GIFs are derived work of the LZW compression algorithm. Just because they are > nice guys doesn't mean that they won't be able to charge on the derived work in > the future. Has no relevance, there is a legal contract in place from Adobe Systems. > Since not everybody can afford an Adobe license, I'd prefer to move away from > the GIF patent piradigm. CCing Gerv for patent-related comments. fine then email the png files to email@example.com and within 2 business days we will submit a GIF version. This is very SILLY. And us encoding the GIFs was not a joke.
True. It's not like we don't have already docs/images/*.gif in the CVS repository. But all the world is moving away from GIF, and it certainly seems that we shouldn't be doing the opposite. But, if you want a little hack, go ahead and do it. Someone complained to me that Bugzilla should be rewritten because it's full of hacks. Since then I tried to avoid that and write clean code. Sure, in a world, it's not possible to find the perfect solution and you must do compromises. The problem is that the more often you compromise, the more dirty your codebase becomes. Moving towards a patent-free image format would go a lot in the right direction. But there will always be a lynk-like browser for which we will have to compromise. Sure, in design, that one-liner function will look clean, but in reality, that one-hundred line code will work, because it deals with real-life incompatibilities and situations. :) I'll redraw my review- and let Dave decide :)
Oops, I haven't seen comment #12 :)
(In reply to comment #11) > 1. This means that developers won't be able to modify the gif file, so > developers won't be able to contribute to our CVS code base. There are lots of free programs which can open a GIF and save it as something else, and there's actually legal GIF encoders which are free on some platforms (GraphicConverter for Mac OS X, for example - it's licensed, and is shareware, but saving as GIF still works in the unregistered (free) version) > 2. GIFs are derived work of the LZW compression algorithm. Just because they > are nice guys doesn't mean that they won't be able to charge on the derived > work in the future. The patent covers encoding with LZW. The patent specifically excludes decoding, which means anything that views it (i.e. web browser) is safe. Niether does it cover storage and transmission of the interim product, so I don't buy this argument. We've had 1x1.gif in the bugzilla directory since the beginning of Bugzilla. But I'll await Gerv's opinion.
err, let's put these back for now, I'm still waiting for Gerv. But unless he says something profound I'm probably going to approve it anyway.
> which means anything that views it (i.e. web browser) is safe. The issue is not decoding but transmission. You can't redistribute the derived work without the patent owner's approval. Like I said before, in our case they are "good guys" in this case and decided not to forbid transmission, so that's irrelevant anyway.
Someone is going to have to step back and explain to me exactly what this feature is, because the initial bug report really doesn't explain it very well. But, on the GIF point, most free software is now acquiring GIF support; general consensus is that it's OK. See http://burnallgifs.org/ - "GIFs are now patent-free". IBM's remaining GIF patent (if it would hold up in court; there's doubt about that) applies to software used to encode GIFs. Therefore there is no problem in us redistributing a GIF. It is true that someone may need non-free software to modify it (although see above); while not an ideal situation, I wouldn't say that it makes the file itself non-free. Vlad is fortunately incorrect - GIFs are not a derived work of LZW, just as my compiled C code is not a derived work of gcc. And the patent does not cover transmission of GIFs via its algorithm; you can't get a patent on sending a particular configuration of bits over the Internet. Gerv
in Internet explorer PNG with transparency get all messed up, and look hideous. to the point they are distracting away from the ID column.
OK, how about a way to avoid this whole GIF war... the article in the third link suggests that PNG has a binary transparency mode (as opposed to blended alpha) which IE *does* support. Can we rebuild the PNG file with a 1-bit alpha mask rather than 24-bit?
(In reply to comment #21) > Can we rebuild the PNG file with a 1-bit alpha mask rather than 24-bit? OK, GraphicConverter and Photoshop both claim there is no alpha channel on that PNG file. Huh?
Created attachment 159449 [details] new png IE compatible oh! I should of looked at the obvious when Adobe did not like it.... silly me, sorry to ruffle so many panties.
kiko, that work for you?
> in Internet explorer PNG with transparency get all messed up, and look hideous. > to the point they are distracting away from the ID column. Further back :-) Where are these lock icons, when do they appear, and how can I see one? And yes, IE supports 1-bit transparency on PNGs just like GIF. Gerv
(In reply to comment #25) > Further back :-) Where are these lock icons, when do they appear, and how > can I see one? http://landfill.bugzilla.org/bugzilla-tip/buglist.cgi?short_desc_type=allwordssubstr&short_desc=foo Make sure you're logged in as firstname.lastname@example.org. See bugs 1376 and 1933 in that buglist. The padlock icon is used next to secured bugs instead of the gray background now, because we had too many css conflicts with the gray background (not to mention it was darn ugly on sites that changed the background color otherwise)
Comment on attachment 159449 [details] new png IE compatible This works fine and should keep Vlad happy (we want to keep Vlad happy of course).
and request checkin more to go along with this is in bug 261210
Landed in trunk and branch. /cvsroot/mozilla/webtools/bugzilla/images/padlock.png,v <-- padlock.png new revision: 1.2; previous revision: 1.1 /cvsroot/mozilla/webtools/bugzilla/Attic/padlock.png,v <-- padlock.png new revision: 184.108.40.206; previous revision: 220.127.116.11