Diebold won't allow you to overvote, but it won't object if you undervote on a contest. I didn't try to see what happens if you simply hit the "cast ballot" without voting in any contest.
I know of one voter whose choice was misread by a Diebold machine today in Maryland. When she tried to correct it, the machine beeped at her. Embarrassed, and feeling that the particular contest wasn't that important, she decided to let it stand.
The bug is demonstrated by the page at http://pmt.sf.net/gamma_test The gamma=1/2.2 patch is supposed to match the GIF, JPEG, and other unlabeled content, but when viewed with IE, the gamma=1/1.96 patch matches instead.
Prior to IE7 there were two major things wrong with the PNG support. One was the alpha channel opacity, which thankfully is now working. The other is the gamma handling which is still wrong. See http://pmt.sf.net/gamma_test. Other browsers match the gamma=1/2.2 patches with GIF, JPEG and other unlabeled material, while IE matches them with gamma=1/1.96. This defeats any effort to match colors in a PNG with other items on a web page.
In http://pmt.sourceforge.net/gamma_test/ on a normal PC, the GIF, JPEG, sRGB patches and the unlabeled patches should match gamma=1/2.2 but they match gamma=1/1.96 instead. This foils attempts to match images with backgrounds and images in other formats.
The workaround is to remove the gAMA chunk from PNG files while preserving the sRGB chunk.
That is a disclaimer, not an anti-nuclear political thing. It means that Sun cannot be held responsible if the nuclear plant that you designed with their software melts down.
I'd like to see a new/old flag, where "new" is any comments that have been added since my last visit to the article. Also a way to set the threshold to expand only the new comments.
1/2.2 is the closest fit of sRGB to a pure gamma curve and is not visibly different. The 1/1.96 that IE7 uses is visibly different. Different enough that it screws up any attempt to match a PNG with a background color. The best workaround that I know (other than requiring your visitors to use Firefox) is to remove the gAMA chunk from the PNG and only store the sRGB chunk. IE will ignore the sRGB chunk but that's OK; the colors will match the rest of the page properly. Other browsers will recognize the sRGB chunk and handle it properly. The recommendation in the PNG spec to supply both gAMA and sRGB chunks can be safely ignored.
The issue of whether gamma is accurate or not is beside the point. The problem is that a PNG with gamma=1/2.2 is displayed differently by IE7 than a PNG without a gamma chunk or a GIF or JPEG or the HTML background, when the target is a PC monitor (whatever the actual gamma of the monitor).
So long as their nearest competitor, Firefox, is deliberately suppressing lossless animation, IE has no reason to work on it either. The MNG/JNG restoration bug (#18574) for Firefox/Seamonkey currently has 804 votes, and has been the leading voted-for mozilla bug for about 3 years. For a while it looked as though it had a chance to go in Seamonkey, but the same individuals who don't want it in Firefox have prevented it from going in Seamonkey either.
No, I don't think it is at all reasonable to deliver a file with the PNG signature, PNG extension, and image/png MIME type and then gripe because IE8 or IE9 only shows the base PNG and not the animation that is hidden in an aPNG chunk.
APNG should be served with a video mime type since it is animation (so should ani-gif but that's another problem). Better yet there should be an "animation" mime type. Since IE8 or whatever would probably use the PNG renderer for APNG, the gamma would probably still be wrong.
If your suggestion is to use image/png to convey APNGs because IE7-8-9 are only going to see the base PNG and not the animation, then from the IE perspective it is fine but from the perspective of all the browsers that do support APNG it would be incorrect.
PNG files with gamma=1/2.2 are still rendered differently from PNG files with the sRGB chunk and from untagged images. See http://pmt.sf.net/gamma_test where the 1/2.2 patches should match and the 1/1.96 patches should be lighter (use Firefox or almost any other browser to see how the page should be rendered).
I attempted to install IE7b3 but failed. I did successfully remove IE7b2 (re-exposing IE6) but now I just get a new "Internet Explorer Troubleshooting" button (with a Firefox icon!) that doesn't do anything. Anyhow, someone please go to http://pmt.sourceforge.net/gamma_test/index.html and see if it passes the gamma test. IE7b2 was still failing, with the gamma=1.96 patch matching the background better than gamma=2.2.
Recent versions of ImageMagick retain the original dimensions when cropping and storing in an image format (PNG, GIF, others) that are capable of storing offsets. You can use the +page or +repage option to get rid of the offset info.
Maybe you were looking at the user identification string, which says "Mozilla/5.0" for Firefox and the other major browsers. For example, mine identifies itself as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060202 Firefox/1.5.0.1 (mahowi)" when I check Help->about Firefox Community Edition
In the previous months, I've downloaded FireFox 1.01, 1.02, 1.03, 1.04, 1.05, 1.06! As FireFox does not download a patch for a security update and one has to download the whole thing again (quite silly in my opinion), does these 6 downloads count as 1 or as 6 in Mozilla's book? It would be interesting to see a graph of downloads versus date. If you count as six downloads, then the graph would likely show bumps for a few days following each release. If you count as only one, then the graph would be smoother. In fact I count as zero, because I use third-party (amano) downloads that support MNG.
How do you know that someone won't claim a patent on PNG/MNG 15 years from now? They were published in 1995/1996. So any patent would have had to be filed in 1996 or 1997. Incidentally, PNG's "progressive display" method was new and probably patentable, but its inventor chose to donate it for free use in the PNG spec.
Slashdot Mirror
Diebold won't allow you to overvote, but it won't object if you undervote on a contest. I didn't try to see what happens if you simply hit the "cast ballot" without voting in any contest.
I know of one voter whose choice was misread by a Diebold machine today in Maryland. When she tried to correct it, the machine beeped at her. Embarrassed, and feeling that the particular contest wasn't that important, she decided to let it stand.
The gamma issue isn't fixed.
The bug is demonstrated by the page at http://pmt.sf.net/gamma_test
The gamma=1/2.2 patch is supposed to match the GIF, JPEG, and other unlabeled content, but when viewed with IE, the gamma=1/1.96 patch matches instead.
Prior to IE7 there were two major things wrong with the PNG support. One was the alpha channel opacity, which thankfully is now working. The other is the gamma handling which is still wrong. See http://pmt.sf.net/gamma_test. Other browsers match the gamma=1/2.2 patches with GIF, JPEG and other unlabeled material, while IE matches them with gamma=1/1.96. This defeats any effort to match colors in a PNG with other items on a web page.
In http://pmt.sourceforge.net/gamma_test/
on a normal PC, the GIF, JPEG, sRGB patches and the unlabeled patches
should match gamma=1/2.2 but they match gamma=1/1.96 instead.
This foils attempts to match images with backgrounds and images in other formats.
The workaround is to remove the gAMA chunk from PNG files while preserving
the sRGB chunk.
There is an addon called "distrust" that is supposed to do this. I haven't tried it, but here it is:
https://addons.mozilla.org/firefox/1559/
That is a disclaimer, not an anti-nuclear political thing. It means that Sun cannot be held responsible if the nuclear plant that you designed with their software melts down.
I'd like to see a new/old flag, where "new" is any comments that have been added since my last visit to the article. Also a way to set the threshold to expand only the new comments.
1/2.2 is the closest fit of sRGB to a pure gamma curve and is not visibly different. The 1/1.96 that IE7 uses is visibly different. Different enough that it screws up any attempt to match a PNG with a background color. The best workaround that I know (other than requiring your visitors to use Firefox) is to remove the gAMA chunk from the PNG and only store the sRGB chunk. IE will ignore the sRGB chunk but that's OK; the colors will match the rest of the page properly. Other browsers will recognize the sRGB chunk and handle it properly. The recommendation in the PNG spec to supply both gAMA and sRGB chunks can be safely ignored.
The issue of whether gamma is accurate or not is beside the point. The problem is that a PNG with gamma=1/2.2 is displayed differently by IE7 than a PNG without a gamma chunk or a GIF or JPEG or the HTML background, when the target is a PC monitor (whatever the actual gamma of the monitor).
So long as their nearest competitor, Firefox, is deliberately suppressing lossless animation, IE has no reason to work on it either. The MNG/JNG restoration bug (#18574) for Firefox/Seamonkey currently has 804 votes, and has been the leading voted-for mozilla bug for about 3 years. For a while it looked as though it had a chance to go in Seamonkey, but the same individuals who don't want it in Firefox have prevented it from going in Seamonkey either.
No, I don't think it is at all reasonable to deliver a file with the PNG signature, PNG extension, and image/png MIME type and then gripe because IE8 or IE9 only shows the base PNG and not the animation that is hidden in an aPNG chunk.
APNG should be served with a video mime type since it is animation (so should ani-gif but that's
another problem). Better yet there should be an "animation" mime type. Since IE8 or whatever would probably use the PNG renderer for APNG, the gamma would probably still be wrong.
If your suggestion is to use image/png to convey APNGs because IE7-8-9 are only going to see the base PNG and not the animation, then from the IE perspective it is fine but from the perspective of all the browsers that do support APNG it would be incorrect.
PNG files with gamma=1/2.2 are still rendered differently from PNG files with the sRGB chunk
and from untagged images. See http://pmt.sf.net/gamma_test where the 1/2.2 patches
should match and the 1/1.96 patches should be lighter (use Firefox or almost any other
browser to see how the page should be rendered).
I attempted to install IE7b3 but failed. I did successfully remove IE7b2 (re-exposing IE6) but now I just get a new "Internet Explorer Troubleshooting" button (with a Firefox icon!) that doesn't do anything. Anyhow, someone please go to http://pmt.sourceforge.net/gamma_test/index.html and see if it passes the gamma test. IE7b2 was still failing, with the gamma=1.96 patch matching the background better than gamma=2.2.
Cray CTO Steve Scott says, 'The Cray motto is: adapt the system to the application - not the application to the system.'
That's a good motto
Yeah. But having spent a good part of my career sweating over scientific
codes line by line to make them "vectorize" on the Cray, I wonder.
MNG support is at http://mngzilla.sf.net/
includes binaries and patches. We were
tossed out of bug #18574 in December.
There is a list of MNG-supporting applications at
http://www.libpng.org/pub/mng/mngapps.html
Recent versions of ImageMagick retain the original dimensions when cropping
and storing in an image format (PNG, GIF, others) that are capable of
storing offsets. You can use the +page or +repage option to get rid of the
offset info.
Maybe you were looking at the user identification string, which says "Mozilla/5.0" for Firefox and the other major browsers. For example, mine identifies itself as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060202 Firefox/1.5.0.1 (mahowi)" when I check Help->about Firefox Community Edition
http://www.washingtonpost.com/wp-dyn/content/artic le/2006/02/03/AR2006020302610.html
In the previous months, I've downloaded FireFox 1.01, 1.02, 1.03, 1.04, 1.05, 1.06! As FireFox does not download a patch for a security update and one has to download the whole thing again (quite silly in my opinion), does these 6 downloads count as 1 or as 6 in Mozilla's book?
It would be interesting to see a graph of downloads versus date. If you count as six downloads, then the graph would likely show bumps for a few days following each release. If you count as only one, then the graph would be smoother. In fact I count as zero, because I use third-party (amano) downloads that support MNG.
How do you know that someone won't claim a patent on PNG/MNG 15 years from now?
They were published in 1995/1996. So any patent would have had to be filed in 1996 or 1997. Incidentally, PNG's "progressive display" method was new and probably patentable, but its inventor chose to donate it for free use in the PNG spec.
March 7, 1995, birth of the Portable Network Graphics (PNG) format.
Yes the "advanced" search menu (with dates) is still there, but it doesn't work any more.