text:
Are there any plans to implement animated .PNG, aka .MNG (Multiple-PNG) images?
At www.cdrom.com/pub/mng you can find technical details describing this new
image format.
There is a movement underway to completely replace .GIF images with .PNG images
on the web(because of a licensing fee that is asked for .GIF supporting
software) but that will only happen if the .PNG format will also support
Reassigning to PNG component owner, Greg.
Is MNG a finalised standard yet?
MNG is a frozen proto-standard; it will not be officially standardized until
there are at least a couple of complete implementations available--one often
discovers subtle little problems in a spec only by writing the code and testing
the thing. Currently there's a fairly complete MNG encoder/decoder available as
a Windows-only binary, but I don't think it's an optimizing encoder. There's
also full MNG-LC encode/decode support in ImageMagick (i.e., Open Source), which
is sufficient to allow fully lossless conversion of animated GIFs with the sole
exception of the kind that use the one (very rare) disposal method. The only
commercial app with any support is Paint Shop Pro (or Animation Shop, now that
it's sort of a separate product), but it hasn't been updated to the current spec
and writes an out-of-date MHDR chunk.
As for implementing MNG in Mozilla, yes, that's definitely been in the back of
my mind as the next obvious step after PNG is working correctly, and I've tried
to keep that in mind as I've rewritten bits of the PNG code. But I personally
don't have the cycles to do it, and I haven't seen much action on the MNG list,
either. That is, there are only three guys on the list who have done *any* real
MNG coding (I don't count my own extensions to pngcheck since it's really only a
meta-info dumper), and only two of them have released anything. Interested
folks really should think about chipping in, perhaps starting with some
extensions to libpng to make it more MNG-friendly. (A separate libmng probably
isn't necessary or desirable. Feel free to steal from ImageMagick.)
P.S. I'm changing the status to ASSIGNED to avoid getting auto-spammed, but
don't expect any progress from me for at least 6 months, probably longer. (If a
resolution of LATER is preferable, Eli can go ahead and change it to that.)
You have the option of reassigning to firstname.lastname@example.com. Adding [HELP WANTED].
Per e-mail from Greg, he has relinquished PNG component ownership; thus,
reassigning assigned bugs to ImageLib owner.
Reassigning to firstname.lastname@example.com, for anyone who'd like to implement this to
pick up.
Assigning all open "firstname.lastname@example.com" bugs to "email@example.com" to weed
Moving back to firstname.lastname@example.com. This is where the helpwanted will be
assigned until someone picks them up.
*** Bug 37986 has been marked as a duplicate of this bug. ***
info from 37986:
MNG would be a tremendous addition to Mozilla as it would offer all the
features of GIFS with no patent issues. In addition it would allow for true
color animated images compressed as a JPEGs.
You can find more information at...
Are you volunteering to write the mng component?
actually not, I was just adding comments from a dupe. I have no idea where to
even start ;)
Updating URL, removing "helpwanted", and taking bug.
tor rocks!
tor is my hero. isn't it done yet?
seriously though, this feature is an IE5 killer. Throw a few spiffy MNGs up on
popular, anti-microsoft sites, and all their viewers will soon be using the
amazing, stupendous, MNG-capable mozilla.
It is done - I'm working on getting it checked in and helping
to solve the bugs that prevent full integration (see the
dependencies for this bug).
On which platforms have you tested the code? If someone would
volunteer to test on wintel and/or mac (and maybe linux if
you tested on solaris) would be a huge help.
Personally tested on solaris/sparc and linux/ia32. I have written diffs
for the win32 build system, but don't have a system available to attempt
a build. Haven't figured out the mac build system enough to attempt to
make the necessary changes there.
My thought was to get this code checked in behind a --enable-mng configure
flag for unix (plus perhaps the win32 changes), then work on getting the
other platforms running.
Created attachment 9985 [details] [diff] [review]
adding mng/jng to sniffout_mimetype()
changing the configure files won't affect win or mac either way.
We can just not modify the win/mac make scripts to pull in mng.
And we don't want to modify the mime sniffer. Really.
Not until we know why necko is being stupid about understanding the mime type.
Or why the loader isn't finding the decoder component.
pnunn, as part of the MNG landing I would like to checkin the attached patch
for if.cpp to add mng/jng to sniffout_mimetype(). This allows mozilla to
handle MNG/JNG files from servers that don't attach the appropriate mimetype.
This patch also reindents the ART chunk to match the rest of the code and
includes the gross hack to let the MNG decoder handle two mimetypes (by
pretending JNG files are video/x-mng).
Along with the unix build system changes I've made the necessary changes
to config/config.mak and modules/libimg/makefile.win that should allow
mng-capable builds on win32 by setting MOZ_MNG=1. The build system
changes have been reviewed by cls.
I don't want the mime sniffer changes checked in.
We have to respect what a web server sends. Assuming
that we know better what mime type is sent is arrogant
and ultimately confusing.
If the component loader is not finding the mng decoder, we
need to find out what's wrong. Not paste over the problem
with 'fixit' code.
If you need to test how the component loader is working,
reference the mng test file by way of an html page, with
an <img> tag. This will assure you the data is routed to
the image lib.
The mime sniffer is there to override setting that may occur
on certain classes of browser images. But if the data stream
doesn't match anything in the mime sniffer's list, the component
should be loaded with the mime type sent from necko.
This is the part that is broken. There should be a way to
add a mime mapping with file extension in necko.
I'm adding Jud and Gagan to this list so they are aware of
the issue.
If you say that we should believe what the server tells us, why is the
mime sniffer there at all? Currently if I rename a gif file to foo.png,
mozilla will ignore the image/png mimetype and feed the stream to the gif
decoder. Mozilla should trust that the mimetype and attempt to decode it
with the png decoder.
The mime sniffer is there for some of the basic image mime types
that are commonly used as part of the browser and browser chrome.
It minimizes some of the more common place user error screw ups.
But for the browser to be able to have a mechanism to drop in new
image format decoder components, we have to trust that some users
somewhere have a clue and can create a new mime type mapping.
If we police all the data streams, then we should test all data streams
in necko just in case they _might be_ image data. And the browser
would be so slow it would be unusable.
I see these as the basic issues:
1. Where should the user add the mime type mapping to necko?
2. Is the component loading correctly? Is the correct mime type
passed through to imglib? Why can't the component be loaded?
If we have the answers to these issues and it makes sense to add
in a _temporary_ mng signature to the imglib mime sniffer until
we can get the correct structures in place in necko, I'd be ok with
checking it in. But I don't want to do it, until we have a clear
view of what is wrong and how to fix it.
ps. I can see cls oking the X config system changes, but
can he really test the win changes? I had the impression he is an
unix only guy.
Since the mng/mngcom subdirectory makefile.win are untested, I'll leave off
the win32 build system changes in my checkin and attach them here for the
Code checked in along with unix build system changes to add a --enable-mng
option. Here are the current limitations (which will drop away as dependent
bugs are resolved): MNG files, limited to roughly 256Kb, must be specified
inline (i.e. <img src="foo.mng">).
For people on win32, hopefully all that's needed is applying the following
patch, setting MOZ_MNG=1, and making in modules/libimg. More realistically
you'll probably need to tweak modules/libimng/mng{com}/makefile.win. Please
try it out and report any successes or patches needed.
We could use some help from a MacOS person to get it building there.
Index: modules/libimg/makefile.win
RCS file: /cvsroot/mozilla/modules/libimg/makefile.win,v
retrieving revision 3.6
diff -u -r3.6 makefile.win
--- makefile.win 1999/11/06 03:31:07 3.6
+++ makefile.win 2000/06/12 23:40:43
@@ -20,6 +20,10 @@
-DIRS = public src public_com png pngcom jpgcom gifcom
+DIRS = public src public_com png pngcom jpgcom gifcom \
+!if defined(MOZ_MNG)
+ mng mngcom \
!include $(DEPTH)\config\rules.mak
This is Great! I can't wait to play with this...
[#whatever pnunn said!]
Most of the thanks should go to Gerard Juyn (firstname.lastname@example.com), who wrote
the excellent libmng and graciously made modifications to the library to
ease integration with mozilla.
I'm going to a meeting today to find out who needs to work
on user specified mime mapping (like helper apps, but with
components.). I will be doing some tests to see where the mime
type is 1)not getting set 2)if set, where it is lost.
To get libmng to build on Windows, I indeed had to tweak makefile.win.
Created attachment 10226 [details] [diff] [review]
Patch to get libmng building on Windows
Copy/paste/modify error on my part - patch checked in. Thanks!
The MNG decoder was turned on by default today on all platforms,
and is now in the nightly builds. Give it a try and if you find
any bugs other than the current dependencies of this bug please
file a bug against me. Thanks.
Gamma correction dosn't seem to work on Windows. Added dependency on bug 44866
Insofar as (1) basic MNG support is enabled on all platforms, (2) basic MNG
support works on all platforms (well, Linux and Win32, at least), and (3) MNG
gamma correction works (tested with Win32 build 2000072008), this bug should not
block 8415--everything necessary for chrome support is in place, as far as I can
tell. The only MNG features on Gerard's test suites
(http://www.libmng.com/MNGsuite/ and http://www.libmng.com/JNGsuite/) that do
NOT work, as far as I can tell, are color correction--either via chromaticity
chunks or ICC profiles--and JNG. But neither is a blocker for chrome.
MNG is still not working in chrome. I have finished a new skin for bug 8415, and
the MNGs I attempted to use did not work. They are included in the skin for use
as a test case. Just modify communicatior/skins/brand.css to test the throbber.
As I said in 8415, MNGs not working in chrome is most likely due to bug
tor - is there an issue with MNG on Mac still (this is implied by an earlier
comment)? If so, does it need fixing by RTM?
I don't know of any mac-specific problems other than the gamma
correction, which affects mac more than other platforms.
*** Bug 66963 has been marked as a duplicate of this bug. ***
MNG support does not appear to work in Build 20010430 Win98. Is anyone else
experiencing this problem?
libpr0n (the new image library) does not have a MNG decoder. I have half of
such a decoder in my tree - works fine, but leaks all images. I'm planning
on getting back to it before 0.9.1.
> libpr0n
Ha ha very funny. Now please change it. Political enemies of the
organizations that supported libpng/libmng in the first place could
have a field day with it.
Image library name discussion --> bug 66984
randeg: libpr0n is the name of the entire new image library, not just the
PNG/MNG part. Besides, it's also called imglib2 (IIRC) if you want to be
politically correct.
Not sure what you mean by "political enemies of the organizations that
supported libpng/libmng". It's an image rendering library, not welfare reform.
> Not sure what you mean by "political enemies of the organizations that
> supported libpng/libmng". It's an image rendering library, not welfare reform.
enemies: Radio talk show hosts and the like.
organizations: Government laboratories
support: Tangible support, e.g., web/ftp hosting
The progress of MNG is disgusting (it's literally moving backwards). Adding
helpwanted, regression, and *strongly* suggesting for nsbeta1. Many sites out
there still credit Netscape 6/Mozilla with having MNG support from the days when
it actually *did*. Currently Mozilla doesn't support any animated image format
except Unisys' patented GIF89a format.
removing nsbeta1, netscape only
doronr: By your keyword change I am assuming Netscape has fixed MNG for Netscape
6.1. Is this true?
No. He's removing the keywords because they are no longer relevant.
tor has MNG in hand; he's waiting for help with building it on Mac and Windows,
AIUI. Patience :-)
Gerv: Please explain to me how nsbeta1 is no longer relevant.
AIUI, nsbeta1 was NS 6.1 PR 1, which has happened.
My apologies; I was wrong. nsbeta1 is not specific to any release, and no-one
except Netscape employees should be removing Netscape keywords.
IIRC no one removes the nsbeta1 keyword. it is replaced with nsbeta1- if
Netscape doesn't feel it is necessary. However, the next nsbeta1 is going to be
a while in coming, but at least it'll be there for PDT. :-)
"Bugs which have been rejected for consideration in the next Netscape release
will have the nsbeta1 keyword replaced with the nsbeta1- keyword."
--Keyword Description
Yes, and only @netscape.com should be setting nsbeta1(+|-).
I think until MNG works again, we need to put up a release note that MNG *will
not work* with affected versions. This is particularly important since some
sites still say that Mozilla supports MNG.
I've seen that there is a directory modules/libpr0n/decoders/mng in the Mozilla
Tree - how can I enable the MNG Decoder?
Is it working on Win32?
If not, what needs to be done?
Should run fine on windows, though personally I haven't tested the new
decoder on that platform. To build it cd to modules/libpr0n/decoders/mng
and do a make -f makefile.win . Any problems encountered should be
reported in bug 66976.
Zach is supposed to be producing the Mac project files for MNG, but he tells me
he's too swamped to sort it out.
Is this the only thing blocking turning MNG on? Can someone else produce these
I just asked on irc.mozilla.org if anybody would like to create the Mac Project
Files for the MNG Decoder, and peterv said he would do it if he had time; I
should remind him in a day or two.
Couldn't the MNG Decoder turned on on the other platforms while Mac Project
Files are missing?
The REQUIRES Line in the Makefile is completely wrong, the following will work.
I haven't checked makefile.win, but I assume that it needs the same changes.
Index: Makefile.in
RCS file: /cvsroot/mozilla/modules/libpr0n/decoders/mng/Makefile.in,v
retrieving revision 1.4
diff -u -r1.4 Makefile.in
--- Makefile.in 2001/09/18 13:38:03 1.4
+++ Makefile.in 2001/10/01 13:37:11
@@ -32,6 +32,12 @@
xpcom \
necko \
gfx \
gfx2 \
imglib2 \
timer \
= nsMNGDecoder.cpp nsMNGFactory.cpp imgContainerMNG.cpp
gerv: mac project files, getting r/sr on the mng decoder, and the minor build
tweaks to turn on mng by default are all that's left.
tor: are you chasing r and sr on the decoder at the moment?
gerv: no - I was waiting until it was built and tested on all tier-1
platforms before trying for a review. A four month old review (when
the decoder was ready) would be considered stale.
Should this bug still depend on 41333, now that MNG is on the trunk?
Probably not.
Right, but it does need to be fixed. The number of tables that needed to
be modified to add a new image mimetype is insane. If Christian hadn't done
the hard work of finding all of them for ICO I probably wouldn't have bothered
with a full integration of MNG.
Since MNG is now turned on everywhere and chromacity correction is somewhat
low profile, I'm closing this bug. If you find MNG support bugs, please file
them in bugzilla against me.
Verified MNG's working on win XP build 2002032803, linux build 2002040211 and
Mac OS X build 2002040203
There is a move afoot to remove MNG/JNG support (See bug #195280), therefore
this bug should be reopened. A vote for this bug should be considered a
vote against 195280. Glenn
Help still wanted (libmng maintenance/support within imagelib), regression
threatened (bug #195280). Not sure if reopening will work, but trying anyway...
I'll work within libmng to explore ways to reduce its footprint. Glenn
Now that bug #195280 has been "FIXED", please change this bug's title from
"retain support for MNG ..." to "restore support for MNG ...". Glenn
Reassigning since the bug is currently assiged to the person who CAUSED this bug.
Created attachment 124876 [details] [diff] [review]
Reversal of mng removal patch
This is just tor's patch for bug 195280 (attachment 117320 [details] [diff] [review]) reversed. It
only affects the build system.
This bug has 30 CCs and 39 votes. 50 of either will make this bug block bug 163993.
Created attachment 124879 [details]
MNG testcase
Give up Mozilla is doomed - at least if they go on removing good an interesting
features like this.
Tim: I'd be interested in seeing an alternate patch that puts MNG/JNG
support in the extensions instead of back in libimg2.
Removing MNG saved what, 300kb on my 40+ GB drive? Whoop-de-doo!
Re: comment 81, I'd love to, but build config changes are out of my ballpark
("my" patch was just running tor's patch through a reversing program).
Created attachment 124907 [details]
Relocate old MNG decoder files
Here is a zip containing the old files in a new location
(extensions/mng). I fixed the depth in Makefile.in, which is the only
change at all in any of the files.
--- modules/libpr0n/decoders/mng/Makefile.in 2003-01-30 00:53:12.000000000
+++ extensions/mng/Makefile.in 2003-06-04 10:53:52.000000000 -0400
@@ -17,7 +17,7 @@
# Contributor(s):
# Tim Rowley <firstname.lastname@example.com>
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
I don't know what changes would need to be made to other parts of the build
system (probably the extensions/Makefile.in file and maybe the configure.in
An XPI for MNG support is available at http://stud4.tuwien.ac.at/~e0225227/.
Versions for Linux and windows can be found there. other operating systems may
Tim wrote:
> Created an attachment (id=124907)
> Relocate old MNG decoder files
> Here is a zip containing the old files in a new location
> (extensions/mng).
Moving MNG support to extensions/mng/ may not be a good solution since much of
the stuff in extensions/ is not part of the default build and/or will be
explicitly turned-off by some vendors if there is a way to do so (bug 133534 is
one example how things can go really worse... ;-( ).
Is there an existing architecture to make image decoders pluggable and/or
in-/excludeable at build time?
If not, we should put one in place right now, as we apparently have the need for
kairo: we have both. at compile time, there's --enable-image-decoders (iirc);
and at a later time, you can just drop in a component (well almost, but it works
quite good).
mozilla/extensions exists so that vendors/embedors/distributors/whoever can
disable things that they don't need, which is exactly the case for MNG as well
as many other things in mozilla (including .bmp and .ico).
Why would Crocodile Clips need to include the code for MNG decoding in their
software for teaching math? Or why should ACME-Handhelds need to include a
xprint in their handheld browser? The answer is obviously that they don't.
If someone doesn't want to ship with a certain part of the browser we should not
force them to. That will only cause distributors to choose other browsers.
So the fix for this bug is to find someone who is willing to own MNG (which it
looks like Glenn is), and then place it in mozilla/extensions
So why do we have to move it to extensions and not use --enable-image-decoders
for enabling/disabling? I think it would keep a clearer structure.
Anyway, it's good to see MNG support being at least optional, if not enabled by
default, again.
i just stumbled about this occasionally... but i'd like to see the return, too.
especially since merging MNG into libimg2 and removing redundant code (PNG)
would be more than acceptable in my opinion. there's nothing more beatiful than
8bit transparency. and as said in bug 195280 gerald would volunteer to maintain
this. but well. should we carry this discussion over to mozillazine? maybe this
way more people would get to know about this. and help to solve the issue.
> Moving MNG support to extensions/mng/ may not be a good solution
Leaving it where it was is of course a better solution, but the module
owner doesn't want it there and has already removed it. Putting it in
extensions/ is a stopgap measure.
>So the fix for this bug is to find someone who is willing to own MNG
>(which it looks like Glenn is), and then place it in mozilla/extensions
Yes I am willing, although I don't seem to be empowered to mark the bug
ASSIGNED. I will need to rely on those who are "empowered" to help out.
If you want the permissions to modify/confirm a bug you just need to shoot an
e-mail to <firstname.lastname@example.com>.
I don't think this bug should depend on bug 44866. That's color-correction stuff
that's far from being implemented anywhere in Moz AFAIK.
Will help where I can, but I've no experience with graphics.
Created attachment 125108 [details]
comment 85 - linux XPIs
Just so these XPIs are as available as bugzilla is, here is a zip of the web
page and XPIs mentioned in comment 85.
This is split into four files since the max size is 300K. You only need the one
for your platform.
Created attachment 125110 [details]
comment 85 - OSX and OS/2
Created attachment 125113 [details]
comment 85 - solaris/sparc 2.7 and 2.8
Created attachment 125114 [details]
comment 85 - windows
Please let's stop crippling away important Mozilla features to make it more like
Internet Explorer.
Mozilla was meant to be much more than a simple browser. Mozilla paved the way
for the best support of PNG graphics in the industry. It will pave the way for
JNG and MNG as well.
I've juste added my vote here. 151st one.
Keep up the good work, gang.
- Jacques
Since Glenn is taking care of moving the MNG support to extensions/mng/, why not
restore the old imgmng module until the Glenn's MNG extension is finished?
I am trying to understand why you want to remove the former native MNG support,
but I cannot understand why it must be removed *now*, and cripple some of the
upcoming Mozilla releases!
I've just placed a comparison of the Firebird Throbber.mng from before
the MNG removal, an optimized version of it, and the GIF version that
was recently provided to the Firebird crew, in bug #125280 comment #100
along with a copy of the optimized MNG throbber. I used Greg Roelofs'
"pngquant" and some of my own tools to reduce the filesize from 24kbytes
to under 4kbytes without any effect on its appearance. The GIF is over
8kbytes. Judge for yourself how it looks against the black background.
I suppose it could be optimized too but I don't have anything that writes
compressed GIFs.
The throbber demo is in bug #195280 comment 100. Sorry about the typo.
Note that the comparison is in static PNG format, not MNG, for the benefit
of those who are using a MNG-hobbled browser.
I dont want a browser without MNG support.
I DONT WANT GIF/flash copyright images/animations!!!!!!
I think that MNG can find a manteiner if reeintroduced.
I concur with some other posts above, adding that the *final candidate* stage is
not when this kinds of surgery should take place! That's quite ridiculous.
It's only been removed on the trunk not the branch
Support for MNG should most definitely be restored to Mozilla. Firstly it is the
only way a web site using open standards can implement animation. Secondly, with
the native implementation (rather than plugin) provided by Mozilla one can
insert an animation as easily as inserting an image, which avoids all the
embed/object pain when trying to support XHTML.
Thirdly, a big vote of thanks to the MNG/PNG team, who have made a big
contribution to the future interoperability of the web.
Oh - and fourthly - I'll have to find another reference browser as I use quite a
few mings on my site...
As many, many people here, I'm all for restoring the MNG plugin. Even after reading
the developers' reasons, I fail to understand why they removed something that was
usable. Here's my vote.
Please put it back into the build. As someone stated before. NO PATENT ISSUES
with this format.
People, don't add useless comments like 'ooooh, this has to get back in', that
will NOT help. Just vote for the bug, help with development, make a strong case
with reasons why MNG should be included again. It's a lot better to post nothing
than to post something like 'you NEED to add this again' :\ Just vote and then
either wait or help.
And please read the Bugzilla docs :D
I believe this bug now has more votes than any other bug ever. At 402 votes,
it's passed the PGP RFE. And it got most of them in about 9 days.
FWIW, I'm developing a bioinformatics tool that was to use MNG for genome
mutation visualization. Things like that aren't ever going to show up on an
image search because they're generated dynamically.
Does drivers have an official stance on this issue?
The same question has been nagging me but I've been hesitant to ask it: at what
point are the votes important?
Have a look at http://www.mozillazine.org/talkback.html?article=2702&message=21
for Asa Dotzler's take on votes vs action.
To summarize, votes aren't taken into account at all in and of themselves, if
Netscape decide to work on any RFE, they will typically work on the ones with
more votes first. Votes on groups of bugs along the lines of 'implement this
feature'/'don't implement this feature' (such as this one and its friend)
typically aren't worth the paper they're printed on.
Lewis: All of your statements are valid and _do_ apply to a bug where there is
some work to be done.
However, this is not such a bug. This is a simple management decision. There is
no work involved in 'fixing' this bug. I realize that there is no method by
which people may vote against this bug but perhaps the sheer quantity of
attention to this bug prompts further exploration, yes?
And if indeed our votes "aren't worth the paper they're printed on", you just
insulted 400 voters. So which is it? Should I keep my vote here more move it to
a bug "worth something"?
Perhaps a poll at mozillazine would provide a more representative sample of the
Mozilla user base's opinion?
Sure you can vote against this bug. To do so, vote for bug #195280.
Amusingly, bug 195280 has *lost* votes.
I believe it had 2.
Now 1.
Could be because it was "fixed" I suppose.
Jason: these are not my opinions, but a summary of those found at
http://www.mozillazine.org/talkback.html?article=2702&message=21 .
I suggest you go and read the whole posting, especially the third paragraph
("Even if you just look at Bugzilla account holders as a representative sample
of end-users (I dispute this heavily but for the sake of argument we can discuss
it) then you've still got less than 1/2 of 1% of Bugzilla users voting for a
particular feature or bugfix").
> There is no work involved in 'fixing' this bug.
This is untrue. There is a lot of work, in particular, someone has to own the
MNG code, fixing bugs as they are found, maintaining the code in the face of a
changing Gecko, and working on MNG's significant memory and disk footprint. (I
believe there is a volunteer at the moment, I'm just pointing out that this is
still a lot of work.)
Yes, this bug has currently the largest number of votes in Bugzilla:
I had a discussion with pavlov about this yesterday. He doesn't care about votes
AT ALL: "<stuartk> heikki: if i see like 250k votes, that might be signifigant"
(he got flamed a lot for that, even by other developers, as those numbers are
idiotic and can never be reached)
It's still more interesting to discuss the arguments against MNG:
1) filesize - this got reduced by around 50%, maybe more.
2) GIF and Flash cover this - flash is closed source, about GIF we only need to
see the new throbber on a dark background, how good this is covered.
3) little used - there is only few use for animated images at all, as you also
see only few ani-GIFs. As MNG isn't supported in MSIE for now, 2% of all
animaged images would mean it's more successfull, than Mozilla is ;). Also we
have comments, that it IS used.
4) W3C - just see comment #3 here.
>> There is no work involved in 'fixing' this bug.
>This is untrue. There is a lot of work, in particular, someone has to own the
>MNG code
Fixing this bug simply requires reversing the patch which removed the support -
that is not a lot of work. Whether it's a good idea to have un-owned code in the
tree (or even in the build) is another question, but AIUI, there's quite a bit
of it around.
and even if there is a maintainer, that's only part of the reason it was removed
- another reason was that there is virtually no usage of MNG on the web.
> Yes, this bug has currently the largest number of votes in Bugzilla
> [huge query string]
that, in itself, doesn't change anything. PGP (now pushed down to second place)
has had several hundred votes for a couple of years, and nobody is doing
anything about that. and if you must post query URLs, there's a bookmarklet
which shortens them to something reasonable at
>PGP (now pushed down to second place) has had several hundred votes
>for a couple of years, and nobody is doing anything about that.
The difference is that MNG *was* supported in Mozilla since DEC-2001 and then
was suddenly removed.
Well, now that we know that votes on this bug are completely disregarded (per
comment #121), I'm moving my vote from here to bug #204520 which is where the
work on getting MNG's footprint reduced is occuring.
And Mr. Developer: in the future, please don't tell us to shut up and "just
vote" for something when -- in fact -- you don't care. You just wasted a whole
lot of our time and insulted us, to boot.
Look. People working on the Mozilla codebase can only act this way because the
rest of the Bugzilla community allows it. If people staged some sort of strike
and refused to do anything on Bugzilla (like confirm bugs, verify, develop
testcases, etc.) that might have some sort of effect. If they don't listen to
the votes, then force'em to.
> If they don't listen to the votes, then force'em to.
from Bugzilla Etiquette (http://bugzilla.mozilla.org/page.cgi?id=etiquette.html):
No obligation. "Open Source" is not the same as "the developers must do my
bidding." The only person who has any obligation to fix the bugs you want fixed
is you. Never act as if you expect someone to fix a bug by a particular date or
release. This is merely obnoxious, and is likely to get the bug ignored.
but you can't force anybody to help an app, which moves into the wrong
direction. And this happenes here, if the community (!= all users!) are totally
There are many people who work on the Mozilla Project in a capacity other than
as coder. We do all kinds of things to free the coders' time up to do coding. If
we are going to do that work so that they can code, they could at least have
some deference to that instead of sending us a collective "bite me". I don't
think it bad ettiquette to say, "if you don't do the work we want, we aren't
going to do your grunt work anymore."
**** people off is never a good strategy. You can catch more flies with
honey than vinegar. Let this bug simmer for a while. Posting "me too" comments
(kind of like this one :-) only spam everyone who has voted for this bug and
fill up mailboxes making more people apt to unvote/unCC themselves. And
remember, at the end of the day, it's just a web browser, and it's just a file
I think the reality is that tough decisions do have to be made and in this
instance, one has already been made. The comment that votes are irrelevant was
probably not communicated in the most diplomatic way.... for the most part I'm
sure it is true, otherwise in cases such as this we'd always wind up having to
bow to demands. It is a tough decision.
I think the point being made was that decisions are made and votes won't change
that. The votes are merely to aid the order in which bugs are fixed.
All that said, I don't think it hurts for people to vote if they really believe
in something such as this. But no one should expect that 1000, or 10,000 votes
or whatever means the decision will be reversed. But if you believe in this and
you vote for it then in reality is must have a slight effect on future decisions.
And thats democrasy (even if I can't spell it!).
Myself, I would like to see this feature in place - it does seem like a Good
Thing(TM), but the people making the final decisions know this. They are aware.
They do understand. They do care. Unless I can commit the time to doing the
development myself, then I can't really complain; people do what they can to aid
the common cause. If anyone is sooo upset about this decision, then be proactive
in trying to reverse it - don't start wars!!
Peace and love everyone! Have a great weekend. ;)
I am working with the imglib maintainers on defining a set of criteria that they
want to be met in order to get MNG back in. As soon as they are agreed, I'll let
everyone know what they are.
In the mean time, please continue to vote for this bug if you so wish.
Thanks Gerv, it's really good to see someone @mozilla.org taking care of getting
this discussion in a good shape.
Please cqare to take a look that the creteria can really be met, so we don't get
"you must have 250k votes" or something like that. Again, thanks for steppoing
up and trying to get that discussion and work back to some use again.
<thought mode="crazy">My theory grows to be that pavlov wants MNG to be broadly
supported and well-supported, so he tries to make tons of people upset about the
topic, so that they all do really care of what's happening in the future and
start using MNG for almost everything, as soon as it's supported again</thought>
Just an additional argument for keeping it: I read on German IT newschannels that
there is an ongoing patent issue with the JPEG format. Not very definitive yet,
but maybe the future will bring us bad news.
So having an additional open format at hand could be a big advantage, even if it
is not widely spread yet. Maybe that could also be a reason to begin to ACTIVELY
spread it now.
For the love of god people, this isn't a forum! Shows of moral support, "that's
great," personal attacks, and "me too" posts have no place here. As this is a
codebase steering issue, and not an actual bug (intended functionality, or lack
thereof is not a bug) the arguments for and against bringing back MNG may have
been warented, but only when the arguments made were contruvite and helpful.
I don't think it's really impossible to argue for MNG to be reimplemented
without breaking the rules in the Bugzilla Etiquette. That means no pointless
comments, no trying to FORCE the developers to do what you want, and NO personal
attacks. The nastiness out of some parties is really just getting inappropriate
for a software development bug tracker. I believe "Hey, something's being done?
I think that's great" is also not appropriate.
That being said, I want MNG back in the codebase, but if the developers can't
agree to do it, there's only three things you can do. You can find another
browser, create a set of patches against the trunk which re-adds the
functionality, and release your own binaries, or if there really are enough
people disatisfied with how this was handled with coding skill and time to
maintain such a massive project, as is open source tradition, you can always
fork the codebase. I hope it doesn't come to that last option, but it's always a
possibility, and in someways, it could also be interesting, assuming enough
developers could be found to maintain both Mozilla and the forked project.
Anyway, useless comments down to a minimum, please? Not everyone likes waking up
to 15 e-mails in their mailbox.
Oh, and before anyone else posts something to the last post which I just got in
my e-mail, I'm not really sure what JPEG has to do with MNG. JPEG is a lossy
static image format, and MNG is an animation format for PNG, which is loss-less.
The two are about as unrelated in usage as possible for raster image formats
capiable of 24-bit colour. True JPEG can be hacked to do animation in Mozilla,
but I haven't really seen it used outside of streaming webcam software, which
uses a Java App for IE, in years, because IE, and many other JPEG renderers do
not support animated JPEGs.
<offtopic>I'm sorry for this spam upfront, but if I don't say it on here,
somebody will. Notice this bug includes JNG which is the JPEG Network Graphics
format, which is basically JPEG-in-MNG. So before adding more spam to
everybody's mailbox complaining about complaining, get the simple facts
straight. Though I do agree that that post did in fact have nothing to do with
this bug (if JPEGs are in trouble, then so is JNG, another issue
Thanks for responding, Gerv; glad to know actual progress is being made. NOBODY
Setting blocking1.4- as MNG suppport has not been removed from the 1.4 branch
and thus will be in 1.4 final.
The MNG decoder is 300k? Oh lord please tell me it isn't 300k! I mean I only
have a 70gig drive here people, you all act like this is the 21st century or
something, sheesh. And talk about that memory footprint, I need to conserve my
512megs of RAM to make sure AIM runs smoothly and none of that 300k bloat taking
up all my RAM. *rolls eyes*
Since bugzilla isn't letting me vote without comment, I'm just stating that I'm voting to change
resolution to FIXED to support the MNG/PNG format. Good luck to all involved in getting it
reinstated into the Moz trunk.
See bug 209439 - "Need ability to find 3rd-party extensions through .xpi".
Perhaps if this were available as a toolkit-level addon, it wouldn't need to be
distributed with Mozilla and could be downloaded into the GRE on demand. Of
course, this means nothing for the XPFE version of Mozilla as long as we carry it.
Tux: The size is not an issue for hard drive space, but for download time.
>Perhaps if this were available as a toolkit-level addon,
hm? What do you mean with toolkit-level addon?
> it wouldn't need to be
>distributed with Mozilla and could be downloaded into the GRE on demand.
currently, you can't install extensions into the GRE, and it looks like that's
as intented, as written in another bug.
> Of
>course, this means nothing for the XPFE version of Mozilla as long as we carry it.
the xpfe version of mozilla does not currently include the mng decoder
however, my xpi should work for all versions of gecko.
> currently, you can't install extensions into the GRE, and it looks like that's
> as intented, as written in another bug.
biesi: see bug 209439 (which really needs a better description)... I am working
on a mechanism that will allow "GRE extensions"... there is a whole dependency
tree to accomplish before this become reality, but it will happen.
> Of
>course, this means nothing for the XPFE version of Mozilla as long as we carry
The XPFE mozilla uses the GRE just like Phoenix does...
Nice. Perfect. Just when I started to use MNG. Thanks a lot guys.
Is there a way to get that xpi working in Mozilla Firebird?
It seems likely that when MNG is restored to the trunk, it will be
in a degraded form that doesn't handle 16-bit samples or Delta-PNG datastreams.
If so, is there a way to use an XPI to regain full MNG capability? Note
that it would be possible to regain full MNG capability by building with
the system libmng instead of the embedded one, but I think only a small
minority of users will want to do that or even be capable of it.
Why only degraded lib?
How much size does it save?
It's a tradeoff of size versus removal of features. The specific amount
saved is platform-dependent. For specifics, after Gerv gets back to us,
see bug #204520. But rest assured that Gerard and I are making pretty
good progress.
The XPI should work just fine in Firebird; though I haven't tested it. does it
not work?
It is claimed in mozillazine "Fb" forum, near the end of the thread on
MNG/JNG removal, that it does not work with Firebird.
In my personal opinion, it is a good idea to drop the 16-bit support since only
8 bits are rendered anyway, but it is not a good idea to drop Delta-PNG.
Notwithstanding the portability of MNG files, Delta-PNG is one of the key
features of MNG, that can make a big difference in compression, compared to GIF.
I also wish to make a suggestion: since efforts are concentrating towards
reducing the libmng footprint, isn't it possible to redirect some of these
efforts towards replacing the entire libpng with libmng, for PNG rendering? I
understood that libpng is older and more reliable -- which means that more
efforts should be concentrated around more libmng testing. What else would be
I am not asking people to do extra things (which may look bad, considering that
I am not doing anything myself); I am only suggesting to spend the efforts in a
different direction.
I'll answer comment #148 in bug #204520. Please continue the thread over there.
as for using libmng for png images, see bug 48893
------- Additional Comment #131 From Gervase Markham 2003-06-13 09:22 -------
I am working with the imglib maintainers on defining a set of criteria that
they want to be met in order to get MNG back in. As soon as they are agreed,
I'll let everyone know what they are.
It has been two-and-a-half weeks and I've heard nothing on the maintainers'
(most of whom have e-mails ending in @netscape.com) demands for reinstating the
MNG format. However we have many contributors that could become MNG maintainers
and very good progress has already been made in reducing the file size. I
believe there is an effort underfoot to remove MNG without valid reason.
I have, as yet, had no reply from one of the imglib maintainers who needs to
sign off on the criteria under discussion.
well, what about this guy:
kinda cute, imo. what do you think about the software. He mentioned scanners, i
am overly fond of scanners; so maybe i am too biased.
Which maintainer isn't replying? I find it ironic that part of the reason MNG
was removed by the imglib staff is because of the lack of an active maintainer,
when... well, you know.
ImageLib maintainers, according to
Owner: email@example.com; QA contact: firstname.lastname@example.com
ImageLib has maintainers. The MNG part didn't.
I've checked a "slimmer libmng" in to libmng's CVS. For details see
bug #204520 comment #56. Hopefully this will provide sufficient information
to the powers-that-be to help them decide how much reduction is required.
Damian, skewer: the maintainer in question is Stuart Parmenter (pavlov), not one
of those you name.
I just looked over the recent developments here, and here is a summary. Please
correct me if I'm wrong.
* This bug has over 500 votes. It is by /far/ the most voted-on bug in Bugzilla,
* Glenn has been waiting on comment 21 in bug 204520 for a month and a half with
no response outside of a outrageous request from IRC. That is to say, nobody has
formally set a target size for libmng despite requests.
* The original complainer and the person who checked in this bug to the trunk
(email@example.com), who I suppose is the proper authority regarding comment 21, has
not commented in any of these bugs since early June AFAICT.
I would therefore believe that the original complaint is dead, and the want for
MNG support is very high, so there is no reason why libmng-1.0.6 should not be
checked into the trunk immediately when it is released.
Looking forward to the day when bug 195280 is marked WONTFIX.
Gerv: I wonder if pavlov will (wants to) stay a module owner in the
now-different situation (employer)...
Additionally, I believe we should have some better organization of module owner
issues - but I'll take that to npm.seamonkey
> Gerv: I wonder if pavlov will (wants to) stay a module owner in the
> now-different situation (employer)...
That's something you'll have to ask him. :-)
Don't think I'm going anywhere. Remember, I was working on Mozilla well before
I started at Netscape ;)
And would you have the time and be so kind to answer some of the questions that
have been asked, regarding the validity of reasons behind removing MNG support,
and what would be required to re-instate it?
Eg. are 518 registered bugzilla voters an indication of more wide-spread use
than assumed? What reasonable size-reduction would be required to consider it a
useful addition to Mozilla rather than a bloat?
I'm still here, too. I was working on Mosaic-2.4.1 (see changelog) before
Netscape had been heard of by the general populace, and before PNG/MNG were
Current situation with MNG reduction, on a particular platform
(FreeBSD/gcc-3.2.1) is about 179k:
62k removal of redundant and unused functions in libmng,
50k removal of unused functions in libpng,
17k removal of 16-bit sample support in libmng, and about
50k merging libmng and libimg2 to avoid storing two copies of the jpeg
library, as demonstrated by tor.
IMHO that is enough. How about putting MNG back on the trunk now?
Additional 7k could be obtained by removing Delta-PNG support but I don't
recommend that, and about 13k by removing JNG support but I don't recomend that
And as usual, we get no response...
is it just me and Glenn, or are you this plain rude to everyone with a fleeting
interest in PNG/MNG/JNG? It's not like we're asking you to solve the mysteries
of the universe or something...
"Stuart Parmenter" firstname.lastname@example.com was the strongest supporter of removing MNG
without justification. I don't think his opinion is valid in this issue.
FYI: If pavlov could provide some definite requirements for his supporting MNG's
return, and the full imagelib crew agrees with those requirements, I would be
more inclined to respect his opinion on this matter. But he personally backed
and approved the removal of MNG without a single word about why, and now that
he's the only person who needs to say anything, he's filibustering the whole
operation and still has provided NO REASON why he would want MNG removed. This
is an insult to thousands of Mozilla users and a direct insult to 520 Bugzilla
users who are voting for this bug. Things need to change here.
What's this, Bugzilla invasion of the trolls?
Gerard, ever thought that maybe Stuart doesn't spend his time 24/7 in front of
the computer, trying to solve what *you* think is an important issue?
Skewer: Find a new place to troll. Thanks!
email@example.com please take your bugspam elsewhere, thanks
Mark: Umm... since you weren't paying attention, Stuart has neglected to give a
response for over a month now. It doesn't require being on a computer 24/7 to
say something in that time. Also, he responded to the inquiry as to whether he
would continue to be the module owner just the other day, without saying one
thing about requirements for reimplentation of MNG. So the impatience is quite
skewer: pavlov is the imglib module owner (last time I looked), so his opinion
is very much valid.
Mark: gerard (with Greg) is one of the people who has been working hard on MNG
over the past few weeks, so his frustration is perfectly understandable.
Can we calm down a bit here, please?
For those who have misinterpreted my statement "IMHO that is enough", that means
in my humble opinion it is enough to warrant checking MNG back into the trunk,
not that I intend to quit working on it. I am committed to continuing to reduce
the size of libimg/libmng unless I find out for sure that it is a fruitless
skewer: pavlov is the imglib module owner (last time I looked), so his opinion
is very much valid.
Gerv: And Bush is the U.S. President. That doesn't mean he knows what he's doing
or belongs there. What argument is there not to remove GIF because of the Unisys
patent issues or because there is a viable alternative available (PNG, MNG)? In
fact, why not remove XML, how often is it you run into a webpage that uses XML?
Skewer: Let's see how did you put it . . oh yea "please take your political-
spam somewhere else please, thanks."
skewer: Your political commentary was completely off-base.
However in light of the work done and improvements made of late, it does seem
like someone very much doesn't want to concede that they might have made a
mistake when deciding to remove libmng indefinitely.
I lost my patience for a moment and I apologize. Even if it's pretty obvious
why. I certainly didn't want to star a flamewar, so let's all stay civilized and
work towards a solution. Ranting doesn't work! And Mark, I *don't* think it's
important, in fact, I couldn't give a hoots **** at the moment whether MNG comes
back or not. There are a lot more interesting things happening in my life right
now. But don't read that to mean that I'm not interested. libmng has been my pet
project for 4 years and will remain so for some time to come, and I'll work with
anyone that *works* with me!!!
Just to recap for those that do not want to go through the entire backlog.
Here's the status on the original reasoning behind the removal:
> * mng decoder module is roughly the same size as all the other
> image decoders and libpr0n logic combined.
> Linux sizes:
> 261796 libimglib2.so
> 241492 libimgmng.so
> MS-Windows sizes:
> 155024 imglib2.dll
> 170336 imgmng.dll
From bug 204520 comment 60:
MOZILLA_1_4_BRANCH libmng: 189K
tip libmng-devel/mozlibmngconf.h: 112K
That's a 77K (40%) size-reduction in the bare decoder. Looks to me like Glenn
has already done an incredible job towards reducing the size. Also 50K were
saved from the libpng implementation, another 50K could be saved by removing the
duplicate JPEG code. Also the optimized MNG throbbers for Firebird are a fair
bit smaller than their GIF-makeovers (bug 195280 comment 100).
And we still have more ideas on how to decrease the size of libmng further. But
neither of us is going to spend a lot of time working in the dark. If pav can be
se kind to answer our question on what size-reduction is required, at least
we'll know what we're working against. And I mean a real number, not some off
the top of the head figure akin to impossibility. A valiant module-owner
wouldn't hesitate to answer such simple mathematics. I don't mind if there are
more personal reasons behind keeping MNG out of the tree, but at least come out
and say so. I've been down such paths myself a couple of times, but believe me,
the ostrich-way really doesn't pay off.
> * mozilla integration is rather rough, partly due to a necko bug
> (possibly fixed by darin's recent async changes) and partly
> due to the lack of active, interested maintainers.
There is still no active maintainer. The most obvious person at this point
(Glenn) has been turned down. The fact remains that the new maintainer wouldn't
actually need much knowledge of the MNG library itself, since he/she will have
Glenn and me for the full 200% behind him/her to solve any issues relating to
the MNG decoder. Maintenance would therefor be more of an administrative task
then real grunt-work. If we would have had a bit of co-operation from the
module-owner, I would have spent a lot more effort in squashing the currently
outstanding bugs against MNG.
> * animated gifs and flash (and possibly svg in the future) cover
> much of the feature set of mng. jng is a bit more interesting,
> but not in ways that most people will care about.
> * the formats are not w3c recommended.
As many people have stated this isn't much of an argument. Have a look at bug
195280 comment 100 and see if MNG isn't a tat superior to animated-GIF. And
AFAIK themes can't use flash. Other arguments against this point are that MNG is
an open standard, not proprietary or flee-ridden with patents, it's a lot more
sophisticated than simple 8-bit paletted image-streams, can achieve better
compression than GIF, and can be run transparently against the background. You
can only achieve that with Flash if you design the whole page in Flash, which
makes it rather impossible to maintain.
> * the formats are little used in the wild.
500+ registered bugzilla voters think not. The Firebird crew and many other
theme-authors didn't think so. And what kind of thorough investigation has been
done to support this point? MNG usage is growing thanks to Mozilla! Let's keep
it that way. You've got a great product. And as many people stated before,
Mozilla is an open-source platform that gives new emerging technologies a
foothold to gain the status they deserve. *Mozilla* makes the difference, not IE!!!
I don't think anyone caught my point, they were too busy accusing me of trolling
or spamming, so I'll put it simply:
The reason this bug, bug 18574, is not currently FIXED, is because
<firstname.lastname@example.com> (anyone wonder why I prefer to refer to THAT e-mail?) and
only pavlov is not providing the criteria which would allow MNG to be checked
back in. Since he is the imglib owner he has the authority to stop MNG from
being included in Mozilla for absolutely no reason at all. That's exactly what
is happening--no reason at all is being given for its current exclusion from
Mozilla. The size has been reduced more than it needed to be (the additional
size of a typical Flash or GIF animation compared to an optimized MNG is more
than the difference in the code made by removing the libmng library). Lack of
widespread usage might be a valid reason to remove something like this from IE,
but this is Mozilla, and there are plenty of little-used standards that are
being included because they're good, not because they're popular; for example,
CSS3. W3C recommendation isn't a valid reason, because bug 3744 is based on the
"GNKSA" guidelines some kid made up. Just about any reason for stopping MNG can
also by stymied by the fact that we even include MARQUEE support in Mozilla.
Overall this MNG removal thing is something that never should have happened. Am
I right?
This is a question based on my understanding of the processes put in place by
the mozilla organization, and as such, may be based entirely on a misunderstanding.
But as I understood it, all module owners are answerable to drivers, and if a
particular module owner is not doing an adequate job, the drivers can
investigate the issue and come up with a solution including anything from "allow
this bug to be checked in, regardless of what the owner says" up to and
including revoking the person's ownership position.
To be clear: I am NOT suggesting that pavlov should be removed from imglib
ownership. However, I *do* think that he has failed to carry out his duty as
module ownership in this case: that duty would certainly include providing a
timely response to an entirely reasonable question like this.
As such, doesn't the normal mozilla process say that the appropriate action now
would be to contact drivers?
Gerv, as the person who's taken the lead on bringing this to a diplomatic
solution, what's your take on the current situation? Do you feel that the delay
in getting a response is still reasonable? If so, how much longer until it
becomes unreasonable, and am I right about the correct action to take in that
case? (I'm not trying to propose an ultimatum or anything like that, but *some*
kind of limit to how long this bug is going to sit in limbo would be appreciated
by everyone involved, I think)
> Gerv, as the person who's taken the lead on bringing this to a diplomatic
> solution, what's your take on the current situation?
Your understanding of mozilla.org process is correct. It is up to individuals to
decide when and if to escalate a particular issue to drivers, and if they are
the most appropriate person to escalate that issue.
Those who are considering this course of action may do well to contact Gerard or
Greg, as they are the people currently hacking on MNG.
It's Glenn and me, but mostly Glenn doing the hacking. Greg's our punchball in
the back. We'll be getting in touch with drivers some time this week. Just
deciding who's doing the writing...
Sorry, guys - all your names begin with G, and I get confused :-)
> there are plenty of little-used standards that are being included because
> they're good, not because they're popular; for example, CSS3
I know, this bug gets spammed out to over half a thousand people now, but I just
wanted to link to this little project:
I got it off of this MNG site:
What I find interesting about something like this is it is a quick easy
browser-based alternative to VNC (yes, there are VNC Java Applets, but
nonetheless). I recommended it to my boss, who has been looking for something
like this. If he starts using it, I imagine he'll be either looking to install
Netscape/Mozilla on remote computers, or the IE MNG plugin.
Even more then a website, a browser based application they depend on is
something people might go out of their way to install Mozilla for. Especially
if they were used to using it for this reason on their home/work computers. Of
course, if MNG becomes a plugin, then people would probably just use the IE
plugin. No difference, after all. Similar reasoning applies to intranets.
Indifferently supported web standards often get a toe-hold there as well.
Just one more reason along with MNG in the classroom (Mozilla as default install
on a college network is another source of evangelism), and MNG throbbers, as
well as the amazing difference between a 20k translucent JNG and the 200k PNG
that would be needed for same effect.
Ok. My one and only bug post on the subject :)
I wanted to watch my favorite pr0n clip with current Mozilla, but I failed to
see it. I'm confused now, as as http://libpr0n.com/faq.html says it should
support it's MNG format.
Either your webpage is wrong, or Mozilla doesn't qualify for a good pr0n
browser, as animated goatpr0n comes best in MNG format.
Pavlov had nothing to do with that web site. See bug#66984 comment#6.
I tried to install the mng extension from the firebird extension website and it
didn't work (I verified this by trying the bugzilla testcase on the top of this
site http://bugzilla.mozilla.org/attachment.cgi?id=124879&action=view ).
The installation failed with 0.6.1 official (=final) build and the latest
nightlies {current one is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.5b) Gecko/20030731 Mozilla Firebird/0.6.1}.
having restarted the first time after the extension installation, firebird gave
me an error : "the application couldn't be started because mozz.dll couldn't be
firebird started anyway and after the next restart the error msg was gone, but
mng animations didn't display.
so there isn't native mng support anymore nor a working extension.
see: http://forums.mozillazine.org/viewtopic.php?p=133923#133923
I hate to reply with this many cc's, but leaving the previous comment without a
response helps nothing.
bernd, the extension in question has issues on Firebird Windows, but works on
Seamonkey Windows and both products under Linux (apparently), at least based on
that and other threads. mozz.dll does not exist under Firebird, so the
extension isn't really compatible. Maybe the extension author should update it,
who knows whether he's interested still. If MNG is that important in the short
term, use Mozilla Navigator with the extension or use Linux.
I opened bug #214737 for discussion of the MNG XPI problem.
Updating dependancy tree, removing duplicates and putting bugs they are
duplicated to.
I'd wanted to nominate this bug as a blocker for version 1.5, just because I
can't think of a normal (non-alpha, non-beta) version of Mozilla without MNG
support. But because this is not possible (yet) I'd nominate this as an 1.5beta
One of the main reasons of the removal of the support was the size of the
decoder, in the other comments of this bug is alreday stated that there can be
more size/footprint winnings when converting the (animated) GIF's in the chrome
to MNG. So if we are concerned about the reduction of the size we should do that
BTW: There is no need in blocking 1.4.x, because the branch for 1.4 was cut
before MNG support was removed from Mozilla.
Maybe the person who removed the "blocking1.5b" flag could leave a comment to
explain why they did so?
Only drivers should set blocking+ flags. If you wish to nominate a bug for
blocking status, set the blocking? flag.
I'll take the leap here and set that.
Re: comment #186 and comment #187; the MNG extension is working now with
Firebird. See http://quicktools.mozdev.org/mngsupport/ which is based on
the attachment #125114 [details], above, plus mozz.dll and some Windows registration settings.
Asa, could you please explain why you removed blocking1.5b for this bug when it
is the most voted-on bug in all Bugzilla and can be easily fixed?
referring to #193:
sorry glenn,
this new xpi didn't fix my problem either.
steps I did:
1) installed the "complete MNG Support for FireBird (mng-windows-fb.xpi)
extension package"
2) restarted firebird
3) tried testcases -> all testcases failed
4) checked "extensions" in "options" -> no extension was installed
5) executed mng.reg manually as instructed on the site you mentioned
6) made sure mozz.dll was in the firebird folder
7) installed "MNG Decoder for Windows (92 KB Download)" from
http://stud4.tuwien.ac.at/~e0225227/ (the "original Extension page")
8) tried testcases -> all testcases failed
Conclusion: still no mng firebird support on windows.
tried with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030808 Mozilla
Please continue discussion of XPI in MozillaZine->Firebird forum:
Since I know Asa doesn't get bugmail for most/all changes: #194, look at the
link in comment 114 as to why votes don't always equal action.
And just to clarify for those who tried adding the blocking flag: The
requirements have been laid out in bug 204520, and those are what is needed for
MNG to be added and this bug fixed. Until those goals are met or modified,
drivers have made it clear that this will not be added back to the trunk. As a
result, requests to block any release will be denied since drivers already
decided it could be removed until the goals are met.
Re: #194:
"Asa, could you please explain why you removed blocking1.5b for this bug when it
is the most voted-on bug in all Bugzilla and can be easily fixed?"
Several reason:
This bug is not _ready_ to be fixed as as set of specs is still beign drawn up
by module owners and drivers. This bug in now way is a sudden regression, or
otherwise urgent in the scope of the 1.5b release and does not even rise to the
level of rendering sites incorrectly. Also, did you not see this?
Status Whiteboard: DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS
It's pretty clear this bug is not close to being resolved yet.
referring to #195:
a complete dump of my former profile let me install the xpi.
thanks for all those messing with the mng and the mng-xpi creation.
I have received word from drivers. They invite MNG support to be put back in
the image library as a configurable option that is turned off in default
mozilla.org-produced builds (Seamonkey, Firebird, Thunderbird).
They are interested in having only MNG-VLC supported as a configurable
that does not entail all the footprint of full MNG, and would support
such a subset being turned on in mozilla.org-produced builds and made
part of the "typical" GRE configuration that Mozilla.org brands and promotes
(aside: we see the need for "minimal", "typical", and "all" GREs, with
"typical" being widely deployed on desktop machines).
(drivers invite MNG support to be put back in
the image library as a configurable option that is turned off in default)
And we all know that that will be useless. While telling users to use Mozilla
for certain content might be feasable, telling them to choose special
configuration options clearly is not. Also all current users of Mozilla will
have to mess around and it won't work out of the box. People will forget it
when upgrading.
This quote from Glenn in bug #208607 shows IMO how ridicoulous and frustrating
the whole situation already is:
"My patch for reducing
libpng another 5-10k in addition to 50k already saved by me to make room
for MNG support has been lingering in bug #208607 for a couple weeks
without any response. I have also reduced my own copy of the jpeg library
significantly, too, but why bother?"
IMO this all is not about memory footprint, but only about pride, power and
control. Which is all very sad.
I don't wish to lay blame or attack anyone - I'd just like a clarification of
the state of affairs without loads of Moz. Dev. TLAs:
Is it now true that the main reason for not [re]including MNG as default is it's
footprint? I seem to recall reading above that more footprint is /saved/ by
converting the default chrome's animated GIFs to MNGs that is taklen up by it's
inclusion in the library - an overall footprint /decrease/ by including it. Am
I right?
Also, I'm not quite sure I understand the mechanism by which MNG will/will not
be present in a moz under the seeming current plan. Will it need a special
build, or will it 'be there' in the default build but not downloaded by default
unless some installer tickbox is set? If it's not 'there', what happens if a
MNG is found whilst browsing - will there be an automated 'plugin dialogue'
offering to make it work, or will it just not display?
to Neil Bird -> let me explain the mechanism: not being built by default, will
not be supported, you will have to find somewhere a Mozilla build with support
So, essentially, the current status quo is preserved. Is anyone surprised?
Drivers supports the reinclusion of MNG-VLC in mozilla.org builds, via it being
"on" for "typical" GRE Builds.
What this means is, the full MNG spec will not be compiled by default (but will
be available as an option), but they MNG-VLC *will* be compiled by default,
*and* available for install in all but the "Minimal" GRE configuration.
Before anyone accuses drivers of maintaining the status quo, read above. In
essence drivers have approved the reinsertion of a signifigant portion of MNG
into the tree.
Is that a tentative "yippee" then? What's "VLC"?
Could you please explain the difference between "full" MNG and MNG-VLC? Thank you.
"Limiting the feature set in a widely-deployed WWW browser to anything less than
MNG with 8-bit JNG support would be highly inappropriate." - (MNG-VLC Format
Version 1.0) PNG Development Group
[http://www.libpng.org/pub/mng/spec/mng-vlc-1.0-20010209-pdg.pdf] Page 18.
If that statement means "full MNG", it might be worth reconsidering Mozilla's
It is status quo from the perspective of webmasters and of those who download
official binaries.
From developers perspective, MNG support (slightly crippled) will be back on
trunk and can be enabled with a simple "--with-mng" or something.
Everyone will still have the option of installing a fully MNG-supporting XPI.
From the MNG evangelist's perspective it's not too good because it stifles
potential MNG usage on web pages (although of course IE is already doing that
for us) and in skins/chrome where we were actually making some inroads.
"VLC" is a "very low complexity" version of MNG that is little more than
a stream of PNG files in a MHDR/MEND wrapper. It was developed in response
to people who wanted a very simple MNG for handling multiple-page FAX files
and the line, and wasn't intended to be a browser format.
For more information about MNG-VLC, see:
Short summary from that page:
MNG-VLC is "A very-low-complexity subset of MNG that does not use stored
objects, variable framing rates, location of images at positions other than
(0,0), or other complex features. The "simplicity profile" in the MHDR chunk
must meet certain requirements [...]"
It should be noted that MNG-VLC *cannot* replace most animated GIFs, due to the
limitations of frame rate and offsets in MNG-VLC. The only formats that could
replace animated GIFs are MNG-VLC or full MNG.
In other words, not very useful as an animated GIF replacement and prohibitive
for development and uptake of MNG-based websites. The extension option really
isn't viable for the common user, unless it's maintained by mozilla.org and it
is automatically downloaded and installed the first time a user comes across a
site with MNG/JNG on it. I don't know of any infrastructure currently available
to do that.
All other debate aside, it seems to me that this new route is going to cause
MORE maintenance issues rather than less due to all the extra ifdefs and
compile-time options that will need to be included. This would likely increase
the source code size, even if it slightly lessens the binary size. I hardly see
how this is logical when looking at the original reasons for removing MNG.
Sorry for the spam... In my previous comment, I wanted to write "MNG-LC" instead
of "MNG-VLC" for replacing animated GIFs. For more information, see:
Still, I am glad that the drivers are allowing at least one part of MNG to come
back into Mozilla, even if it is crippled and may cause more problems than it
To sum it all up again, what actually *does* speak against full MNG/JNG support
in Mozilla? The only reasons given
(http://bugzilla.mozilla.org/show_bug.cgi?id=195280) seem to be that
1. The MNG decoder is too big
2. Mozilla integration is "rather rough", whatever that means
3. GIF, Flash and (possibly in the future) SVG cover the same featureset
4. The formats aren't used (much)
5. The formats are not w3c recommended
Reason 2 seems like a non-argument to me ("rather rough" integration means that
it should be worked on, not ripped out).
Reason 3 is invalid since GIF is patent-covered (and the patent is still in
effect in many countries, like, for example, Canada).
Reason 4 is also a non-argument; we might just as well remove XHTML or MathML
support from Mozilla for the same reason.
Reason 5 is another non-argument; the w3c does not officially recommend GIF,
either, as far as I know.
That leaves us with reason 1: codesize. I don't think that this is a a real
issue myself, but I can understand that others are worried about code bloat in
general, download times (especially for analog modem and isdn users) etc. The
solution I'd propose would be to either make available different builds of
Mozilla with different featuresets, or, better, to make support for MNG and
other formats configurable at install time, so people using the Net Installer
wouldn't have to download what they need in the first place. MNG support should
also be an option that is selected by default; the relatively small increase in
code size (given as 240k on Linux, 170k on Windows on bug 195280) does not
justify turning it off by default given the relative importance of MNG as a free
and unencumbered alternative to GIF, Flash etc.
Sorry for spamming here, just one small comment:
I consider MNG coming back into the trunk, even if only enabled via a compile
option, being a major step into the right direction.
This way, work can be done to prove it e.g. as stable as libpng and being good
enough to eventually take over rendering of PNGs. Such a movement could possible
lead it back into default builds as well.
Having MNG-VLC in default build would be a first step as well, as we probably
can move up to MNG-LC or more later on.
And Mozilla-based products, which may need full MNG, can include it by default,
as well as any custom Mozilla distribution (perhaps the SVG-enabled builds as well).
As I said, it's a first step, and it's a good sign to see at least that happen.
> 1. The MNG decoder is too big
A lot of things are too big and less important than MNG.
> 2. Mozilla integration is "rather rough", whatever that means
This is obviously not the reason, otherwise they wouldn't agree to introducing
3. GIF, Flash and (possibly in the future) SVG cover the same featureset
GIF is patent encumbered and technologically limited,
Flash may be the status-quo but doesn't work well outside of Windows, MacOS, and
Linux-x86. Even the Linux-x86 port isn't that great.
SVG - great thing, love to see it happen, but can SVG and MNG not 'get along'?
> 4. The formats aren't used (much)
Because none of the browsers support it! All of the webbrowsers are looking
around saying, "I'll support MNG when everyone on the web is using it.", but
nobody will use it until the browsers support it. The browsers won't support it
until everyone is using it or all the other browsers support it. It is possible
that once Mozilla implements it, the other browsers may follow.
> 5. The formats are not w3c recommended
I agree that SVG is great and should also be implemented, but a lot of things
aren't w3c recommended.
Now, the arguments that GIF isn't w3c recommended but is supported shouldn't be
used as an argument because GIF has legacy behind it. JPG also has legacy
behind it. They are the status-quo, you can't have a leading browser without
GIF or JPG support.
Hopefully one day SVG and MNG will be part of the status-quo and it will be
ludicrous to have a browser that doesn't support them without being deemed a
'text-only' browser.
SVG and MNG will NEVER become the status-quo if they are never implemented into
browser simply because someone is not willing to take a risk on new technology.
I understand, it is a risk; but it can be undone. I also understand that not
every proposed technology can or should be implemented. Somehow PNG has managed
to rise, look at how popular it has become, it is used nearly everywhere now. 3
years ago I sent someone a PNG image and they didn't know what to do with it,
now they are as familiar with PNG as they are with JPG. I feel that MNG will be
the replacement for the animated GIF as we know it today and will be the safe
and easily used medium for those not needing something as dynamic as SVG or
something as static as PNG.
I applaud the agreement that MNG-VLC should be included, but I feel that it is
too limiting to offer any advantage to GIF, especially with the outweighing
disadvantage of backwards compatability faced by web designers.
In conclusion, MNG should be included with at least as many features as that of
GIF as to make the format a viable option for web designers, to help spread it's
usage, and finally to convience other browsers that yes, it can and should be done.
If MNG is not fully implemented in Mozilla, then every effort should, no.. MUST,
be made to including and optimizing SVG.
>Is it now true that the main reason for not [re]including MNG as default is
>footprint? I seem to recall reading above that more footprint is /saved/ by
>converting the default chrome's animated GIFs to MNGs that is taklen up by it's
>inclusion in the library - an overall footprint /decrease/ by including it. Am
>I right?
Could one of you 'in-charge' care to answer this for me? If that statement is
true, why is the default chrome still using GIF's?
Would anyone be interested in maintaining an alternative Mozilla which will NOT
be supported by mozilla.org, that has full, real MNG built? Mozilla.org has
indicated that it is not interested in restoring MNG (essentially this bug is
WONTFIX). Right out of the box such a project has a guaranteed 565 users, and
probably quite a few more once word gets out that mozilla.org has closed its
doors on the MNG format. (Once the "fixed" Mozilla starts to take over
Mozilla.org's market share they may change their minds about this.)
Also, the maintainers of the LibMNG homepage need to be notified that Mozilla
does not support MNG or JNG anymore per administrative order. The contact
address I found was newt at pobox.com.
Skewer --> If it does turn out that the drivers are all that stupid, I will be
very glad to withdraw support for the monolithic Mozilla Foundation and
petition Debian to change its default browser to your branch.
(Written using Konqueror)
right, insulting and threatening people is always a good idea if you want people
to do something you want
Well, Chris, there was an "if" -- I don't think Ashi or Skewer would directly
just say or think something along the lines that drivers are full of it; I don't
think these comments were meant to be outright offensive. It's simply that ever
since this stupid issue started, those who decided to remove MNG never even
bothered to tell the real reasons. No matter how nice or how unnice the people
on this "forum" were.
If anything I find it a bad thing not to communicate with the users. And no,
those initial "reasons" were not acceptable, most of them having been disproven
by either simple logic, or by the results of the work of the G group (Glenn,
Gerv, and whoever else starting with a G, sorry about my name memory, Greg
p'haps?) and Tor, re: size.
It would be high time that the one who actually started the whole thing
(firstname.lastname@example.com IIRC) came up with something decent of a reason, because we
won't eat this (as it can also be seen). Not to mention his attitude, that is
nothing but selfish, and I'm sorry to see something like that in this community.
I'm glad that a minimal version is considered to be put back in the trunk, but I
still don't see any decent reason about why just a rather neutered version of
MNG can be directly supported. What /is/ this obsession with closed and/or
patented standards?
Thanks for reading,
Ashi, Eric, Skewer, Henrik:
You're all suggesting that either drivers, tor or pavlov - or all of them - are
stupid, braindead or dumb. This is simply not the case. pavlov and tor are
genious programmers, and drivers are clever people who are overseeing the project.
The initial primary reason for kicking out MNG was that there was no maintainer
of the code, it seems. This problem looks solved currently, and there's good
reason to re-include the code in the tree and if it stays well-maintained,
re-include it into the default builds gadually over time.
The second problem, code-size was heavily work-on by another genious, who fits
well as the maintainer of the code, and I think the whole issue would work out
after some time.
email@example.com are _not at all_ stupid, as they tried to calm down the
discussion and proposed a way that should be acceptable for all sides of the
discussion, though it is a compromise. This is what diplomatic and political
processes are all about in real life, and in such a project as well. It's not
the ideal solution for all parties, but it's a base to work upon. Please don't
poison that try to calm down the conflict.
I'm just a simple user, and yes, I'm interested in having MNG as well, as I see
quite a few pros, but it's just the wrong way to tell people they're stupid just
because they might have some personal obligation.
(sorry to spam a bunch of you people that already know all of that - this
comment shouldn't be needed, as lots of others that keep the flames burning.
Well, this is OSS though, and flames seem to be a part of OSS spirit after all...)
If it didn't show, I'd like to emphasise I don't think they're idiots. I'd like
to emphasise something else too, though: pavlov never came back to tell us any
decent excuses, as far as I know, having been reading this bug for a couple
months now. I have definitely not questioned their programming abilities, nor
have Skewer and Ashi questioned that; I personally will accept that both Tor and
Pavlov are good programmers.
I am questioning the general attitude of Pavlov, though, and the elongated
silence of drivers --- that though with the re-inclusion of MNG-VLC has broken.
re: Reason For Kicking MNG. I recall pavlov and tor coming to tell they have no
mng maintainer. After some posts, a couple of the G's mentioned they could try
to find time soon for it, and would gladly take over maintenance of MNG. Some
posts later pavlov announces something along the lines "ok, I have taken out MNG
from the trunk." and poof he's gone, seemingly(!) without having considered the
G's. After that, I recall Gerv and Glenn and Tor trying and succeeding to
reduce the size of the libs which was perhaps pavlov's most valid point among
the invalid ones like "people have no interest in using it" or something that silly.
I am definitely happy that gradual re-inclusion is considered, but what the
people here keep whining about is com-mu-ni-ca-tion. We just don't get real
feedback and good reasoning. Is it too much to ask for someone to share us the
real requirements? Been asked for for a good while, I'd like to remind.
I say again, I don't think the drivers are stupid, they just took helluva much
to react at all (or so it seems from reading this bug), and even then we didn't
get to know much (or are my eyes closed?).
That's all I wanted to add,
PS: yes, things have been repeating all over and over, I'd say we all know the
pros and cons... which is why I'm so surprised on pavlov's obsession with
patented standards :P
Drivers *did* reply, if only via a private message to me (comment #200).
I am working on a cut-down version of libmng that only supports MNG-VLC,
and should have that checked in to the libmng CVS today. Since the cutting-down
is via #ifdef macros, anyone will be able make a partly- or fully-MNG-supporting
"unofficial" build of Mozilla or FireBird.
well, stupid was:
- to remove the code after somebody said, he will work on it
- creating arguments, like "nobody uses it", "code to big" or "not W3C recommened", which you
could also use to stop the whole project and write an IE clone
- to say "I don't care about votes"
- not to answer on mails for a long time
- to show not having understood the possibilities of MNG compared to GIF or Flash
- to set unrealistic readd requirements
- breaking compatibility with older Mozillas at all
- to readd a useless MNG ripoff (called MNG-VLC)
- to say "everything went it's normal way".
If it's the normal way not to care about the communities oppinion (and the community are not the
users, the community are the users, who say, what they think about something!), it would be
better to stop the whole game. So I wouldn't say pavlov is stupid, but he made many things wrong
and behaved like a dictator.
As far as I'm concerned, MNG-VLC is the same as no MNG at all. It is useless
as an animated GIF replacement and useless as a form of animated JPEGs. Adding
in only MNG-VLC would therefore make Mozilla's MNG support exactly what
drivers and pavlov claim it to be-- useless bloat!
Why would you not want to put this into Mozilla? GIF has those stupid patent
issues. This format does not. Also, and if the library is a little bigger who
cares? Are you loading ALL the libraries into memory at once. I seriously
doubt it. So, this means it can be left in and called on when it is needed.
Just because W3C doesn't list it, does that mean it should be left out? I think
not, since the whole key of their site is supposidly to encourage NEW ideas.
MNG would replace animated GIF files without a doubt with its smaller size when
compared to GIFS.
> * mng decoder module is roughly the same size as all the other
> image decoders and libpr0n logic combined.
> Linux sizes:
> 261796 libimglib2.so
> 241492 libimgmng.so
> MS-Windows sizes:
> 155024 imglib2.dll
> 170336 imgmng.dll
Come on. 166.3K in size. That's not big compated to other DLL files that I've
seen. The feature warrants the space. Anyway, if that size were an issue, why
would people download software like Shockwave when it takes up a ton more space
than even this library file itself, or even items like RealVideo? Why? Because
they want the feature available.
I feel that this format would replace GIF just as JPG replaced BMP files on web
I've posted a patch to downgrade libmng to a MNG-VLC-supporting version
only, in bug #204520. When applied to mozilla-1.4, it creates a static
libmozmng.a with "size -t" about 51k and libimgmng.so whose "size" is 77.5k.
Perhaps we could put in support for compiling Mozilla with MNG-LC as well. It
could be turned off by default, and it would give us another option for
negotiating MNG support with the Drivers.
Glenn has already added such support. See the bug listed in Whiteboard Status.
Yeah, I see it for Comments #78 and #80 in Bug 204520. There are three
config flags called MNG_BUILD_VLC, MNG_BUILD_LC, and MNG_BUILD_FULL_MNG. I like
that MNG_BUILD_LC includes a few non-MNG-LC goodies like JNG. MNG-LC + JNG
support should be optimal if the size is low enough.
Ideally, I'd like to see Mozilla support MNG_BUILD_VLC for the "minimal"
install and MNG_BUILD_LC for "typical" and MNG_BUILD_FULL_MNG for "full".
"Everyone will still have the option of installing a fully
MNG-supporting XPI."
Will Mozilla.org provide such a fully MNG-supporting XPI for the
suite and for Firebird?
"5. The formats are not w3c recommended"
I'd guess that MNG, based on W3C-recommended PNG, is a lot
closer to being W3C-recommended in spirit than GIF is.
"to make support for MNG and other formats configurable at install
time, so people using the Net Installer wouldn't have to download
what they need in the first place."
I second this once MNG-VLC integration with Mozilla becomes stable.
"more footprint is /saved/ by converting the default chrome's
animated GIFs to MNGs that is taklen up by it's inclusion in
the library"
I'd guess that drivers are not counting a compensating reduction in
Mozilla browser chrome footprint because they want to reduce the
footprint for embedding, where Mozilla browser chrome is typically
not built.
"What /is/ this obsession with closed and/or patented standards?"
I suppose most of us already know this, but a freely
redistributable computer program such as the Mozilla browser
cannot implement any patented process unless the author can
secure a worldwide, perpetual, fully-paid-up license for such
process. The only way to do this if the patent holder is
unwilling to sell such a license is to acquire a controlling
interest in the patent holder, and I don't think even AOL Time
Warner (Mozilla.org's former parent) is rich enough for that.
-- My view on the issue --
I understand the compromise that the drivers are making.
Part of it may have something to do with the difficulty
of reviewing and super-reviewing a huge chunk of new code
and the difficulty of getting enough tester coverage.
I'd support putting MNG back into the trunk with only MNG-VLC
enabled in official browser and suite builds, letting testers
shake the obvious problems out, and then filing separate bugs
to add MNG-LC and JNG to official browser and suite builds.
Get MNG-VLC in, get it tested, get it stable, then go from there.
> I understand the compromise that the drivers are making.
> Part of it may have something to do with the difficulty
> of reviewing and super-reviewing a huge chunk of new code
What new code? We are talking about putting back on the trunk code
that is in Mozilla 1.0 through 1.4 and was already subject to 3 years of
review and super-review. Only thing is now it's been pared down to
remove unused or redundant code, some rarely used features, and some
interesting features.
We are not asking for a new feature, but to undo a regression that took
place in version 1.5. Drivers agreed to undo it, partly, and to allow
builders to undo it fully via a configuration option. Drivers did not
make either of these concessions contingent upon any particular filesize
achievement (comment #200).
MNG support being partially restored in the form of MNG-VLC is better than
having no MNG support at all IMO, but I'd still like to ask one question:
What is the reason that drivers@ don't want to have / allow a full
implementation of the MNG standard in mozilla.org builds that is enabled by
I don't mean to bash drivers, but I simply don't understand what's actually to
be said against doing that. There is much to be gained by (re-)adding MNG
support, and I cannot think of anything that could be lost, so why isn't it
done, or even considered by drivers?
You're all suggesting that either drivers, tor or pavlov - or all of them - are
stupid, braindead or dumb. This is simply not the case. pavlov and tor are
genious [sic] programmers, and drivers are clever people who are overseeing
the project.
Answer this for me -- MNG was working perfectly fine before it was removed, with
very minor exceptions. No work was necessary to get MNG to work right, and I am
not aware of any bugs that were caused by its presence. In Bugzilla terms, isn't
that known as a regression?
> What is the reason that drivers@ don't want to have / allow a full
> implementation of the MNG standard in mozilla.org builds that is enabled by
> default?
Code size. For all the talk about "GIF replacement", most sites will not use MNG
until it's supported out of the box in IE (2 years minimum, if ever). Thus most
users will never see MNG even if we support it fully, so there's some amount of
code that most users will have to download but never use.
Now, we (drivers) are well aware that that alone doesn't settle the argument,
and there are reasons to include MNG (otherwise we wouldn't compromise). But
they have to be balanced against the negative. It's a tough judgement call and I
hope we can all appreciate that reasonable people can make different calls.
So essentially you say that the space taken up by MNG-code is more important
than the space saved by replacing the animated chrome gif with MNG?
Could you please explain how you reach that conclusion, because I sure am not
able to follow.
Also what about the web developers that want to write server-side scripts to
send MNG if the browser supports it (via the accept header), and GIF if not? It
would be a shame to stop them using a better image format.
Also doesn't KHTML support MNG - possibly another reason why companies like
Apple will choose to embed that rather than Gecko?
Ronald (and others talking about GIF->MNG conversion in the chrome): if I
understand correctly, drivers are concerned with _code_ size.
Chrome images don't contribute to code size, but to the overall package size
instead. They are _data_, not _code_.
Drivers, is that correct?
Rick - KHTML doesn't support MNG. Konqueror (which is based on KHTML) supports
MNG by virtue of the fact that it's a KDE app, and KDE supports MNG. Safari
doesn't have MNG support.
Apple apparently selected KHTML because the code was smaller and simpler. At the
time they decided, they could have taken Gecko's larger code (which had MNG),
but instead they selected KHTML's smaller code (which didn't). If getting
people to embed Gecko is a goal, that would be an argument for dropping MNG...
Let's just drop PNG too. I mean who really uses alpha transparency anyway? IE
doesn't support it right, so let's take it out too. Jeez. Why are they adding
all this bloat to Mozilla anyway. I want a tiny little browser that can't view
anything, but the file size will be very small!
Code size? Isn't that what an ac_add_options --disable-mng is for? Having
everything optional in Gecko is great design, but it's silly to take it out of
Mozilla for that reason.
IE support? C'mon, Jerry Baker's right, let's just rip out PNG alpha, MathML,
SVG, etc. to get the code size down. What's the goal, to make Mozilla a
cross-platform clone of IE?
I read a lot of claims about how converting chrome (the throbber) to MNG saves
more than the library size, but I don't see clear evidence.
http://bugzilla.mozilla.org/show_bug.cgi?id=8415#c85 says we save 40K in
Seamonkey by converting the throbber. The code size for MNG-VLC seems more than
that depending on how it's built (and I don't even know if MNG-VLC is enough to
play the throbber). Download size confuses things because everything's zipped
and the code compresses differently to the images. (Forgive me if I missed a
comment --- there are too many bugs and too many comments.)
Anyway, even if it's true that we can save space overall by MNG'ifying chrome,
that only justifies the minimum MNG configuration required to handle chrome
needs (VLC or LC). I was specifically responding to someone who asked "why not
just include the whole shebang".
Embedding sizes do matter, and that's an issue, but at this point, not as much
as Firebird download size (and Seamonkey to a lesser extent).
[Have the gamma problems that prevented CSS colors from matching MNG/PNG colors
been fixed? I lost track, but it was a stopper for chrome for a while.]
I read a lot of claims about how converting chrome (the throbber) to MNG saves
more than the library size, but I don't see clear evidence.
http://bugzilla.mozilla.org/show_bug.cgi?id=8415#c85 says we save 40K in
Seamonkey by converting the throbber. The code size for MNG-VLC seems more than
that depending on how it's built (and I don't even know if MNG-VLC is enough to
play the throbber). Download size confuses things because everything's zipped
and the code compresses differently to the images. (Forgive me if I missed a
comment --- there are too many bugs and too many comments.)
Anyway, even if it's true that we can save space overall by MNG'ifying chrome,
that only justifies the minimum MNG configuration required to handle chrome
needs (VLC or LC). I was specifically responding to someone who asked "why not
just include the whole shebang".
Embedding sizes do matter, and that's an issue, but at this point, not as much
as Firebird download size (and Seamonkey to a lesser extent).
Although you can turn on and off a whole lot of stuff at build time, we don't
really want people to widely ship builds with different sets of features. If
that happens then "Gecko supports XYZ" becomes meaningless and Web developers
will hate us.
[Have the gamma problems that prevented CSS colors from matching MNG/PNG colors
been fixed? I lost track, but it was a stopper for chrome for a while.]
We obviously do support things that IE doesn't. Like I said, it's a judgement
call, and often a tough one. I'm sorry that you feel that no reasonable person
can disagree with you. Between that, the sarcasm, and the abuse, you shouldn't
be surprised that drivers don't like to talk. And I think I'll shut up now.
To clarify, I completely support reenabling full MNG in Mozilla.
I just wanted to say that I think drivers were misunderstood and converting GIFs
to MNGs in the chrome does not count as justification for big code size of libmng.
> (and I don't even know if MNG-VLC is enough to play the throbber)
no, it isn't. As MNG-VLC can't diwplay _anything_ out there. It's worse than having no MNG,
because then nobody can say "hey, look how bad MNG is"!
roc: I haven't converted the animated graphics to MNG myself yet, so I don't
know the actual savings. However, MNG-VLC is not sufficient to support even the
features that animated GIFs offer. Without full MNG (or maybe MNG-LC), any
graphics filesize savings would be lost due to missing features like frame
offsets. I suggest MNG-LC as the baseline install at a minimum, because to the
end user, support for MNG is just bloat without it as MNG-VLC was never meant to
(and can't efficiently) be used for websites.
"if I
understand correctly, drivers are concerned with _code_ size.
Chrome images don't contribute to code size, but to the overall package size
instead. They are _data_, not _code_."
Well, that's exactly what I said. Code size is more important than data size
for some strange reason.
However I don't understand **WHY**.
Excuse me, but isn't putting in support for a subset of MNG that excludes the
majority of existing MNG files rather pointless? If the throbbers people already
made don't even work with MNG-VLC, isn't that an argument for greater MNG
support? Also, I think it is fair to consider the size based on source+chrome.
Even if the source+chrome is bigger for MNG, it's still significant when the
difference for the combined size is 10KB instead of 50KB.
Also, it's sort of product-centric to consider this solely on the basis of
Mozilla's file size. First, there's the obvious fact that Mozilla supports
multiple themes, which means if you have 10 themes, you're saving 400KB, not
40KB. Also, the smaller file size of MNG files would be of great benefit to
those who want their web pages to download faster. And for embedders, if they're
using a lot of animations, don't those animations take up space?
From email@example.com:
> I just wanted to say that I think drivers were misunderstood and converting
> GIFs to MNGs in the chrome does not count as justification for big code
> size of libmng.
It doesn't justify neglecting further optimizations of the MNG code in
Mozilla, but it does need to be factored into the equation with regard to
download size.
From email@example.com:
> Although you can turn on and off a whole lot of stuff at build time,
> we don't really want people to widely ship builds with different sets of
> features. If that happens then "Gecko supports XYZ" becomes meaningless
> and Web developers will hate us.
This would be an argument for full support of MNG. If you take it out, people
who were using the support provided in previous Mozilla version will hate you.
If you put in a subset of MNG that doesn't support their existing MNG files,
they'll hate you. If the total size of the Mozilla browser is not reduced (not
increased, since it's already in previous versions) by ~50KB, who'd going to
hate you? Name that group that's threatening to drop Mozilla if you don't take
out MNG support. Don't think you're being very realistic on the hatred issue...
The bottom line is that if MNG support doesn't at the very least support the
most common MNGs in use today, then any change in MNG support in Mozilla will
undermine MNG in general. Removal of full MNG support, while saving an
inconsequential amount of hard drive and memory space, really just amounts to
gambling that MNG will fail as a web file format. If it doesn't, then we will
have slowed the adoption of an important web standard and given Microsoft time
to add support for MNG themselves. If MNG does fail, then Mozilla.org will share
in the responsibility for its failure. You'll forgive me if I don't see the
overall benefit in such a gamble.
mickael: the decision make by Apple to choose Khtml was two years ago, if they
had to choose today, they could make a different choice, unless you consider
that the Gecko code hasn't improved the slightest bit in the last two years and
KHTML is sstill as lightwheighted as it used to be. Furthermore, MS was seeking
browser independance, it was probably not to become dependent on AOL/Netscape
for their new browser. I know of about 15 different browsers embedding Gecko,
apparently MNG support wasn't seen as a problem by other embedders.
I'd rather see the Gecko code improved in areas where it is known to be slow and
bloated than seeing features removed to artificially reduce code size, but
that's just my opinion. As a person with a marketing background, I can see how
this decision is attracting bad press to mozilla well outside the mozilla
community, there are even comments in forums saying that PNG was dropped with
MNG and I don't even talk about how stupid people who were using MNG images to
promote the use of Mozilla and open source feel now, specially in the school
system where computing teachers favorable to open source had banned the use of
animated gif in their classes. BTW, shall we be ridiculous to the point of
opening Tech evangelism bugs for the pages that make use of MNG images and ask
them to replace them with animated GIF images ? ;-)
Mozilla could be the "killer app" that drives the acceptance of MNG as a
graphics format on the internet. If Mozilla doesn't support MNG images, who will?
I vote for having FULL MNG support - the more things that Mozilla can
interoperate with, the better.
I support FULL MNG. I work on a source-based linux distribution and perhaps
that made me realize something: the "embedded" argument is specious and
ludicrous. You don't ship a full browser in an embedded environment, you
manually specifify your own ./configure options and you build it small. If
they don't want MNG, embedders that care can easily compile it out since the
vast majority will be compiling it themselves anyways. Now, desktop end
users, on the other hand, are totally different. They don't compile their
own, as a universal rule, and thus _need_ to at least have some way to get MNG
support when Mozilla detects MNGs. For Source Mage GNU/Linux, we'll most
likely be packaging MNG enabled by default as a dynamically-linked optional
dependency of our Mozilla and Firebird spells (to use the system MNG if
possible), so in the end (for SMGL) it's no big deal what _actually_ happens
as long as there's a compile option to enable full MNG support, but,
regardless, even if I can see it, I want as many others to see it. Why? In
my Mozilla evangelism, to graphic artist website developers, I talk about SVG
and MNG a lot as replacements for things like flash and gif -- well, I found
out a month or so ago that I couldn't say that Mozilla supported MNG.
Are there any embedded developers interested enough to want Mozilla to be
small by default without a custom compile against the weight of a few more K
and the benefit of a complete alternative to animated gif? Moreover, any
embedders that won't be compiling their own version? Morover again, would
mozilla not make their own binary specifically for the embedded market if
there was enough pressure? In sum: the "what about embedded" argument is
moronic. Period.
(One part of me doesn't care about animated graphics since I find them
immensely annoying and disable them wherever I can, but I still support MNG by
default because it means more website developer flexibility, especially for
the graphic artists that like alpha transparency and anti-aliasing on
everything. I have a hard enough time getting people to switch to Mozilla
because it doesn't support "exactly" a specific IE CSS extension to scrollbar
colors that's popular in the graphic artist community.)
Also, the data different than code argument in this example doesn't make sense
to me, too. The vast majority of users will probably have a dynamic linking
system and libmng can be made to not load into memory on boot (if it doesn't
already do this), but rather, only when it is used. That makes it the
same "load" as some chrome images that behave similarly. Also, for every MNG
image that people come across that is a MNG instead of a gif (due to the
browser sending the correct accept header mime type for MNG -- we don't need
to wait for IE to deploy MNG), you save them that much more bandwidth (why
limit the benefits to just MNGs shipped with Mozilla?). "Oh spare them the
bandwidth" is senseless, and with harddrive space at a dollar per gigabyte, a
single distracting banner ad on a website will cost more in opportunity cost
than somebody having a tiny lib that renders full MNG.
guys, MNG won't be a "killer function" for Mozilla, its nice, and it'll probably
be a good thing when it gets supported in wider areas, but given how many people
hate animated images period, how crucial is this really? I mean, "hey, lets
make better looking animated banner ads, then they wouldn't annoy the crap out
of me!" is not on many people's minds.
Also, libmng isn't installed by default on SuSE 8.2, so I don't think even all
Konqueror installs support MNG either.
As for the "embedded" argument, Firebird and Thunderbird are considered
embeddors in the mozilla.org scheme of things. Both want the smallest footprint
possible. Thunderbird disabled MNG before it was removed from the trunk and I
suspect Firebird would have followed suit if not removed from the trunk, given
the footprint savings. (The removal saved 300k off the firebird .exe,
approximately 4-5% of the total size).
Given the fact that MNG is not a "web standard" per the w3c or used in more than
1% of the rest of the market, dropping this code in the SHORT term loses nothing
substantial to the competition. Size and performance matter more right now than
support for a little-used standard to users in general, and USERS are the new
focus, and we need to compete based on what it does now, not what it will do in
the future. Ask that typical user what MNG is, and they won't know, and
probably won't care. Yes, there's other places that need to be addressed, but
that shouldn't be an excuse for including this. "There's more bloat elsewhere"
means nothing. Bloat everywhere is a target, this was just a big and easy size
win, the harder stuff will take longer, but it will happen in time too.
> Given the fact that MNG is not a "web standard" per the w3c or used
> in more than 1% of the rest of the market, dropping this code in the
> SHORT term loses nothing substantial to the competition.
The only graphics formats that have PNG, JPEG, SVG and WebCGM. MNG and JNG
are based on PNG, so we're really talking about an extension of an existing
recommendation. GIF has a placeholder on their web graphics page (probably for
when the patents run out), but I don't see any kind of W3C recommendation for
it. So when you think about it, MNG is a more legitimate standard that GIF,
since portions of the spec are already approved in the form of the PNG
As for SHORT TERM loss, MNG stands to loose a lot of legitimacy if a highly
visible application such as Mozilla suddenly drops it after having supported it
for several years. It doesn't benefit us to treat MNG support like some sort of
source code yo-yo that we move in and out of Mozilla at will. It only weakens
MNG as a graphics standard and confuses users and web developers.
> (The removal saved 300k off the firebird .exe, approximately 4-5% of
> the total size).
I'm seeing 240KB on Linux and 170KB on Windows posted previously. Are you
contradicting those numbers?
>> (The removal saved 300k off the firebird .exe, approximately 4-5% of
>> the total size).
>I'm seeing 240KB on Linux and 170KB on Windows posted previously. Are you
>contradicting those numbers?
Exact sizes depend on platform. It was about 300k on Linux prior to any of
my footprint-reduction work. The 240k was after applying my first patch.
Here are the sizes I'm currently seeing on FreeBSD5.0/gcc-3.2.1, and reported
recently in bug #204520:
size libimgmng.so size -t mozlibmng.a
Original MNG-1.4 288429 182715
MNG_BUILD_LC (includes JNG) 174797 86198
MNG_BUILD_LC (without JNG) 104422 73329
New Default (MNG_BUILD_VLC) 77526 50973
MNG-1.5beta 0 0
These are of course *uncompressed* sizes. The effect on download size
is only around 35-40 percent of these numbers. Note that throbbers,
either in GIF or MNG format, do not compress effectively if at all, so
40K in throbber savings would pretty much offset the size of MNG-LC
without JNG.
From the Webmaster perspective, PNG & MNG are much more useful than GIF.. but..
MNG unfortunately is not yet as widely adopted, and people tend to be a little
slow to see the features, of having such support available.
The only valid point that was made, was that there was not initially a
maintainer for the codebase. Which makes maintaining more difficult..
(particularly when making big changes that could break the non-maintained
code.)... Size was the other valid argument.. but.. it is reasonable that MNG
would be larger. Given it's feature set.
Having some sort of support, even if it isn't close to ideal is better than none
at all. After all, progress is marked by making things better.. Complaints of
missing MNG features will eventually appear. ;-)
I do question why Drivers support MNG-VLC and not MNG-LC (with or without JNG)
based on the recommendations of the PNG-working group.. Far as I know, in
Mozilla's history, following the recommendations of such a library developer has
not been an issue before.
As far as Firebird is concerned, they were using MNG in the theme that shipped
with it. Until it was removed from the trunk.. So I doubt they were considering
dropping it. They, like the rest of us, probably did wish it was smaller, and
better optimized... though.
As for the maintaining argument, the fact that a serious maintainer was rejected
is a bit puzzling.. Was any reasons given for why Glenn was rejected as a
maintainer? (I'm guessing it's politics.. but..) Do we have another canidate for
a mainainter for MNG? Also, what is the proceedure for becoming said maintainer?
since it hasn't been mentioned here. I'm not sure if I can be of any help, but I
am a supporter of seeing this return, and will help where I can.
As Glenn has proved, there's plenty of room to optimize the different decoders
throughout the imglib module.. which could further improve the performance (and
reduce the footprint). and if optimized along with MNG, it would cover the
existance of the new format. Truth is, new formats are going to come along..
that's a fact that isn't going to go away. Unless you're willing to deprecate
and remove old formats, (which there doesn't seem to be any) to cover for the
new ones.. The codebase size is going to increase, it's just a fact. The fact
this was branded as "rarely-used" was unfair, as it's new.. and growing (just
not as quickly as some things do).. whereas "rarely-used" when a format is old,
is considered "legacy", and therefore it hangs around, to plague software for
years. I fail to see how if this really is a footprint issue, then all of imglib
isn't being subjected to the fine-tooth comb that MNG was.
This became a hot topic, because of how it happened. There's an injustice in the
way it was removed... Most people respond to situations like this, which is a
good thing. The interest in MNG is good, but the flames really aren't. It's
likely to alienate the supporters of MNG in an enviroment that's already
MNG-unfriendly. Lack of Communication and lack of consideration of others ideas,
played huge roles in the removal of MNG in the first place. Let's prove that we
are more mature than the current owner of libimg. ;-) and work to fix the
problems (both in the code and in the heirarchy), and restore the full-support
of MNG to Mozilla.
-- Wolf
Some comments to address questions brought up in the last couple days:
The reason that drivers went for the VLC profile is that Stuart and I,
not being intimately familiar with the MNG specification, thought that
VLC would at least match GIF's rather modest capabilities.
Glenn was rejected as a maintainer candidate at the beginning because
he had indicated for a long time before that he was opposed to working
in the mozilla codebase. It's great that Glenn is helping develop
libmng, but the maintainership of that wasn't the problem - Gerard was
already doing a fine job there. The code we're primarily concerned
about (setting aside size issues) is the glue code that lives in
It's great to hear that JNG support weighs in at about 13K, but
unfortunately that comes with the caveat of taking a 102K MNG-LC.
That number is unacceptably high penalty for a file format that is an
extension of one already supported in the mozilla codebase (PNG).
I don't like the argument about saving space with MNG throbbers for a
number of reasons:
* I believe Glenn was using full profile features when he made those
throbbers, so those sizes can't be used unless you're talking
about adding full mng back to mozilla.
* The GIF versions of the throbbers are not minimal - a little
experimentation with gifsicle showed they could be smaller.
* Throbbers using 8-bit alpha will cause mozilla to have a bigger
footprint and will run slower (significantly so for gtk on a
remote connection).
>Glenn was rejected as a maintainer candidate at the beginning because
>he had indicated for a long time before that he was opposed to working
>in the mozilla codebase.
"in the libpr0n directory", not "in the mozilla codebase".
See comment #46 and bug #66984. I withdrew my objection a couple of months
ago when I realized that was a battle of egos and that I might need to work
in that directory anyhow.
Incidentally my ISP is spamkilling any incoming bugzilla messages containing
that directory name, through no action on my part.
> I believe Glenn was using full profile features when he made those
> throbbers, so those sizes can't be used unless you're talking
> about adding full mng back to mozilla.
I used full-MNG features, but those features are available in the
MNG_BUILD_LC subset (I explained in bug #204520 that "LC" is a misnomer
because this subset handles MOVE, CLIP, and other things. It handles the
LOOP chunk as well).
> The GIF versions of the throbbers are not minimal - a little
> experimentation with gifsicle showed they could be smaller.
Download size isn't really all that important, I guess, or someone
would have made them smaller.
> Throbbers using 8-bit alpha will cause mozilla to have a bigger
> footprint
The Firebird throbber that I uploaded had a smaller footprint yet
uses 8-bit alpha to avoid the ugly white haloes that were present in
the GIF.
> and will run slower (significantly so for gtk on a
> remote connection).
The reason that drivers went for the VLC profile is that Stuart and I,
not being intimately familiar with the MNG specification, thought that
VLC would at least match GIF's rather modest capabilities.
Translation, this suggestion was made due to ignorance on your part. Since it
has been clarified that VLC would *NOT* be useful in any way as an alternative
to GIF (and therefore have the opposite effect of what is desired by increasing
the code size without adding any valuable functionality), will you withdraw the
suggestion and change it now to MNG-LC?
It's great to hear that JNG support weighs in at about 13K, but
unfortunately that comes with the caveat of taking a 102K MNG-LC.
That number is unacceptably high penalty for a file format that is an
extension of one already supported in the mozilla codebase (PNG).
I don't know about you, but I think MNG is worth an extra *20 SECONDS* of
download time on 56K, don't you? (Especially if it is a configurable download.)
Mozilla is already large enough (as would be any full browser package) that it
is practical for a narrow-band user to download it overnight. What difference is
it whether the download finishes at 1:00:00 AM or 1:00:20 AM? I don't find these
size arguments to be significant -- Nobody was interested in the size hits
caused by so many less valuable changes like implementation of MARQUEE, BLINK,
etc. Please, if you can possibly defend your motives... tell us why we should
care about 100KB more than we care about MNG.
I don't like the argument about saving space with MNG throbbers for a
number of reasons:
I don't either. So why don't I instead make the argument that if I save 10KB per
MNG image (realistic numbers) it only takes 10 MNG images for the added download
time to pay for itself? I know you won't see any MNG banner ads on Yahoo (Why
would they? All the browsers that support[ed] MNG have some form of
ad-blocking... we're just that good!), but MNG will never become popular if
petty issues like this hinder its progress. And if MNG isn't enabled by default
and built into the binaries for end-user download... nobody will see MNG images
and there's no point to ever having supported MNG in the beginning.
By the way, whoever said we should not implement MNG until MSIE supports it...
thanks for a good laugh. :)
Skewer, I think that you are hurting your own cause (which happens to be mine as
well). The tone of your last comment was a bit rude and I doubt that it will
help much. Let's try to leave our egos in the closet and discuss this in a
saner way.
Anyway, it appears that the decision to allow only MNG-VLC in the default build
was based on a misunderstanding of the specs. I am glad that tor mentioned that
in his comment. Now I hope that the drivers will change their mind and allow
MNG-LC in the default build, so that animated GIFs can be replaced easily.
It would be nice to include JNG as well, but I could live without it for the
next release (as long as it can be enabled in non-default builds). But I hope
that we will at least get MNG-LC.
Perhaps this would be a good time to figure out what the majority of us would
agree on. The following seems to be the general consensus:
1) MNG-VLC is unacceptable because its feature set isn't sufficient to make it a
replacement for Animated GIFs, thus making the format unattractive for web
developers. Including MNG-VLC would provide benefit neither to Mozilla nor the
MNG format. It was probably never the intent of the Drivers to select such a
subset. I believe they were simply misinformed.
2) MNG-LC is an acceptable for replacement Animated GIFs and should be part of
whatever level of MNG support is restored to the Mozilla trunk.
3) The MNG_BUILD_LC configuration is an acceptable compromise for the majority
of MNG supporters who use Mozilla because it supports a mild superset of MNG-LC
that allows Mozilla to display the majority of MNG files currently in use. (Let
me know if this is not the case.)
4) JNG support is highly desired, but there are many who feel restoration of JNG
support can be eliminated in the short term if it allows MNG restoration to go
That last part is a bit ironic from a W3C point of view. It's my
understanding that JNG is simply a variation of PNG that supports JPEG
compression. Since both PNG and JPEG are W3C recommendations, and the lack of
sufficient compression in PNG for true color images is one of the major
arguments against using it in web graphics, one would think JNG would not only
be an obvious format to add to a browser, but would also be fairly easy to get a
W3C recommendation for. I suppose the real argument here is whether alpha
channels are more valuable than patent-free animation. Personally, I'd rather
see JNG included, but I'm not sure I'd push the JNG issue at the expense of MNG.
Then again, much of the savings in MNG data size comes from the use of JNG, so
removing it may not work in our favor.
There are still some questions to be answered, though, before we can make
headway in discussing MNG support:
Q1) Do the Drivers(TM) actually have a maximum size in mind for MNG code? (If
creative optimization could bring full MNG support below a code size target
predetermined by the Drivers, then we're wasting our time even talking about
levels of MNG support.)
Q2) Is JNG a critical feature? Is JNG, on its own, worth supporting in Mozilla?
Input from the Drivers is important here. The Drivers need to be more clear
about exactly what they want and are willing to live with, while we need to cut
them some slack and realize that they're not evil Hellhounds come to devour the
soul of our precious baby MNG.
>There are still some questions to be answered, though, before we can make
>headway in discussing MNG support:
>Q1) Do the Drivers(TM) actually have a maximum size in mind for MNG code?
Greg wrote drivers on behalf of himself, Gerard, and me a while back asking
them to clarify that specific question. The answer (comment #200) did not
impose any particular limit. I interpreted that to mean whatever we can
achieve at the moment, with a committment to continue reducing the footprint
as much as possible.
> Q2) Is JNG a critical feature? Is JNG, on its own, worth supporting in
> Mozilla?
I would say no, and yes. To see what JNG can do, look at http://pmt.sf.net/opossum
using a JNG-capable viewer (doesn't work with Firebird + MNG XPI because SF
sends the wrong MIME type, so you may need to download the page and images and
view it locally. Doesn't work with Moz-1.4 on Windows2k and later because of a
Microsoft compiler bug for which I provided a patch that is awaiting r/sr). It
is JPEG combined with PNG-style alpha-transparency, which allows you to get nice
antialiased edges and translucent drop shadows.
More official response in a private message to me, Greg, and Gerard:
Since it was brought to our attention that MNG-VLC is not appropriate
for replacing animated GIFs, it's clear that asking for MNG-VLC was a
mistake. We'd like to have MNG-LC enabled instead. We'll strongly
consider enabling support for JNG-chunks, too, once we've seen the final
footprint numbers.
There is one other thing we'd like to clarify. The above is contingent
on figuring out a way to have MNG and PNG share the PNG code, preferably
by having the MNG support use libpng. I realize this might be hard work
but there is no way to justify shipping two PNG implementations.
Thanks for all your work. We really appreciate it, although I know that
sometimes it may not look that way.
Reading through the MNG specification, it's looking as though MNG-LC can't
perform the GIF restore-to-previous discard method. Is that the correct
that is correct, MNG-LC cannot do GIF restore-to-previous disposal method. The
code built by libmng with the MNG_BUILD_LC macro can, however. I am going to
rename MNG_BUILD_LC to MNG_BUILD_WEB_MNG and reduce the code produced by
MNG_BUILD_LC to approximately what's required by the actual MNG-LC specification.
Here is an update of my results, requested off list by a Driver.
The MNG_BUILD_LC/LC_JNG are renamed MNG_BUILD_WEB_MNG/JNG and
new MNG_BUILD_LC/LC_JNG represent code that implements approximately
the MNG-LC specification. Note that "web" is about 10k larger,
uncompressed, than "lc". "web" in my opinion is the minimally
useful configuration for a browser.
size libimgmng.so size -t mozlibmng.a
Original MNG-1.4 288429 182715
MNG_BUILD_WEB_JNG (includes JNG) 174797 86198
MNG_BUILD_WEB_MNG (without JNG) 104422 73329
MNG_BUILD_LC_JNG (with JNG) 164659 77978
MNG_BUILD_LC (without JNG) 94300 65129
New Default (MNG_BUILD_VLC) 77526 50973
MNG-1.5beta 0 0
Argh. So MNG-LC, previously advocated as the "animated GIF replacement" subset
of MNG, isn't. So in fact there is no "standard" subset of MNG, short of full
MNG, that serves as an "animated GIF replacement"? That's a bummer.
BTW, who has volunteered to maintain the libpr0n MNG code (i.e.,
mozilla/modules/libpr0n/decoders/mng)? Are you all expecting Pavlov to do that?
<i>The above is contingent on figuring out a way to have MNG and PNG share the
PNG code, preferably by having the MNG support use libpng</i>
Finally we know the main (valid) reason for the original removing of mng!!
Thank you, now we understand a lot more what is wanted.
> Argh. So MNG-LC, previously advocated as the "animated GIF replacement" subset
> of MNG, isn't. So in fact there is no "standard" subset of MNG, short of full
> MNG, that serves as an "animated GIF replacement"? That's a bummer.
The MNG spec has always mentioned that MNG-LC cannot do restore-to-previous.
Arghh indeed.
> BTW, who has volunteered to maintain the libpr0n MNG code (i.e.,
> mozilla/modules/libpr0n/decoders/mng)?
I did but was found unacceptable. I'm no longer seeking that job and won't
accept it if offered.
>Are you all expecting Pavlov to do that?
That would be nice. See bug #204520, comment #65, near the bottom: "I am
willing to help."
The libpr0n part of MNG support is only a few hundred lines, most of
which are very similar to the relevant code for supporting other formats.
And Pav wrote it so doubtless understands how it is supposed to work.
>>The above is contingent on figuring out a way to have MNG and PNG share the
>>PNG code, preferably by having the MNG support use libpng</i>
>Finally we know the main (valid) reason for the original removing of mng!!
Why is it a valid reason, to throw out the existing libpng and libmng, both of
which work, and write a new extended libpng that supports both? The most that
could be saved by the (substantial) effort would be 30k, which is the size of
libpng with all of my footprint-reduction work checked in, plus perhaps a few k
in libpr0n. It is claimed that the single library would require less
maintenance, but that maintenance would fall upon mozilla maintainers, not the
current 3rd-party libpng and libmng maintainers.
OK, so here's my understanding of where we're at.
The duplication of PNG code in MNG can't be easily removed. Glenn says maybe in
a year. This is a design flaw and a problem for codesize, maintainability (fixes
may need to be applied in two places), and consistency (different PNG bugs
depending on how you package your PNG).
Pavlov doesn't want to maintain the libpr0n/MNG glue code. So there's no
maintainer for that.
There is no standard subset of MNG that fully replaces animated GIFs. So we're
stuck with either the full library or a subset that Glenn cooked up, which we're
not sure anyone else will actually use.
These problems will all need to be addressed before we can resolve this bug.
Almost certainly any patches would be made directly against libpng. These MNG
"mozilla maintainers" that you speak of. Who are they? I think you missed one
of the original reason that MNG was removed. There is no Mozilla MNG
maintainer. The responsibility for writing this code is left in the hands of
those who want the feature in the tree. It is up to you, Glenn, to come up with
a way to solve the issues at hand. Hopefully Greg and Gerard can help you out.
It seems pretty clear that what drivers and myself are interested in is a PNG
based animation format that can replace GIFs and thats it. A subset of MNG
various MNG parts would certainly be ideal. Perhaps a new MNG-GIF or whatever
"profile" should be put together that only contains those things needed to
replace GIF since it sounds like both MNG-VLC and MNG-LC are both inadiquate.
I'm still baffled by how the MNG creators were able to make "small" profiles
that can't replace GIF. What were they thinking? Also, why was a seperate
library made instead of adding the MNG featureset on top of libpng?
From firstname.lastname@example.com:
> There is no standard subset of MNG that fully replaces animated GIFs. So we're
> stuck with either the full library or a subset that Glenn cooked up, which
> we're not sure anyone else will actually use.
As opposed to MNG-VLC, which we KNOW nobody will use. ;)
From Stuart Parmenter:
> I'm still baffled by how the MNG creators were able to make "small" profiles
> that can't replace GIF. What were they thinking?
Actually, I was just thinking that we should create a specification for the
subset of MNG that Mozilla eventually ends up using. Perhaps "MNG-WEB" or
"WebMNG"? This would let developers of graphics tool know which portions are or
are not supported in Mozilla.
> Also, why was a seperate library made instead of adding the MNG featureset
> on top of libpng?
I was under the impression that libMNG supported PNG files. Why can't the PNG
support simply be rewritten to us libMNG? Wasn't that the whole point behind Bug
48893? I think the problem here is that libMNG is newer, and therefore
considered less stable than libPNG. There's also been some suggestion that
libMNG will eventually utilize libPNG directly to avoid code duplication. Is
this correct?
>There's also been some suggestion that
>libMNG will eventually utilize libPNG directly to avoid code duplication. Is
>this correct?
No, the idea was that when libmng reaches the maturity level of libpng we will
drop libpng and use libmng to handle standalone PNGs.
That doesn't square with recent comments though. We seem to have a brand-new
requirement that we use a single library to handle standalone PNGs and
MNG-embedded PNGs immediately.
Robert : There is no standard subset of MNG that fully replaces animated GIFs.
So we're stuck with either the full library or a subset that Glenn cooked
up, which we're not sure anyone else will actually use.
Considering the fact that this bug currently has 559 votes, I think it is reasonable to assume that
there are some people who would use the MNG support if it were implemented. Also I can assure
you that I personally know of at least 67 people who would use it (right now they are all using
builds of Mozilla that have MNG support). If you are worried about people hating you then be glad
that I have not told everyone about the decision to drop MNG support.
It is unclear to me why you have a problem with whether or not Glenn's MNG_BUILD_WEB_MNG and
MNG_BUILD_WEB_JNG subsets are "standard" or not. They are simply MNG_LC with a few extra
features so that it can effectively replace all animated GIFs. What difference does it make if it is a
"standard" subset?
Pavlov : It seems pretty clear that what drivers and myself are interested in
is a PNG based animation format that can replace GIFs and thats it. A
subset of MNG various MNG parts would certainly be ideal.
It sounds like you are describing Glenn's MNG_BUILD_WEB_MNG which was introduced several
comments ago.
Pavlov : I'm still baffled by how the MNG creators were able to make
"small" profiles that can't replace GIF. What were they thinking?
I am not sure what you are asking, but I will try to answer.
If you are talking about the actual creators of the MNG format then the answer is that they were
not so narrow minded as to think that replacing GIFs was the only purpose for the MNG format.
If you are talking about MNG_BUILD_VLC then the answer as to why they did it is quite simple.
Drivers asked them to do it.
If you are talking about MNG_BUILD_LC then the answer is that the original MNG_BUILD_LC actually
WAS able to replace GIFs. The new MNG_BUILD_LC was created for sake of accuracy when the old
one was renamed MNG_BUILD_WEB.
If you are talking about something else then you will have to explain the question further.
Mark: I wasn't refering to anything you just replied about. Next time you reply
to someone, maybe try and see if they were actually talking to you or not.
As long as Glenn's "WEB_MNG" configuration can *gracefully* work with any fully
standardized image that's the idea...
Glenn, will we lose any of the following in that "WEB_MNG" configuration?
True color / Alpha transparency / Gamma correction
All are features that are very important, but are not supported by animated GIF.
I wouldn't be willing to sacrifice any of them for just a quick alternative to
GIF. Actually, speaking as a web developers, if I could have a format which has
those features and otherwise does anything GIF does, that's already adequate for
any realistic application. There are countless special features to MNG that
don't really have any usefulness at all, I realize from looking at the test
images in MNGsuite. Just like there are JavaScript functions that are virtually
useless that only work in certain browsers, those goofy MNG functions have no
place in Mozilla unless we want to pop up on a DynamicDrive.com type of site.
These kind of features might even be present in MNG_LC but not necessarily
valuable to web developers. If we can be ruthless with this (sure, someone might
find scrolling text MNG images cool, but is it worth having?) we can probably
get a good reduction without the need to squeeze libmng and libpng together
(which for the record, I oppose).
skewer: no one is wanting to remove any core PNG functionality. It is the MNG
featureset that is in question.
If you don't have something useful to add to this bug, please don't post it in
here. This bug is already more than useless. Pretty much unless you are
directly involved with resolving this bug, there is no reason for you to post
anything in here anymore. Please go find some other bug to troll in.
Pavlov: Your attitude towards people in general is not quite justified. No
matter that this is or isn't a /forum/, both here and in 204520 you yourself
either belittled others, or acted selfish and quick-on-the-gun, or came up with
out of the scene ideas (ideas about libmng sizes in 204520 for example).
I mean, right, I do not know you, you are most surely a better programmer than
myself, but I'm very sure that you aren't building a nice picture about yourself
in your public posts. As for what you do in private messages to Glenn or anyone
else -- well, we don't know about that, but your public behaviour is starting to
become ridiculous.
Someone suggested that we all leave our egos behind and try to communicate in an
intelligent manner. That means you too, so please.
You are right about that Skewer didn't read the things well enough (or at least,
I agree on that with you). In this Mark issue I too thought you were talking
about MNG's creators making up stupid subsets -- so I now come to the conclusion
that we don't have telepathic powers, and as such I'd like to ask for some form
of written communication that tries to fit these criteria.
R, not enjoying to be off topic.
Henrik, I've posted all of 1 time in this bug prior to today and I've posted
exactly 1 time in the other bug, and that was only quoting an email that I had
sent. My comments towards Mark were uncalled for, but people have to realize
that this bug has gone out of control. The extra comments in here have got to
stop as they are just wasting my time and the other people trying to resolve
this bug's time. I did not come up with the library size numbers in my email on
my own and most developers I have spoken with believe they are quite reasonable.
Almost all of my discussions relating to this issue occur through email as
bugzilla isn't a discussion forum.
Breaking standards is evil.
At least that is what everybody says if Microsoft does it. Standards exist for a
reason. It brings compatibility between applications. Any image editor/viewer
supporting MNG would follow the standard. If Mozilla chooses to implement a
non-standard MNG subset, there will be a lot of "MNG image does not work" bug
reports. Could you imagine if there were JPEGs and Mozilla JPEGs. PNGs and
Mozilla PNGs, XML and Mozilla XML, HTML and Mozilla HTML?
We constantly bash Microsoft for breaking standards and here we are with Mozilla
doing exactly the same thing. If Mozilla breaks the MNG standard, then we should
all shut up about Microsoft Internet Explorer having broken PNG support. After
all, all Microsoft did is implement a PNG subset, supporting GIF features.
Mozilla has a virtual monopoly for viewing MNG images, but does that mean is
should abuse that monopoly? If something is wrong with a standard, then the
standard should be changed not broken.
There are more reasons to support the full standard. If PNG is just a GIF
replacement, why not limit Mozilla PNG support to 256 colors and remove its
alpha channel support? My guess is that the world would be too small. Both PNG
and MNG/JNG are attractive, because of their expanded feature sets.
The argument of PNG/MNG being a GIF replacement is also faulted. GIF patent
issues are already over in the USA and starting June 2004 will be over anywhere
else. Do we drop PNG and MNG support on that date?
A MNG subset is not MNG and if MNG/JNG is seen as a valuable addition (and I too
think it is) then it should be implemented fully according to the standard.
Breaking standards (ie implementing a subset) brings us in Microsoft territory.
> Glenn, will we lose any of the following in that "WEB_MNG" configuration?
> True color / Alpha transparency / Gamma correction
No. We lose deltaPNG and 16-bit support (16-bit images are downgraded to
8-bit during decoding so you won't see much difference on your screen).
I mistakenly removed PAST chunk support yesterday from WEB_MNG and will restore
it shortly, at a cost of around 5kbytes.
The rest of the features that are removed are ones that Mozilla doesn't use
If you try to read a MNG file that uses DeltaPNG, you will get the "image cannot
be displayed because it contains errors" message. Any other files should be
shown OK (with possible degradation due to 16-bit to 8-bit downgrading).
If you configure --with-system-mng or if you use the MNG XPI then DeltaPNGs
will be OK and there won't be any 16-bit to 8-bit degradation.
Jan Derk, it is quite common for programs to support SUBSETS of file formats
like MNG. This is not breaking a standard, and forcing everyone to support every
last feature in a spec like MNG's is not always reasonable.
What Microsoft has frequently done, however, is to make ADDITIONS to a
standard that weren't part of the standard to begin with and break the
extenstion model set up for that standard. Their Java (later known as the
Microsoft VM) is an excellent example of this.
What "MNG-WEB" tries to do is implement a subset of full MNG format that will
still work if rendered by a full MNG implementation. (I'm hoping it also
supports Dynamic MNGs. I'm looking forward to creating web pages with Dynamic
MNG.) This can be good or bad depending on the following:
1) Are the features supported by MNG-WEB going to be documented so that people
can create efficient MNG files that work with Mozilla?
2) Will MNG-WEB lack features needed by some web developers?
3) Is MNG-WEB a true stepping stone to the eventual reintroduction of full MNG
support, or just a way of quieting down the MNG community while shaving some
code size from Mozilla?
On a side note, I do think that the situation for this bug has gotton out of
hand. While I dispute the idea that this is not the place for a discussion on
the bug to take place, I do feel that there has been a lot of nonproductive
conversation, and that at this point Bug 18574 is too broad, considering all the
issues involved in MNG support. Perhaps the best solution is to break this bug
apart into separate bugs that cover the following:
- Restoring JNG support.
- Restoring MNG-LC/MNG-VLC support.
- Restoring "MNG-WEB" support.
- Restoring full MNG support.
In this way, I believe we can get better feedback from the Drivers, more
focused discussions, and the votes for each bug can be used to gage the
importance of each of these to the community at large.
Just read Glenn's message. Glenn, are you saying that MNG-WEB for the most
part only exclude features Mozilla couldn't use anyway?
1) Are the features supported by MNG-WEB going to be documented so that people
can create efficient MNG files that work with Mozilla?
It's just a snappier name for profile 975 found in the MNG spec. And
MNG_BUILD_WEB_JNG equates to profile 991.
2) Will MNG-WEB lack features needed by some web developers?
Yes, it lacks DeltaPNG which includes some goofy things like palette
3) Is MNG-WEB a true stepping stone to the eventual reintroduction of full MNG
support, or just a way of quieting down the MNG community while shaving some
code size from Mozilla?
It doesn't seem to be either at this point. It is merely a huge waste of
my time. "Shaving" some code size? It's been cut about 60 percent. That
more like major surgery.
Jan Derk's comment is quite correct, and explains exactly why we can't just ship
some random subset of MNG such as Glenn's WEB_MNG, which would essentially be
Saying it's "profile 975" isn't a good answer. "975" is just the setting of 9
feature bits. It isn't given a proper name anywhere in the spec or listed as a
reasonable development target.
> Jan Derk's comment is quite correct, and explains exactly why we can't just
> ship some random subset of MNG such as Glenn's WEB_MNG, which would essentially
> be Mozilla-MNG.
OK, I added one more configuration for testing purposes. The macro is
MNG_BUILD_MOZ_MNG and the result is a full MNG implementation with various
footprint reductions that don't reduce the feature set other than removing
features that Mozilla wasn't using. It handles 16-bit samples by demoting
them to 8-bit while reading. It does handle DeltaPNG and JNG.
See bug #204520.
Size on my FreeBSD5.0/gcc3.2.1 platform are
mozlibmng.a 107877 and libimgmng.so 200835.
>Saying it's "profile 975" isn't a good answer. "975" is just the setting of 9
>feature bits. It isn't given a proper name anywhere in the spec or listed as a
>reasonable development target.
It was an answer to the statement that MNG-WEB should be documented. "975"
is listed in the spec as "MNG without DeltaPNG or JNG".
MOZ-MNG would be profile 1023 which means complete MNG support.
There have been some comments that DeltaPNG is about 'goofy' stuff like pallette
shifting. Actually, it's about image-compression:
"Several movies of finite-element calculational results by the U. S. Army
Research Laboratory required only about a quarter of the file space when
converted from a simple series of PNGs to delta-encoded PNGs."
Previous comments indicate the size of the DeltaPNG code is about 7k. Surely if
anyone ever hits a delta-png, just once, the download size will have been made
up for. I'm fairly interested since I'm among the 60% of users who can't/won't
get broadband.
This isn't new territory in motion image compression - all the MPEG specs are
based on delta images.
I see a parallel with the gzip content-compression code. A tiny code fragment
greatly improves the low-bandwidth experience.
Here's the numbers again. Hope I didn't mess anything up...
size libimgmng.so size -t mozlibmng.a
File Sizes:
Original MNG-1.4 288429 182715
MNG_BUILD_WEB_JNG (includes JNG) 174797 86198
MNG_BUILD_WEB_MNG (without JNG) 104422 73329
MNG_BUILD_LC_JNG (with JNG) 164659 77978
MNG_BUILD_LC (without JNG) 94300 65129
New Default (MNG_BUILD_VLC) 77526 50973
MNG-1.5beta 0 0
Savings over Mozilla 1.4:
MNG_BUILD_WEB_JNG (includes JNG) 113632 96517
MNG_BUILD_WEB_MNG (without JNG) 184007 109386
MNG_BUILD_LC_JNG (with JNG) 123770 104737
MNG_BUILD_LC (without JNG) 194129 117586
That's a log of options, and all of them save considerable space over Mozilla
1.4. MNG-VLC and MNG-LC are non-starters due to the fact they can't
realistically compete with GIF, so we can throw them out. MNG_BUILD_FULL_MNG
doesn't really offer anything significant over MNG_BUILD_MOZ_MNG, so let's toss
it out too. That that just leaves us with this:
size libimgmng.so size -t mozlibmng.a
File Sizes:
MNG_BUILD_WEB_JNG (includes JNG) 174797 86198
MNG_BUILD_WEB_MNG (without JNG) 104422 73329
MNG-1.5beta 0 0
Savings over Mozilla 1.4:
MNG_BUILD_WEB_JNG (includes JNG) 113632 96517
MNG_BUILD_WEB_MNG (without JNG) 184007 109386
MNG-1.5beta 288429 182715
Now if we had a size target, like I'd suggested, the debate would be over.
Simple math. If the target was ~180KB, we'd go with MNG_BUILD_WEB_JNG and focus
on reducing the size of MNG_BUILD_MOZ_MNG so we could use that later. If they
want ~50KB, we continue to try and convince them otherwise while working on the
plug-in. One could argue that MNG-WEB isn't sufficient, but it's a heck of a lot
better than nothing, and I think most of us would take it if we had no other
choice. There doesn't seem to be a whole lot to debate here.
Unfortunately, we have no hard targets to hit, so we end up in a massive MNG
civil war about who's feature to kill. The Drivers need to step in and give us
an idea of what they think is reasonable with regard to size and features so
that this discussion doesn't wander into the impractical and the purely theoretical.
One of you wrote me privately asking for one set of numbers (I did not
upload a patch to actually install this macro):
libimgmng.so.gz is 52k which would be about the effect on download size.
However, the important number is still
Jan Derk's comment is quite correct, and explains exactly why we can't just
ship some random subset of MNG such as Glenn's WEB_MNG, which would
essentially be Mozilla-MNG.
Saying it's "profile 975" isn't a good answer. "975" is just the setting of
9 feature bits. It isn't given a proper name anywhere in the spec or listed
as a reasonable development target.
Glenn: Just so I'm not misunderstanding... These subsets of MNG you've been
putting together will load virtually any MNG image that doesn't use those
intentionally excluded features, right? As long as anyone could use one of the
MNG-supporting graphics apps to create MNG images and they would work fine in
Mozilla, that's what matters. It's not fair to developers to have to do anything
special to their images to have them work in Mozilla. If I'm correct then I see
no reason to build MNG a certain way to make it match a standard, as long as it
still works right for displaying MNG images.
I really can't understand the point of removing a working feature based on a
working-draft of a web standard for the sake of 300k.
Three Hundred Kilobytes.
That is one five-hundred-thousandth of my hard disk space.
"lets see what we can do now.. i know, lets remove support for jpeg, that ought
to make the footprint smaller"
What next, remove support for HTML?
The sheer number of votes and comments for this bug shows how stupid an idea it
is to remove MNG support.
> Three Hunded Kilobytes
It Two Hundred Kilobytes now: MNG_BUILD_MOZ_MNG 200835
This build provides FULL MNG SUPPORT. No features are excluded.
> Glenn: Just so I'm not misunderstanding... These subsets of MNG you've been
> putting together will load virtually any MNG image that doesn't use those
> intentionally excluded features, right?
I think this is an important distinction to make.
Based on the comments, people seem to fear MNG being built "A certain way"
because of the perception that this build will require "special effort" on the
part of MNG creators to be conformant to spec 975.
My understanding is that this is not the case, that MNG's *will* work "out of
the box" when created as animated GIF replacements, with no special tweaking.
This is an important point - if content *creators* need to do nothing different
to support MNG_BUILD_WEB_MNG, then we are *not* being incompatible, and we are
*not* creating a situation where People will start considering this MNG
implementation as MOZ-MNG, IMHO.
Ken: That only assumes that developers are _only_ looking for an animated GIF
replacement and will not use other features. The comparison brought up before
was the IE PNG implementation: IE doesn't support the alpha channel, but
supports enough of the standard to be a strict GIF replacement. The same
problems will eventually occur when MNG becomes more widespread.
Re: comment #290
This one strikes home since I've been meaning to fix a bug I ran into with MNG
and still haven't found the time.
However, I would not have run into the bug if I hadn't stayed at 1.4 (MNG is the
reason I stopped using nightlies).
Eliminating MNG is a good way to guarantee that number will never rise above 0.
Ken: That only assumes that developers are _only_ looking for an animated GIF
replacement and will not use other features. The comparison brought up before
was the IE PNG implementation: IE doesn't support the alpha channel, but
supports enough of the standard to be a strict GIF replacement. The same
problems will eventually occur when MNG becomes more widespread.
We need to use judgment on what most web developers won't use... Some features
might be powerful but fairly unlikely to appear in, say, an ad banner or intro
page just because of the effort involved in putting together a MNG image that's
capable of doing that. Priority 1 is just supporting images that have been put
together by an Animation Shop-type program. The best part is if some feature
someday becomes important we can add it back in later!
Exactly - The focus here should really be on adding just those features needed
to provide MNG support for the majority of MNG's on the web /today/. We can RFE
in the additional features as popularity grows.
Also, remember that the *full* MNG spec is not even used entirely by Mozilla
anyway, so we were implementing a "subset" of MNG even in 1.4. :)
1.4 implemented FULL MNG. Not a subset. It worked fine until it was
sabotaged on June 3. Some ancillary chunks weren't used (iCCP, cHRM, etc)
but files containing them were processed correctly.
"We can RFE in the additional features as popularity grows."
Ya. Considering the dismal rate at which RFE bugs are addressed in Mozilla (1965
fixed out of 6500+), that seems about equivalent to saying never implement the
additional features.
Supporting a Subset of the MNG specification is a balancing act. It makes some
logical sense when looked at like this...
Because it's a relatively new format, and not *yet* widely used... It makes it
difficult to be able to continue to justify having the entire thing included..
(although it *was* there.. go figure..) Although, I don't think it's an
unreasonable assumption to make, that when the format is more widely used,
increasing the features Mozilla supports will not run into as many problems as
we currently face.
So, the idea has evolved to supporting what's needed to make it useable support.
Being careful not to make mistakes that may come back to haunt us.. (Similar to
Microsoft's decision to leave out Alpha support for PNG with IE on Windows)..
So, we leave out what isn't *needed*... and try to make the most complete (while
still remaining useable)... Creating a strict GIF-Replacement, doesn't do the
format justice.. because of the enhancements it has over GIF. But, at the same
time, providing the features to convert from GIF to MNG easily is probably a
decent idea.. (since migration away from GIF is kinda expected by this format).
As long as the subset Mozilla implements is completely based on the standard
(I.E. not adding anything special... or not supporting something seriously
required)... then I believe that there isn't a big problem there.. (Feel free to
correct me if I'm wrong though).
From my understanding.. libmng was designed to be a eventual replacement for
libpng, supporting PNG as well as MNG/JNG images.. (correct?) but what's being
proposed now, is extending the current version of libpng Mozilla uses, to
include the same support.. Why? I realize libpng has the benefit of being more
tested than MNG.. but other than that, what prevents the use of libmng to handle
the current functions of libpng as it appears to have been designed? (and still
remove the duplicated code in the process) But.. neither of these are good as a
short-term goal.. (Showing my software development inexperience here) Is it
possible to build an experimental version of Mozilla where libmng handles PNG?
(assuming both libpng and libmng were back avaiable).
Excluding that particular debate.. which has been going on awhile.. (Bug #48893
has been around since 2000-08-14 (or 3 years. after all)). That leaves us with 2
other specific issues..
(1) Select a subset of MNG functionality that will work for our needs..
(Numbers previously posted):
size libimgmng.so size -t mozlibmng.a
MNG_BUILD_MOZ_MNG 200835 107877 (All but Moz Unused Features)
MNG_BUILD_WEB_JNG (includes JNG) 174797 86198 (Former Build LC_JNG)
MNG_BUILD_MOZ_MNG_NO_JNG 130329 93980 (Moz Unsed excluding JNG?)
MNG_BUILD_WEB_MNG (without JNG) 104422 73329 (Former Build LC)
Savings over Mozilla 1.4:
MNG_BUILD_WEB_JNG (includes JNG) 113632 96517
MNG_BUILD_WEB_MNG (without JNG) 184007 109386
In an ideal world, we'd pick MNG_BUILD_MOZ_MNG (the whole thing minus what Moz
doesn't need)... but I have a feeling that 200835 is still too large at the
current time to be justifyable.. Leaving out JNG support and dropping to it's
smaller brother, MOZ_MNG_NO_JNG would bring it down to 130329, which to me, is
an acceptable increase.. Now based on the summary of this bug, that
configuration would not RESOLVE this bug, but, it's a start.
The other 2 configs.. WEB_JNG and WEB_MNG which are around 25k smaller.. leave
off parts of the MNG specification that may actually be used.. (DeltaPNG was
mentioned specifically). According to posts here, Delta-PNG allows files to be
much smaller, resulting in faster browsing. So, assuming somebody hits a file
and this part of the code is used, the size is made up for.. (also, if it
becomes a widely used part of MNG in practice, and it's not supported in Moz..
then the implementation is useless. No matter how much space it saves.) I assume
Delta-PNG is supported for PNG under libpng?
Based on what has been said, the WEB_MNG config is the minimal that we could
use.. (Based on Drivers request for a GIF replacement.. (restore-to-previous was
specifically mentioned in the discussion as being missing under LC but in WEB).
So, under my understanding the differences between the WEB vs. Moz is Delta-PNG
(only thing that's been mentioned by name).. and obviously, between each of
those and their smaller half-brothers would be whether or not JNG is included)..
So, the questions are, how important to us is Delta-PNG and JNG support? if we
need to pick one? which? and is it practical to pick either? The current numbers
speak for themselves...
(2) On to the second problem, that needs resolving...
For any of the above to matter, MNG needs a maintainer for libpr0n/MNG code.. (I
think that's all that's missing a maintainer.. as long as we're still using the
extenal library) Anybody willing to help out here? I would volunteer as I have
the time.. but my programming skills are beyond insufficent for such a task. heh..
Hope that discussion helps..
-- Wolf
>increasing the features Mozilla supports will not run into as many problems as
>we currently face.
It would be a simple matter of turning off the macro(s) that disable(s) the
feature(s) being added. Technically no problem but will require a lot
of squabbling in bugzilla about file size versus feature set.
>From my understanding.. libmng was designed to be a eventual replacement for
>libpng, supporting PNG as well as MNG/JNG images.. (correct?) but what's being
>proposed now, is extending the current version of libpng Mozilla uses, to
>include the same support..
That is pav's proposal but I don't think anyone else endorsed it. It means
throwing away two working third-party libraries, libmng and libpng, and writing
a new one specifically for mozilla.
>Is it
>possible to build an experimental version of Mozilla where libmng handles PNG?
>(assuming both libpng and libmng were back avaiable).
As I've said before, just have libmng handle PNG files that have the .mng
>In an ideal world, we'd pick MNG_BUILD_MOZ_MNG (the whole thing minus what Moz
>doesn't need)... but I have a feeling that 200835 is still too large at the
>current time to be justifyable..
This is easily reduced about 60k by removing the extra copy of libjpeg.
> I assume
> Delta-PNG is supported for PNG under libpng?
It is not, and that is the major reason libmng's support for standalone PNG
files requires more code, memory, and time that libpng does. At the time a
PNG file is being read, libmng does not know whether it is going to be used
as a movable object or the source of a deltaPNG. Therefore it has to store
much more information about the file instead of simply blasting it onto the
canvas like libpng does.
>restore-to-previous was
>specifically mentioned in the discussion as being missing under LC but in WEB
It's worth noting that restore-to-previous is pretty rare. A couple years ago I
collected all the banner ads I saw over the period of a few months--about
600--and only two used restore-to-previous (and neither of those used it
We should use the newsgroup netscape.public.mozilla.performance.size-matters
for most of this talk.
Created attachment 130784 [details]
Browser crashes when viewing JNG file
That is bug #196670. A patch has been completed to fix that bug, but Pavlov is
being mighty slow reviewing it (i.e. ignoring it).
See bug #196670 about the JNG problem. If you have a pre-June-3 Mozilla or
Firebird browser running on Windows 2000 or later, the JNG decoder fails due to
a Microsoft compiler bug. There is a fix awaiting review, and an "aebrahim"
optimized executable Firebird with the fix is available at pmt.sf.net.
Still no progress, and 1.5 is nearing RC status.
We need some rogue CVS user who actually cares about 578 votes to check this
back in to the trunk when nobody is looking...
Unfortunately, it would take a rogue CVS user with CVS write access, so most of
us are probably out. However, given that Mitchell Baker mentioned that Mozilla
would focus on "improvements in performance, stability, standards support and
Web compatibility" recently (http://lwn.net/Articles/47298/), there still might
be hope..
That would be OK as long as the "rogue" is qualified and volunteers to take
on maintaining the libpr0n and configuration portion of MNG support. Libmng
is already taken care of.
Due to some minor bit rot, the "reversal of mng removal" patch needs a little
work before anyone can check it in. Attempting to use the patch as is, against
the current CVS, results in rejections for allmakefiles.sh, configure.in,
config/module2dir.pl, and build/unix/modules.mk. It appears that manually
updating these files is fairly straightforward and simple, except for
config/module2dir.pl which as far as I can tell no longer contains the list
of directories that would need to be changed to support MNG. "configure"
would also need to be updated via autoconf, after patching configure.in.
Re: comment #304: the Windows XPI for MNG has been updated to fix the JNG crash
problem. See bug #196670 comment #43 for details.
Congratulations, mozilla.org team! Now over 600 votes are falling on your deaf ears.
We couldn't have done it without pavlov, who has gone far, far out of his way to
avoid anything MNG-related (the crash-causing bug 196670 went unapproved for
months on his watch), asa, who considers MNG lowest of all low priorities
despite it having the most votes EVER on Bugzilla (
http://forums.mozillazine.org/viewtopic.php?t=16653&start=17 ), and everyone
else who is pitching in on Operation Ignore.
It's good to know that the top guys at the Mozilla Foundation still care about
the community!
It is pretty funny that this bug has more votes than there were MNG images on
the Web while Mozilla supported MNG...
Of course you won't find many MNG images on the web, simply because almost
nobody could see them with their browser. That's not the point. The same can be
said of CSS3, but that didn't stop you from implementing this "bloat" (and
rightly so).
There ARE companies that have standardized internally on Mozilla/Netscape
because of MNG support (see the comments in this bug). These companies use MNGs
in their intranet and thus need a browser that supports them. Naturally, the
browser used to browse the intranet is also used to browse the internet, thus
increasing Mozilla marketshare.
And MNG images on the web won't increase if browser support for this image
format decreases (d'uh!).
So when do we see the patch from you, Ian, to remove CSS2/2.1/3 support from
Mozilla because almost no web sites use it? Or is this a different issue? Maybe
because you are involved in creating these standards?
And while we're at it, why not remove this silly voting thing from bugzilla.
It's pretty obvious that it serves no purpose as votes only have a meaning when
developers agree.
Maybe before you fly off the handle at me, you should check your facts. I'm in
the pro-MNG group. That doesn't mean that I can't find it funny that there are
still more people voting for this bug than there are MNGs on the Web.
> Of course you won't find many MNG images on the web, simply because almost
> nobody could see them with their browser.
That hasn't stopped the proliferation of SVGs, or TIFFs, or any number of other
formats for which no Web browser has native support.
> That's not the point. The same can be said of CSS3, but that didn't stop you
> from implementing this "bloat" (and rightly so).
Actually, we have very little CSS3 support, and what little we do have, is in
much wider use than MNG.
> There ARE companies that have standardized internally on Mozilla/Netscape
> because of MNG support (see the comments in this bug).
I couldn't find the comments you referred to.
> These companies use MNGs in their intranet and thus need a browser that
> supports them. Naturally, the browser used to browse the intranet is also used
> to browse the internet, thus increasing Mozilla marketshare.
Nothing is stopping such companies building their own Mozilla with MNG support,
or using the XPI that has been made available.
> And MNG images on the web won't increase if browser support for this image
> format decreases (d'uh!).
MNG images on the Web didn't particularily increase while support was increasing
either. Almost all the MNG images on the Web are either testcases, or
demonstrations of the MNG spec.
> And while we're at it, why not remove this silly voting thing from bugzilla.
> It's pretty obvious that it serves no purpose as votes only have a meaning
> when developers agree.
Voting reduces the number of redundant comments in the bugs themselves, which
makes bugs more likely to be fixed, since bugs with more comments are less
likely to be fixed since they are harder to read through.
However, you are completely right that the developers that you are not paying do
not care what you think. They are mostly doing this in their free time. If you
want an MNG-enabled build, why don't you download the source, add MNG support,
and distribute the binaries you create? This is how Free Software works -- you
are free to do what you like.
we (the opensource community) simply need the support of a better animation format than GIF
I was waiting to use MNG in my own website. I was waiting a good gimp support, some better linux
tools to edit animation, things like that. I never expected mozilla to drop a royalty-free format.
why did you remove that ? because it's "bloat" ? I think it was good bloat if you care my opinion.
it's a good thing to support a format like mng
about use, of course mostly noone used mng, mozilla is for the moment a minor browser, the
major one is IE and IE doesn't support MNG , but with time, mozilla was a good tool to promote
like it promote PNG
I read you can add an xpi or to compile a new binary of mozilla with whatever features I want
(mathml, good svg, and so on ) but USERS ? I don't care about myself, I care about "users" which
can read my own web-sites.
I need they can have EASILY a good featured browser , I need an easy tool and world-known to
promote open format. With things like Alpha channel png, with good animation, with (I hope one
day) good vectorized animation (svg) it's easy to convince people mozilla is better
easy to convince developpers, easy to convince users (with a beautiful website using new formats)
Mozilla is ONE way to promote MNG, when mozilla remove it, it says to everyone "mng is a failure"
and no one will want to add it to gimp or kde programs or whatever.
SVG is used not because of mozilla, but because the community NEED a vectorial format to do tools
like illustrator , think about Sodipodi or Sketch (and others) , of course, it would be great than ALL
official mozilla build have svg features, we could add some svg graphics to webpages and it would
be efficient to promote svg tools (adobe commercial ones or opensource ones).
But svg is not like MNG, svg is pushed by adobe and w3c, it helps. mng need some helps. mng
need mozilla.
mozilla is not only a group of developpers which don't care about users, it's about a web-browser
with respect for standards , a webbrowser for developpers, web-developpers ,designers AND
_users_. and, I really don't think ALL "mozilla developpers" don't care about people's opinion, it's
not what I understood when I spoke month ago with some mozilla and netscape (at the time)
please reconsider your opinion.
Alright... Before this bug flies off the handle again with pro-MNG and anti-MNG
posts that add to an already difficult to read through advocacy bug...
(1) Personal Attacks aren't going to get anybody anywhere... usually they're
only likely to further isolate the person you're attacking from the cause you
want them either to embrace or stop blocking.
(2) MNG was removed.... the reasons at this point... don't seem to matter much
anymore.. Basically, it was opinions of code bloat.. which were used
unilaterally against some parts of the code.. and the lack of a maintainer for
the glue code for MNG as part of libimg2... The latter still lacks a maintainer
which seems to have stalled any progress as part of bug 204520.
So, before a second bunch of ranting starts.. try reading through this bug and
Bug 204520.. ;-)
-- Wolf
At this point, it seems clear to me that restoring MNG is the only way to stop
the ranting.
Yes, implement my feature request or I shall taunt you a second time!
Has it really come to that? Will someone start drowning a baby kitten each day
that MNG remains disabled?
Removing myself from the CC list, since the removal of MNG from Mozilla hasn't
really made life that much worse for me. However, listening to your diurnal
whining has.
Perhaps some of you should take this as a hint. And a chance to reflect. I can
assure you life will continue as unplanned without MNG support in this
particular browser. I encourage you to remove your votes on this bug as a simple
show of support for rationality. (not that implementing MNG is irrational, but
the fact that there are three-hundred and eighteen comments here is).
Oh, also: bugzilla is not a discussion forum. (cf. netscape.public.mozilla.*)
See 222099.
In reply to comment #318
This is not about implementing a feature request. This is about restoring
functionality that Mozilla used to have and for which there is no replacement.
MNG support was one of the features that brought me to start using Mozilla.
Others have cited MNG as a requirement for Mozilla theme developers to make
themes that don't look like ****.
MNG is a stable, open, free standard that Mozilla has working code for. There
are hundreds of people who use MNG or are interested in using MNG, and thousands
more who don't know what they're missing and will become as angry as the rest of
us when decent MNG editors are developed.
If rationality were in charge, MNG would never have been dropped from Mozilla in
the first place or it would have been restored after the file size issues were
solved. Instead, we have a egotistic self-centered clique refusing to admit they
may have made a mistake and making the Mozilla project and community suffer for
their errors. This is hardly rational behavior that you are supporting!
Dropping votes for this bug will do nothing to enourage the Mozilla developers
to restore MNG support. Voting is a simple way to show that there actually is
community support for the MNG format. I want to see more votes for this bug so
it continues to stand out as a shining example of bad management practices.
Comment # 318 says: "I encourage you to remove your votes on this bug
as a simple show of support for rationality."
OK, removing mine. It might be fun to rock the boat a little. Let's
put them all (temporarily at least) on bug #196670 which is blocking
this one, has been r'ed and sr'ed and is just awaiting "approval", to
work around the JNG crash that is due to a Microsoft compiler bug.
Well, 1.5 has been released, no merging in of MNG - not to mention the patches
to reduce bloat/redundancy/crashes.
I guess I'm going to have to rip out all the lovely JNG images on my website.
Sure was nice to have complex images that looked great on any background, and
could overlay stuff as well.
However, while I was able to convince those people using my site to stay with
1.4 for time being, most of 'em will want to update to 1.5.
Unless someone here has the bandwidth and desire to put a mirror out for a
patched version? Could link my friends to that.
I could also add the patches to the Gentoo ebuild that will be coming out - try
and convince the Gentoo maintainers to use them as well.
only drivers can set blocking. If you're not a driver, please don't.
(not to mention it's too late to block 1.5 anymore anyway)
Recall that in comment #200, drivers approved restoring MNG support. This
approval had two parts:
1) They invite MNG support to be put back in the image library as a
configurable option that is turned off in default
mozilla.org-produced builds (Seamonkey, Firebird, Thunderbird).
The only thing preventing this from happening is the lack of a qualified
volunteer to do it! If you are able, please volunteer. I will help you
do the work. Your first task (easy) will be to check in the tiny patch that
fixes bug #196670.
2) They are interested in having only MNG-VLC supported as a configurable
that does not entail all the footprint of full MNG, and would support
such a subset being turned on in mozilla.org-produced builds and made
part of the "typical" GRE configuration that Mozilla.org brands and
In subsequent discussion it became evident that MNG-VLC would not be useable,
and we didn't come to a conclusion about what larger subset of MNG would be
OK. I don't see any point in resurrecting that discussion right now; let's
find the volunteer and get part 1 done first, using the MNG_BUILD_FULL_MNG
configuration of libmng-1.0.6.
I expect that libmng-1.0.6 will be released at the end of this week.
libmng-1.0.6beta1 has been out for a month and no bugs have been reported
against it.
Comment #322 asks: "Unless someone here has the bandwidth and desire to put a
mirror out for a patched version?"
I have both. The bandwidth is at mngzilla.sf.net, project just initialized
today to develop the MNG-restoration patch and to host MNG-enabled binaries.
I can build Windows binaries of the releases.
I can provide Linux builds.
Then, let's rock! I want to be able to upgrade to 1.5, but don't want to lose MNG.
Good to see some cooperation and helpful ideas!
Hopefully we'll have a project space forum to comment in shortly, but I
volunteer to create the Gentoo ebuild.
Should be fairly trivial. Just the 1.5 ebuild and appropriate patches, plus a
build flag.
Will ask the Gentoo developers if MNG can be default build flag, with -MNG to
explicitly disable.
Also. Camino, anyone?
And we should check out fedora.redhat.com to see about mozilla+mng being
incorporated into Redhat distro.
How about Debian. Any debian package builders here?
If I understand it correctly, I just apply the last three patches in this bug to
the 1.5 sources in order to get what we want here right?
Re: patches in comment #330, see http://mngzilla.sf.net
Is chrome now able to use MNG's? If not, why the removal of blocking bug 8415?
I removed "or MNG" from the summary of bug #8415 because that part was currently
invalid. Perhaps someone will open a new bug that says animated chrome should
use MNG, which depends on this bug.
>Comment #322 asks: "Unless someone here has the bandwidth and desire to put a
>mirror out for a patched version?"
>I have both. The bandwidth is at mngzilla.sf.net, project just initialized
>today to develop the MNG-restoration patch and to host MNG-enabled binaries.
Have just built a Firebird, based off trunk checked out earlier today, with MNG
support built-in. Used the reversal patch and information from MNGZilla
(comment 331) and applied the changes by hand, as the patch makes me uneasy
because it's outdated. It's affected by bug 196670 "JNG crashes Win32 builds"
but displays MNG images adequately.
Currently hosted on my little webspace. I wouldn't mirror that build yet,
(unless you need a Firebird build mirrored) as this build was simply an
experimental to see if the patching would work. I compile a SVG-DOMi-Venkman
build on a daily basis, and will probably introduce MNG to my daily Firebird
build. Future builds of mine will most likely be found on the MozillaZine
Firebird Builds forum. (My username is "MadmanNova".) If you wait until
tomorrow or later this week, you'll see a MNG-SVG-DOMi-Venkman build. At that
point, I think it would be a-okay to mirror.
Created attachment 134523 [details] [diff] [review]
Updated removal reversal patch (using svg branch)
Did the MNG removal reversal patch on a freshly checked out tree and diffed to
get a newer version of the patch. (Some of the older patch was outdated.)
Caveat: This tree is off of the SVG_20020806_BRANCH, however. The files that
may be affected are configure.in and config/autoconf.mk.in.
Currently trying a new build, having taken these steps:
Checkout SVG_20020806_BRANCH for Firebird, with SVG(libart).
Applied diffs in new patch. (Well, I modified by hand, and then diffed.)
Put copies modules/libimg/mng and modules/libpr0n/decoders/mng into the tree.
(From mngzilla site.)
Run autoconf to re-do configure.
Glenn: I've applied your modifications to libmng_chunk_io.c for this build.
I'll report back later tonight with results. I've been having trouble building
anything today with the plethora of new checkins, so I decided to go for a
fresh tree. Hopefully the build problems I've been having were ironed out.
Created attachment 134552 [details] [diff] [review]
Updated removal reversal patch (mozilla-1.6)
Really sorry about the bugspam.
Apparantly, something in a recent checkin was killing my SVG builds, so I had
to checkout a new tree. So I went and re-did the entire tree and checked the
patch information again. (It wasn't broken--something else was--but I still
wanted to make sure I fixed it.)
A newer Firebird MNG-only build will be up soon, provided nothing else is
broken in the trunk.
I'm also using the MNGZilla method of implementing MNG by simply overwriting
the directories with a MNG-capable version of the files. However, doing this
with the trunk--especially at a time like this when the 1.6b checkin window is
open--is difficult because they change rather quickly. My proposed method of
getting a build like this with little effort is to:
Use MNG patch (like the one I have), provided it's recent (close enough to
current code tree).
Copy (unzip?) the [modules/libimg/mng] and [modules/libpr0n/decoders/mng]
directories to the code tree.
Run autoconf (or "bash autoconf" from DOS) in the top source directory to
reconfigure the configure file.
You _should_ be able to build properly after this.
Checkouts with updates to any of the configuration stuff
(build,autoconf,configure) may (and probably will) cause problems, though. The
configure file can't be edited manually and still work. It's seriously
impossible. And using a pre-configured configure file (like from the MNGZilla
CVS) won't work with basically anything much recent than the tree it was
created from.
I was having trouble with the MNGZilla provided files (from CVS) and
overwriting everything the way I was supposed to, and I didn't realize about
the configure until after a while. Wasn't in the documentation or anything
(that I noticed) so I toyed around with it for a while before figuring it out.
Just a few words to anyone out there who wishes to build as well.
New Firebird build up, with a fix that Glenn sent me that appears to have fixed
bug 196670.
A very very happy success, IMO.
Re: comment #337: Nova's Firebird with MNG support and JNG fixed, built
for Windows 2000+, is at
I've verified (on a FreeBSD platform) that Nova's "trunk" patch will
successfully and simply add MNG capability to Mozilla-1.6a. I've combined the
patch with the set of libimg/mng and libpr0n/decoders/mng files that need to be
restored, and a README.txt, into a SourceForge distribution file (choose one of
tar.gz, tar.bz2, or zip) at
The fix for bug #196670 has been applied to this distribution.
Firebird 0.7 (Release Version) with MNG enabled:
Built with MSVC 7.0, dynamic build. Compatible:
Win 95(?;unlikely)
Win 98(?)
Win ME(?)
Win 2000
Win XP
I don't intend on announcing anymore builds here, unless they are release
versions, or if they are for platforms that currently don't have it.
2 Votes for Bug 195280 - Removal of MNG/JNG support
614 Votes for Bug 18574 - restore support for MNG animation format and JNG
image format
Shouldn't Mozilla be a democratic product and not a monarchic one?
Greetings from Micro$oft ...
MNG & JNG have to be supported by default otherwise the development
of the World Wide Web will suffer.
Alex, i find your comment highly offensive. Are you claiming that Sweden is not
a democracy just because it's a monarcy? This is like a slap in the face on our
king Carl XVI Gustaf and the entire swedish monarchy. I expect an immidiate
appology or we will have an international incidnent on our hands.
Or is this another way that the germans are insulting our royal family. Last
time it was through "Woche der Frau" and this time it's through bugzilla.
/ Jonas Sicking, for democracy and proud to have a king!
Jonas: Bugzilla is no place for personal attacks. Please abstain yourself in the
future from making such comments, and don't relate in your posts the other
people's nationality and extrapolate based on that.
Alex: please read http://www.mozilla.org/mission.html , the "Benevolent
Dictator" section. In the future, please respect the development model that
Mozilla already selected (a module-owner/drivers driven process, not a
democratic one).
Discussion of governance is off topic; please end this thread now.
What we need is a qualified person to step up and offer to maintain
the MNG-related code in modules/libpr0n, which comprises less than
1000 lines.
I agree, being from the Goat Kingdom, I can tell you that a monarchy rocks! You
get to sniff female goat behinds without being hanged!
Now dictatorships, those suck.
And sicking was helping to find a new owner - he set straight that mozilla
doesn't care what government your country has. This allows the millions of
developers who come from monarchies to feel confident and not oppressed and thus
consider taking over MNG ownership!
Wait wait wait... I thought the Zillanians live in a dictatorship (bugzilla the
kaiser, new contributors the slave with no rights to change their own bug
reports) ... do Zillanians live in a monarchy, dictatorship, hampa-pampa-banana
repulic (like current germany and the US under King Bush II) or what? :))))
People, please this has nothing to do with the bug in question so please
refrain from posting that pointless drivel to the buglist.
Thank you.
Jonas: If a monarch decides against the will of the folk it is bad, nothing more
I wanted to say. And don't correlate the Top Level Domain of my address to my
origin, that's wrong.
Vlad: Have you read the "Benevolent Dictator"-section?
Aren't 613 votes - the highest number of votes for any "bug" in Bugzilla -
against the removal enough to say that tor is not doing a good job here?
If it's not a democratic process, why do we have to discuss here?
Alex: What? You're now blatantly critizing our form of goverment as well as
calling our monarch a dictator! Fear the wrath of the swedes, it will be
Ragnarok all over again.
So you're saying that you're not german? Please tell where you're from so that i
can properly direct my insults.
/ Jonas Sicking, Swedish and proud of it.
Re: comment 348
You are supposed to discuss things relative to the bug, such as an idea on how
to implement it or something an implementer might miss.
If you are willing to maintain the relevant code, volunteer yourself or find
someone who will. Module owners are not forbidding you from volunteering for this.
Please stop spamming this bug! There are 120 people subscribed to this bug.
Spamming the bug not only delivers useless messages to these people's mailboxes,
but also makes the bug very hard to read, because for each comment you have to
evaluate whether it's relevant discussion or irrelevant prattle. You have
already been chided once. Now please behave or i'll have to tell your respective
I would /really really/ appreciate if you guys took this to private messages or
even stopped this altogether.
Glenn: cannot any of you guys do that? Seeing that there was like three or four
of you who worked or are working on making the MNG/JNG library small enough,
can't any of you take up the maintenance of this bit of code? I myself am near
internet access most of the time (thus, too, available pretty often), and would
love to help, alas I lack enough programming knowledge (and AAMF Mozilla source
knowledge) to be of any help here.
> You are supposed to discuss things relative to the bug, such as an idea on how
> to implement it or something an implementer might miss.
A configureable option for MNG/JNG that is turned off in default is useless,
because this will prevent distribution of MNG/JNG in the wild.
"640 Kilobytes of computer memory ought to be enough for anybody." - Bill Gates,
"the formats [MNG/JNG] are little used in the wild [...] it's
worth considering removal" - tor, 2003
Re: recent comments
This bug has inspired me to file bug 225751 .
I'll post no more off-topic.
Okay. Re comment #270, is Pavlov acceptable for libpr0n mng code handling? Or
was he just volunteering to help reduce the size of the mng decoder used in mozilla?
In either case, what'd required for a maintainer? I have quite a bit of C and
C++ coding experience, whole projects, and additions to existing projects. I've
been doing it for about 10 years now. (Well, 5 years for c++) Does this make
me an acceptable maintainer? I'd really like to use MNG-required-for themes,
and I agree that there's little chance of MNG ever *becomming* highly used
unless Mozilla supports it first. I mean, hell, IE doesn't even have Tabs yet,
and pretty much everyone else does (incl. IE-plugins). Why can't this be yet
just one more thing mozilla did first, or at least early. And it's not like
mozilla's ever likely to be small, I can afford another 100K (or less according
to bug#204520) for a decent (ie, useful in the 24-bit world we now live in)
replacement for the current low capability of animated GIF's...
Anyway. I have all-day internet connectivity, and at least a few hours a week.
Let me know what's you guys (drivers) are looking for, and if it's just someone
to "own" the code, I volunteer to be initiated. (Why was Glenn refused? I
don't remember if it was said...)
I second Chris' nomination.
Now can someone request review for this patch?
Because of the intensive bugspam here, I'm removing my vote for this bug. Sorry
for adding to that bugspam, but I wanted to make the spammers aware that their
actions just decrease the chances that this bug ever gets fixed.
Anyone that was going to fix this bug, and then decided not to because of the
number of comments attached to it, would be acting childish. If they genuinely
preferred to act in that manner, perhaps they would better serve the public by
not participating in the project at all.
Mozilla is a great browser. Adding MNG and JNG support will only make it better.
MNG and JNG will not disappear. Once more people realize it's uses it will
become more mainstream.
Maybe someone has already suggested this, but I do not have time to go through
200 entries, so, I suggest that MNG support be skipped for alpha releases, maybe
beta releases, and the nightlies in between, but then added in for release
candidates and finals. If the only reason is space, it would help.
I also hate to spam this place, but I would also really like to use animations
and not pay $500 for Macromedia Flash, just to get a soccer ball to move.
But the idea is to reduce the size of the final product, isn't it?
Maybe in a few years the GIF support could be removed ;-)
Our GIF support library is orders of magnitude smaller than our MNG support
library. So that wouldn't help
A new tar distribution of Nova's mng restoration patch, the mng subdirectories,
and autoconf'ed "configure" file, is available in the DOWNLOAD area at
mngzilla.sf.net for restoring MNG capability to Mozilla-1.6.
For developers trying to do opensource web aplications:
Note that if you use gif animations on your app you can't use the savanah soft
development facility, because gif are forbbiden on this site.
1-dont do a mozilla compatible app
2-dont use savanah
3-use static images
As a follow-up to comment #355, I again ask drivers, or whoever else "makes the
decision(s)", what's needed here. At one point, my understanding was that you
needed someone to own and maintain the code. I volunteered to do that, but
noone has responded to me with a "yay" or "nay". Please let me/us know what is
needed, and if it's only a human to leash to it, I again volunteer.
I would like to be able to move forward on this, where "forward" means "MNG
support will soon be part of the base distribution again". Adding in patches
for my own use is fine, but doesn't solve the larger problem of people not using
MNG because there's so little support for them.
Thank you.
Just for the record:
http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c200 indicates that this will
not be a part of the "base distribution" per drivers, even if it is added into
the trunk.
It would be a good start to have it bach in the trunk CVS, and be able to try
different sub-profiles so that one of those might get into default build again.
You probably should directly mail firstname.lastname@example.com as you can't be sure
they're closely watching this bug report.
mconnor: Yes, I saw that, but it saddens me. I don't see a point in doing it
unless it's going to be in distributed builds. But, they do indicate that a
MNG-VLC support could make it back into the "standard" distributions. Most
people seem to believe that that would be of no significant use, but if we can
get drivers to allow MNG-LC, or even MNG after enough time goes by to overcome
their problems with it (since much work has already been done on reducing it's
footprint), then it's worth looking at.
(*sigh*) Okay. I'll email drivers and volunteer for taking over support, so
that it's at least "on-trunk". I presume that the status right now is that it
is not on-trunk? From the last "removal reversal patch" here, it looks like
it's put into a bunch of the build system stuff, but that the library itself
(libimgmng) there must already be code for. Or would it be more desireable to
move it into libimg, as seems to have been done for most other formats? That
would get the JPEG savings, et al, discussed here...
I guess it's up to discussion with drivers and/or imglib2 (a.k.a. "lipr0n")
owners if it should go into libimg or not.
Anyways, there's the libpr0n/mng glue code, and owner/maintanership of that
seems the big problem (and I guess that's what you're volunteering for), if
that's solved, I think all other things can be settled in a email and/or IRC
discussion of you, drivers, and libpr0n owner(s).
Now would also be a good time to go for that, as there's still some time until
1.7a, and that gives us all plenty of testing time until the next final ships :)
No, that wasn't what I'd intended to volunteer for. I presume that bug #204520,
comment #65 still serves as a statement that Pavlov is willing to accept that
glue code. It shouldn't be hard to maintain, and Pavlov is certainly qualified.
So, anyone else I should include in an email discussion other than drivers? Is
there a mailing list for libpr0n people, or should I just include Pavlov?
The glue code is the part that really _needs_ a new owner, Pavlov doesn't want
to have anything to do with it.
IIRC, Glenn said he'd be willing to own the libmng code itself. The real problem
_is_ the glue code.
this bug enabled developers to start a bottom up clean up of mozilla. i have
not been very impressed. i have been rude, but starting size standards with the
free stuff is very very revealing.
the same sort of revelations lead me to believe much much more in the promise
that i see with gtkhtml3 and the, well, for lack of a better word, sweet
developers there.
by the way, did you see the scene in the pirate movie where the one savvy pirate
was riding the sinking ship into the bay and stepped on the pier. i guess this
would be andersca. that was at the beginning of a good movie written by a
corporation. this has been a very very bad one. more like "i love you to
death" which was great and funny yet sad. i like movies that are funny and
funnier. you need free and good software for that. i guess good and free
hardware also, as this is all i can afford. losers.
it is not that i am calling mozilla losers, not in the slightest. Even if the
hippest of the coders got the hell out when they smelled it happening.
for shame, all of you that started to diet with the free stuff. given a chance,
i would like to discuss it with your moms.
also, thank you for the best browser available. a corporation should not start
with the free stuff to diet. simply. did you read the same stuff about growing
up right that i did?
at the same time, i use Mozilla as a WYSIWYG and it is a little too forgiving.
is there a bug about that?
Created attachment 140905 [details]
Full MNG (1.0.5) patch (trunk) bzip2
This is the full patch. The missing files are included in this patch, it is
against trunk (after landing SVG).
MNG doesn't compile by default with this patch, you need:
to build MNG in your patched tree.
Can I assign this bug to me?
I would Maintain the MNG clue code, I will have it back in trunk without
enabled by default. What must I do?
Sure, take it. Glenn
A Free program (for windows) called SlowView, will view, make, and batch convert
MNG images.
it is at RC2 right now (and has been for months)
for anyone interested in a really good MNG maker program.
it is not opensource, but it is freeware.
it is less than a megabyte (not including required software
(In reply to comment #376)
> A Free program (for windows) called SlowView, will view, make, and batch convert
> MNG images.
How is this relevant? Don't spam bug reports.
Alexander, maybe you should ask Pavlov for review/superreview/approval of your
I think that the best thing would be to contact him personally and to make sure
that you are heading in the right direction.
Maybe this could be a feature that can be enabled/disabled in the installer
(like Domi and Venkman can already be switched on/off in the Firefox windows
or as you are already aiming at, make it an optional compile switch.
In any way, either contact Pavlov personally (I am not sure if he is still
looking at this spammed "thread") or set the review flag for your patch.
TNX for offering to maintain the glue code.
Thanks, Alexander. The patch id=140905 wfm on FreeBSD 5.0
Be sure to use the "-p0" patch option, and remember to run autoconf
Sorry for the spam, but:
I keep getting mails on this bug (which is fine) containing all changes since
Feb 08 (which is not). Does anyone else experience this?
It only happens with this bug.
(In reply to comment #380)
> Sorry for the spam, but:
> I keep getting mails on this bug (which is fine) containing all changes since
> Feb 08 (which is not). Does anyone else experience this?
> It only happens with this bug.
> Stefan
same here
Hate to do this, but, well: "Me too." (re: two above comments)
Sorry for the spam:
Per comment 380 and further: this is bugzilla bug 234159. Please file further
comments on repeated text in bugmail in that bug.
Comment on attachment 134552 [details] [diff] [review]
Updated removal reversal patch (mozilla-1.6)
Removed "obsolete" flag because this patch is still good for updating
Created attachment 141710 [details]
Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
This patch replaces opi's recent "Full MNG" patch. It brings the libmng
files up to the current libmng CVS (version 1.0.6+), and makes it possible
to configure mozilla without libpng, thus using libmng to provide PNG support.
This patch is to be used with the current Mozilla trunk.
Comment on attachment 141710 [details]
Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
corrected MIME type
Comment on attachment 141710 [details]
Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
Corrected MIME type, removed patch tag, so that the file is handled properly.
P.S. I'd rather see it as a regular diff.
Comment on attachment 141710 [details]
Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
Changed MIME Type
Comment on attachment 141710 [details]
Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
Corrected MIME type again (Robert broke my previous change :-( ), removed patch
tag, so that the file is handled properly.
Strange. Bugzilla should have given me a collision notice. But I didn't get
anything. Also put the wrong mimetype by accident. To bed with me. Sleepy a must.
(In reply to comment #390)
> Strange. Bugzilla should have given me a collision notice. But I didn't get
> anything. Also put the wrong mimetype by accident. To bed with me. Sleepy a
It is strange... Nor did I got a message that I changed the attributes. Don't
worry about yourself --- you probably put some reasonable MIME type, but you
surely did left the patch tag, which caused the type to be changed back to
text/plain. See the bug activity on this bug for details on the full picture.
Created attachment 142326 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
The latest and greatest Patch for MNG
This patch replaces glenn's recent "Full MNG" patch.
+ updates against cvs trunk
+ bugfix of bug #121927
Configure the MNGBUILD (at the moment it compiles MNG_BUILD_FULL_MNG (or
_RAW_MNG don't know yet) but MNG_BUILD_MOZ_MNG should be enough ... drivers
requested MNG_BUILD_VLC
Drivers withdrew the request for MNG_BUILD_VLC (see comment #257). Instead,
a minimal useful build is MNG_BUILD_WEB_NO_JNG. If you build this, without
"png" in the decoders list so that libmng handles png decoding, the library size
increase is about 70k.
Created attachment 142804 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
This patch is untested ... excuse that I hadn't the time yet. But I hope it
works well.
Define MNG_TYPE with
Default is MNG_BUILD_WEB_NO_JNG
Update to latest libmng CVS
Wait for libmng 1.0.8 (should be around 1.7 freeze) to go into 1.8a
Alexander, why don't you ask someone to review the patch?
Cause I must test it for my self (and maybe Glenn also test the patches before),
then I have points on my todo list and then I must speak with tor/stuart before
it have sense to ask for reviewing it.
And I don't want to spam the libimg/libpr0n developers ... they are not very
happy with such thinks.
Patch #142804 works fine and builds a MNG/JNG-enabled mozilla, when applied to
a fresh checkout from this morning's trunk of cvs. However, the build-type
seems to have no effect, and MNG_BUILD_FULL_MNG is always built. There is an
extra space at the end of line 75393 of the patch, but removing it doesn't help.
Created attachment 142953 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
+ Updated all libmng files to latest in CVS
+ Fixed --enable-mng-type so that it work
- Waiting for libmng 1.0.7 (and not 1.0.8 as I'd sayd it last time)
Has anyone talked with drivers if they are actually interested in full MNG
turned back on. I know they approved VLC when it was throught to be a gif
replacement, but the fact that it isn't doesn't mean that ful MNG is
automatically approved AFAIK.
Also, has the two reasons that MNG was backed out been addressed? I.e. lack of
ownership (gluecode as well as libmng) and the fact that MNG in mozilla had some
bugs (crashes and wrong notifications sent IIRC). In order to take ownership of
a module in mozilla quite a lot of mozilla experience is usually requested, so
you might want to clear any proposed owner with drivers if you want it turned on
by default.
Thirdly, i've read recent comments about using libmng to decode PNG images. I
didn't think that was an option given that it couldn't do progressive rendering,
hadn't gotten as much testing as libpng among other things.
I'm not against including MNG support in mozilla at all, quite the opposite.
However I'd hate to see a lot of effort being wasted before the correct issues
has been addressed.
Also, i'm not a driver, so don't talk with me about any concerns you have, I
can't do anything that the next guy can't.
Nor is this bug the appropriate forum for discussing these things. I'm sure that
everyone involved knows who to talk about these things with, and where to do that.
Patch #142953 needs a slight correction. We are not using libmng_conf.h
exactly as found in CVS. Change
#ifdef MNG_MOZILLA_CFG
#include "special\mozcfg\mozlibmngconf.h"
#include "mozlibmngconf.h"
Once this change was made, it worked for me and I was able to build
MNG_BUILD_MOZ_MNG and MNG_BUILD_WEB_NO_JNG and other configurations.
> Has anyone talked with drivers if they are actually interested in full MNG
> turned back on. I know they approved VLC when it was throught to be a gif
> replacement, but the fact that it isn't doesn't mean that ful MNG is
> automatically approved AFAIK.
Drivers said we could put full MNG back in as a configurable, default OFF. That
was nearly 7 months ago (see comment #200). There was also unresolved
discussion about putting some subset of MNG in, default ON. MNG-VLC isn't
capable enough, and the minimal MNG_WEB_NO_JNG is probably too big. The only
thing preventing putting full MNG on the trunk, default OFF, right now, is the
lack of an acceptable volunteer.
Created attachment 142993 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
There was a little data corruption on my harddrive so that my last patch missed
2 updated files :-(
+ update libmng_conf.h and MOZCHANGES in the diff to my tree
@sicking What bugs do you mean? The latest for ma known crasher bug is resolved
in this patch (As resolved in libmng 1.0.6) ... also the looping bug is
resolved in our glue code. So I've nothing outstanding as far as I see.
A few problems with the decoder, off the top of my head:
* doesn't fire OnStop{Decode,Container,Frame}
* you might want to see if necko now has the features that would let
you decode without buffering the whole stream
* decoder will crash if it runs of memory in said buffering (along
with a number of other unchecked allocations)
Re: comment #402
> * doesn't fire OnStop{Decode,Container,Frame}
> * you might want to see if necko now has the features that would let
> you decode without buffering the whole stream
Both of these seem to relate to bug #177670 which is a request to implement
the "Dynamic MNG" feature, which is a private extension to the MNG spec.
> * decoder will crash if it runs of memory in said buffering (along
> with a number of other unchecked allocations)
Is there a bug report on this?
Re: comment #399
> i've read recent comments about using libmng to decode PNG images. I
> didn't think that was an option given that it couldn't do progressive
> rendering, hadn't gotten as much testing as libpng among other things.
The current patch allows people to configure this way so we can get some
testing. The normal configuration would be with the regular png decoder
decoding PNG. I believe the mng decoder will decode PNGs correctly, but
I doubt that it will be able to do it as fast because of extra stuff
it must do. There's no need to speculate; people can configure both ways
and run timings.
(In reply to comment #403)
> Re: comment #402
> > * doesn't fire OnStop{Decode,Container,Frame}
> >
> > * you might want to see if necko now has the features that would let
> > you decode without buffering the whole stream
> Both of these seem to relate to bug #177670 which is a request to implement
> the "Dynamic MNG" feature, which is a private extension to the MNG spec.
No - the first means that JNGs and MNGs won't work as background images.
The second causes the MNG decoder to waste a lot of memory.
> > * decoder will crash if it runs of memory in said buffering (along
> > with a number of other unchecked allocations)
> Is there a bug report on this?
Created attachment 143562 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
+ Update to latest libmng CVS (removing another thing to lower code size)
+ Using Stop*, so mng also works on Backgrounds/CSS
+ remove the extra buffer
+ fixings from biesi's mail
- some lines have out commented code ... should be removed later
- starts displaying after all data is catched caused by the buffer changes ...
maybe should changed again, if this patch work's correct.
I hope I've all suggestions in this patch. If someone had more input, what
needs to be done, he is greatly welcome.
Glenn: What do we save if we remove the open_stream and close_stream callbacks?
Patch id #143562 has a left-over instance of modules/libpr0n/build/_img_list
so you will need to type "y" to allow patch to skip it. Otherwise it
sucessfully updates mozilla, freshly downloaded from CVS.
>Glenn: What do we save if we remove the open_stream and close_stream callbacks?
About 500 bytes. I'll check that change in to libmng CVS shortly.
Created attachment 144555 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
New Version:
+ update to latest libmng cvs.
+ start playing mng while loading
+ resolve problem when StartAnimation is called before loading is done
TODO: Clean up some makefile.in's etc.
Comment on attachment 144555 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
Patch #144555 works for me. r/sr?
Comment on attachment 144555 [details]
Full MNG (1.0.6+) patch (trunk) bzip2
A couple things:
* StopAnimation should probably cancel the timer before resetting
the handle (btw, perhaps that should be using freeze/resume?).
* Still a large number of unchecked allocations.
* Comment in imgContainerMNG.h about buffering the whole stream
can be removed and/or updated to reflect the current code.
* Should not be registering image/x-mng.
* Shouldn't be modifying the accept header (which shouldn't contain
image/png either, but that's another bug).
* Change to png mimetype in content sniffer shouldn't be necessary.
* Still a large number of unchecked allocations.
Note that the MNG_ALLOC macro has an internal check. Only MNG_ALLOCX needs
a subsequent check. I find two instances of MNG_ALLOCX in libmng that
should be MNG_ALLOC, and we will fix those. They aren't active in moz
anyhow because they are for decoding compressed text.
I was referring to allocations in the glue code, not in libmng.
Hello World,
I know you all want MNG back into tree of mozilla.
But please ... if you are not drivers, asa, tor or me ... DO NOT CHANGE flags of
patches, blockings and else.
This helps nobody ... aggresivity don't help us.
While the last time I had problems with my debian installation and gcc 3.4 (it
crashed randomly) I'm again back to gcc 3.3.3 ... but there was a code change in
the networking part that stops us at the moment from havin a workin libmng
inside mozilla.
No, it isn't a bug in mozilla, it is a fact of design. The mozilla code was
cleaned or corrected to work how the design it want, but that breaks us.
The other tasks from tor are mostly resolved.
Christian Biesinger have build a new linux mng.xpi and provide it on his page
(it works with mozilla 1.6 but seems to be breaked in trunk builds). It have
libmng 1.0.8a. This resolves crashers with libmng and the images that are
generated from the new software of the blinkenlights project.
Bad is, that 1.7 is declared as the new stable branch. Maybe Netscape 7.2 will
depend on this and so will also miss the libmng plugin cause we won't have all
working until 1.7 is ready.
So, assuming that 1.7 is released before libmng can be repaired to fit the new
design, once libmng is repaired, would it be possible for someone to compile 1.7
with the fixed libmig and post Mingzilla 1.7 for Windows, Linux, and OSX
somewhere so some of us can use and test it?
Created attachment 146226 [details]
Full MNG (1.0.8a) patch (trunk) bzip2
New patch using libmng 1.0.8a and the new libmng pushdata functions, so the mng
glue code now is compatible to the mozilla API.
And that's all of changes in this release of the patch set. All other thinks of
code cleaning and repair tor's buglist for mng are left out for the next days.
Greetings Alex//
http://www.blinkenlights.de/torus-mng.en.html is a very nice sample animation.
(With older libmng versions your browser will crash).
Created attachment 146839 [details]
Full MNG (1.0.8a) patch (trunk) bzip2
> * StopAnimation should probably cancel the timer before resetting
> the handle (btw, perhaps that should be using freeze/resume?).
> * Still a large number of unchecked allocations.
> * Comment in imgContainerMNG.h about buffering the whole stream
> can be removed and/or updated to reflect the current code.
> * Should not be registering image/x-mng.
> * Shouldn't be modifying the accept header (which shouldn't contain
> image/png either, but that's another bug).
left until image/png isn't there any more (And I think a bit other about accept
headers, but that's an other problem)
> * Change to png mimetype in content sniffer shouldn't be necessary.
Alexander, if you think that this patch revision (1.0.8a) fixes tor's issues and
should make it into the trunk, you will have to ask for r/sr again.
Just a question from someone watching this bug...why shouldn't mng be registered
as image/x-mng?
I'm waiting for libmng 1.0.8, one thing from tor was left, I must speak with tor
before and Glenn's report "it works" is outstanding.
MNG will be registered (in a unknown future *gg*) as video/mng and so it is at
the moment registered as video/x-mng ... why it isn't registered as image/mng I
don't know. So we have image/x-jng and video/x-mng yet.
Greetings Alex//
re: accept-header issues, we removed jpeg and gif from the accept header since
pretty much every browser out there accepts them. the current subject of debate
is whether any content negotiation is being done with image types in the wild
(not in theory). tor's thought (and it has validity) is that keeping image/png
is equally bloating the accept header. Therefore adding image/x-mng etc is also
useless from that perspective. But, that's a relatively minor side issue that
we really need to hash out for png too, so it deserves a side bug.
(In reply to comment #410)
> * Shouldn't be modifying the accept header (which shouldn't contain
> image/png either, but that's another bug).
Would you mind to explain why the Accept header should not be changed? How would
Apache otherwise know that we can display PNG or MNG?
> tor's thought (and it has validity) is that keeping image/png
> is equally bloating the accept header. Therefore adding image/x-mng etc is also
> useless from that perspective.
That logic doesn't work. "Everyone accepts GIF and JPEG, so putting them in the
Accept: header is bloat. Only a few browsers accept MNG, so putting it in the
Accept: header is bloat." Huh? :-)
If MNG goes back in, it should be added back to the Accept header, until and
unless every other browser has been supporting it for about five years (which is
how long we've all had PNG support.)
Created attachment 147094 [details]
Full MNG (1.0.8a) patch (trunk) bzip2
> * Change to png mimetype in content sniffer shouldn't be necessary.
Also removed a crasher in StopAnimation (excuse there was a ! to much).
Now the patch should be up to date and only libmng 1.0.8 seems to be
Re: patch id#1470948 -- it works for me (FreeBSD 5.0, gcc 3.2.1).
Patching from this afternoon's CVS 1.8a distribution is flawless,
but when patching the 1.7rc1 distribution, the patch fails to update
modules/libpref/src/init/all.js (but this can probably be ignored, or
you can just update manually from all.js.rej which is an easy one-liner).
Either way it display's MNG, JNG, and PNG satisfactorily.
tor: this patch seems to address all of the concerns you have expressed.
Do you have more?
Some source things:
* MOZMNG in configure.in should be bumped
* remove dependentLibs.h
* remove whitespace change in png content sniffer
* image/x-jng is being sniffed/registered even if libmng is built
without JNG support (the default configuration in this patch)
How big is the resulting libimgmng.so these days?
Isn't there also still an issue with which code to use for PNG files? If this
patch makes us use libmng to decode PNG files isn't there a big risk of
regiressions for PNG rendering seing how much time and testing has gone into the
current libpng code. Of course this is a moot point if this patch lets us still
use the current libpng for PNG files.
Is there any way that libmng could use the current libpng? If not, could libpng
be modified so that would be possible?
As I read it, the patch will only use libmng to decode PNGs if the
png decoder is disabled at configure time. We definitely want to
keep using libpng for PNG files.
The png files will only decoded by libmng if you define this in your
configuration, else png decoding is done by the libpng.
I think there will be less regression with change of decoding png from libpng to
libmng ... it's the same circle of programmer(s) who do the libs.
Ok, will do the missing things (some of them are already fixed in my tree today)
I compile with MNG_BUILD_MOZ_MNG and have
libimgmng.so 186512
libimglib2.so 178856
tor asked: How big is the resulting libimgmng.so these days?
On the FreeBSD5.0/gcc3.2.1 platform, MNG_BUILD_WEB_NO_JNG configuration,
ac_add_options --enable-image-decoders=mng,gif,jpeg,bmp,xbm (i.e.,
libmng providing standalone PNG support, reduced MNG support -- no Delta_PNG)
size libimgmng.so is 109930 bytes and size libimglib2.so is 154234 bytes.
MNG_BUILD_MOZ_NO_JNG configuration, same decoder set, libmng providing
standalone PNG support and full MNG support, no JNG support
size libimgmng.so is 129815 bytes and size libimglib2.so is 154234 bytes.
MNG_BUILD_MOZ_MNG configuration, with png in the decoder set, (libpng
providing standalone PNG support)
size libimgmng.so is 200664 bytes and size libimglib2 is 201063 bytes.
Other configurations are supported but are less interesting.
Isn't the most interesting configuration what could go into a default build?
I.e. having libpng enabled and having as small libmng as possible (while still
keeping it usefull).
Does opi's patch work well for everybody? I did some tests on OS/2 and found
that is causes Mozilla from the 1.7 branch to crash when trying to display two
specific MNG/JNG files: I built Mozilla with
ac_add_options --enable-crypto
ac_add_options --disable-debug
ac_add_options --with-extensions=default,irc,inspector
ac_add_options --disable-mailnews
and with and without
ac_add_options --enable-optimize=-O2
started it and drag-drop-loaded a few image files, including my three MNG/JNG
Animation1.mng (MNG animation testcase, the 4th attachment of this bug)
pnglogo-grr-anim-lc.mng (from libmng webpage)
sasaki.jng (little girl with cat on her head, probably from libmng page)
The effects are these:
- "normal" graphic files like PNG, BMP, JPEG are all loaded normally
- Without activating MNG/JNG (only the above options) many browser windows are
opened when loading one of the above testcases
- when adding
ac_add_options --enable-image-decoders=default,mng
nothing is displayed for sasaki.jng (as expected) but pnglogo-grr-anim-lc.mng
crashes the browser every time, while Animation1.mpg crashes the browser when
compiled with -O2, and is displayed but not animated without optimization
- when using both
ac_add_options --enable-image-decoders=default,mng
ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG
sasaki.jng also crashes the browser every time
- With a patch I used to build my Mozilla 1.6 (made from attachment 134552 [details] [diff] [review] dated
2003-10-30 and the libmng 1.0.6 sources) and the MNG_BUILD_FULL_MNG setting
everything displays OK, no crashes occur, and Animation1.mng is indeed animated
So, is this an OS/2-only problem or does someone observe this on other
platforms, too?
tor says: * MOZMNG in configure.in should be bumped
Yes, to MOZMNG="((1<<16)|(0<<8)|(8))"
MOZPNG should also be bumped, to 10205. You want to do
that change separately?
Peter W says: These crash on OS/2:
Animation1.mng (MNG animation testcase, the 4th attachment of this bug)
pnglogo-grr-anim-lc.mng (from libmng webpage)
sasaki.jng (little girl with cat on her head, probably from libmng page)
The first two look fine on my FreeBSD5.0/gcc3.2.1 platform.
pnglogo-grr-anim-lc.mng can be found at www.libmng.com/pub/mng/mngpics.html
at the top of the page.
I think sasaki.jng was someone's avatar on mozillazine forums, now long gone.
Sorry for the spam,
but does anyone have any build available for WinXp/Linux (Fedora) with different
build options some of us could test out to make sure everything is working
correctly and help find bugs?
Both Suite and Firefox builds would be nice, I'm willing to do as much testing
as needed.
Again, sorry for the extra spam if this is not an appropriate request.
sakaki.jng was my avatar, it was removed from my profile because it crashed
Mozilla. Perhaps this bug is relevant:
It's a legit JNG, no special code as far as I know.
sakaki.jng contains an extraneous CRLF after the IEND chunk. It may display in
some JNG decoders but not in others. The data-streaming inside libmng and the
gluecode has changed, and it's probably complaining now about the extra bytes.
Can you fix that problem for libmng 1.0.8? Cause no input, correct or not,
shouldn't crash.
Also http://www.libmng.com/MNGsuite/images/MNGPAST16a.mng is outstanding, it is
pushed in one with 711 byte (or what I'd wrote in my mail).
I hope I get Windows Builds in the near future, all builds can be found on
(Oh, it seems there is a Windows Firefox/MngFox build present)
Actually, I found the first part of the problems I reported in comment 432, on a
build I just made from the 1.7 branch on Linux. Drag-drop-opening of any MNG/JNG
file from nautilus onto the browser window results in many windows opening
without MNG/JNG activated. Only help seems to be Ctrl-Q... I guess this is a
problem of the glue code.
@Ashi (comment 436): I doubt that the same compiler problem of MS VC (from of
bug 196670) is also present in gcc-3.2.2 on OS/2 with and without optimization.
But until now I did not manage to get a debugger working on OS/2 and have too
little knowledge of compilers, so I cannot be sure.
Actually, sasaki.jng is attachment 130784 [details] of this bug.
Is it possible to move the discussion on the details of opi's patches into a new
bug or into some newsgroup (don't know which one)? This bug gets so awfully
long, CCs too many people, and I find it really hard to handle at home over
analog modem.
opi says: (Oh, it seems there is a Windows Firefox/MngFox build present)
That was built with Jason Summers' libmng-1.0.6 plugin, not your latest
Additional tests under Linux, now built with
ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG
ac_add_options --enable-image-decoders=default,mng
As under OS/2 Animation1.mng is displayed (the AOL text) but not animated, when
loaded locally (URL file:/<path>/Animation1.mng). When loaded from the URL of
attachment 124879 [details], the animation is shown. pnglogo-grr-anim-lc.mng or the other
hand shows the animation, when loaded from a file: URL and from a server.
The crashed I noticed before are therefore OS/2 specific. I hope to be able to
figure out soon how to properly debug this.
Additionally, I found that loading MNGs from an FTP server does not work.
Mozilla asks for a viewer or to save the file. For PNGs on the same server it
works. I tested this at <ftp://swrinde.nde.swri.edu/pub/mng/images/> and
FTP URLs not working is probably because the tables in
uriloader/exthandler/nsExternalHelperAppService.cpp haven't
been modified.
(In reply to comment #442)
> FTP URLs not working is probably because the tables in
> uriloader/exthandler/nsExternalHelperAppService.cpp haven't
> been modified.
instead of doing that, a category entry for "ext-to-type-mapping", name "mng",
value "video/x-mng" (or what the type is), should be added.
Some others and I can't get this patch to apply. I tried doing:
patch < /patch/mozilla-mng-patch-040427.diff
patch -p 22 < /patch/mozilla-mng-patch-040427.diff
Then I tried:
sed 's/\/mnt\/mozilla_compile/\./g' /patch/mozilla-mng-patch-040427.diff > diff.txt
patch < diff.txt
I tried it in both the ./mozilla directory and the ./mozilla/.. directory. From
the ./mozilla directory, some chunks applied, but not all.
We don't have /mnt/compile_mozilla and even when I tried a symlink to my real
mozilla directory it didn't work.
In all cases, it asks for a filename to use for some|all of the files.
For information how to use the patch please take a look at
(In reply to comment #444)
> patch < /patch/mozilla-mng-patch-040427.diff
> patch -p 22 < /patch/mozilla-mng-patch-040427.diff
please read "man patch". you want -p1, and apply it inside the mozilla/
directory. or use -p0 and apply it above the mozilla directory.
sorry, that should be -p2 instead of -p1.
Created attachment 147577 [details]
MNG (1.0.8a) patch (trunk) bzip2
* MOZMNG in configure.in should be bumped
* remove dependentLibs.h
* remove whitespace change in png content sniffer
* image/x-jng is being sniffed/registered even if libmng is built
without JNG support (the default configuration in this patch)
@Peter Weilbacher
* loading MNGs from an FTP server does not work
done as biesi it wants
* OS/2 crashers
can't help without stack traces
Please try also to add the option
ac_add_options --without-system-mng
Another problems:
If you use the xpi and go to sites that have mng's in an <img> Tag, but the
imges are send back from server with mime-type text/plain won't displayed.
This is a buggi workaround for stupid admins, won't fixed here, cause it isn't
a mng problem.
Hint: Tell the webadmin, he should add the correct mime-types to his server.
If you wan't open directly a mng and the server send's mime-type text/plain
then mozilla opens a "what to do" Dialog but tells the user the correct mime
type "video/x-mng". Buggie workaround for stupid admins. Fix is in way.
Hint: See above.
Why the MNGZilla builds show application/octet-stream on this issue and not
"video/x-mng" will be ironed with out at the moment with bz.
Patch #1475778 works for me (FreeBSD 5.0/gcc 3.2.1), when applied to the
mozilla-1.7rc1 distribution. As before I had to patch one line of all.js
(In reply to comment #448)
> * OS/2 crashers
> can't help without stack traces
I can't produce a gdb-like backtrace, but it is crashing in libmng code not the
glue code. When I try to load sasaki.jng or pnglogo-grr-anim-lc.mng it crashes
at line 690 in libmng_display.c because pData->fDisplayrow is undefined (NULL).
Didn't yet find out why that is and why it works on Linux. When displaying
Animation1.mng the pointer is correctly initialized and that line calls
mng_display_rgb8_a8(pData) at libmng_pixels.c:1378.
> Please try also to add the option
> ac_add_options --without-system-mng
It is using the libmng code contained in your patch as I confirmed in the
debugging session.
The special case for OS2 and other platforms is inconsistent with the glue
code which uses the same canvas types for all platforms.
In modules/libimg/mng/mozlibmngconf.h, change the following:
#if defined(XP_WIN) || defined(XP_OS2) || defined(XP_BEOS) || defined(MOZ_WIDGET
#define MNG_SKIPCANVAS_RGB8
#define MNG_SKIPCANVAS_RGBX8
#define MNG_SKIPCANVAS_BGR8
#define MNG_SKIPCANVAS_BGRX8
to simply:
#define MNG_SKIPCANVAS_BGR8
#define MNG_SKIPCANVAS_BGRX8
which happens to be what you get on Linux.
Created attachment 147886 [details]
MNG (1.0.8b) patch (trunk) bzip2
* OS/2 crashers (also win, if it crashed there)
done (updating to latest libmng cvs, where this was corrected)
* As under OS/2 Animation1.mng is displayed (the AOL text) but not animated,
loaded locally
It seems that local files are loaded syncron (remote files asyncron). The image
self isn't animated but its state depends on how much is loaded. Cause of
syncron load, the image is ready when it will displayed first.
If you try another animated mng, then you see, that it also animate after
* Why the MNGZilla builds show application/octet-stream on this issue and not
"video/x-mng" will be ironed out.
should be fixed on trunk
* If patch is applied but mng not compiled in, open a mng file directly causes
many windows opened.
Will look into this next time.
Does this also happens with BMP's?
I hope, I've all. New builds and xpi's on
http://www.sourceforge.net/projects/mngzilla will come next week for Linux AND
Windows(compiled with gcc so maybe slower then msvc builds).
Confirmed that 'pnglogo-grr-anim-lc.mng' now doesn't crash it. (I've been
secretly building with MNG in, and noticed that.)
Some JNG files still don't work, but it's never worked. It's quite possible I'm
missing something, or that support for pure JNGs hasn't been added yet. At
least, from my test page for image working-ness and for crashing. A bunch of
images taken from either my hard drive, or from the MNG/JNG testcase sites:
Have compiled Firefox (Aviary stable branch) with MNG (based on 2004-05-07 05:52
PDT patch) and SVG, and planning to compile Trunk sometime in near future. Will
probably optimize different versions, but currently I have publically posted a
generic Windows G6 build. Has some other customizations in it, but generally
stable. (Aviary is doing nicely.)
ac_add_options --enable-image-decoders=default,mng
ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG
Experiencing no crashes, and everything looks stable on the Windows end.
Sorry for bugspam, just announcing as to let more widespread testing on the
(updated) MNG code take place.
@Alexander Opitz:
I have been doing MNG builds for myself:
One is
http://pryan.org/mozilla/firefox/amano/Fx-2004-06-08-O1-Gopher-MNG-Exp.exe that
includes Jason Summer's mng plugin (as GlennRP reported, it is at 1.08a libmng
And the second one is
http://pryan.org/mozilla/firefox/amano/Fx-2004-05-12-O1-Gopher-MNG-Exp.exe with
mng support manually patched in (using your latest diff file).
When I surf to http://www.libmng.com/MNGsuite/dynamic_embed.html to test the
dynamic mng, the Jason Summer plugins works, but my modified build (the diff
file one) fails: Australia and the buttons are visible, but all mouseover
effects don't work.
How is that possible as both "implementations" are at libmng 1.08 state?
Bernd: Opi's patch, by default, is configured to build the
MNG_BUILD_WEB_NO_JNG variant, which does not include support for
dynamic MNG. To get dynamic MNG support you will need to add
"#define MNG_SUPPORT_DYNAMICMNG" to modules/libimg/mng/mozlibmngconf.h
Re comment #445: Also you need to remove the line #define MNG_SKIPCHUNK_evNT
from mozlibmngconf.h. I don't know if it will work or not; it may be
that some dynamic-MNG enabling has to be done in the glue code as well.
I am running a --enable-image-decoders=mng,gif,jpeg,bmp,xbm
--enable-mng-type=MNG_BUILD_FULL_MNG build since end of April under both OS/2
and Linux. Only today did I encounter PNGs in a "normal" webpage that do not
display correctly with the MNG decoder but do with the PNG decoder in the
official Mozilla.org/IBM builds. I guess that these problems are already known
to the libmng developers but now that I am adding to this bug I can list them
anyway in case they are just not contained in MNG_BUILD_FULL_MNG:
1. The first problems I found were at
http://www.bo.astro.it/report02/node44.html. In the MNG build the formulae
appear white on black and the plot does not have any content besides black
background. In the standard PNG build everything appears correctly (black,
background transparent).
2. So I went to check, and the "Illegal and/or corrupted PNG images" from
http://www.libpng.org/pub/png/pngsuite.html not only do not display but lead to
a few hundred screenfuls of empty space. In the standard PNG build they just
appear as normal cannot-display-icon.
3. There also is a webpage that describes all the errors browsers can make when
displaying (alpha) transparency of PNGs (but I lost the URL and spent 30 minutes
looking for it without success). The standard PNG build gets them all displayed
(nearly?) perfectly, while the build with MNG instead of PNG makes several errors.
I just realized that I still have to answer opi's question from comment 452:
> * If patch is applied but mng not compiled in, open a mng file
> directly causes many windows opened.
> Does this also happens with BMP's?
I haven't tried yet to compile the browser without BMP support, but with the
above .mozconfig arguments it does not. I will try to build without BMP and test
in the coming days.
Finally, I have made OS/2 builds with MNG and a new MNG XPI for OS/2 available
on http://weilbacher.org/Peter/mozilla.html, in case an OS/2 user reads this bug
but not the npm.os2 newsgroup. I guess it's time that I start using some JNG or
MNG on that page...
I just compiled Mozilla (1.7 branch) on Linux with
ac_add_options --enable-image-decoders=mng,gif,jpeg,xbm
ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG
(so without BMP support) and now I see the same problem with BMPs, too:
try to open a BMP and lots of new Mozilla browser windows open, the only way
around it to use Ctrl-Q.
Its a shame the only choice we have for animations are gifs... what the hell
are you guys doing ? that would have been my priority if i had sufficient
knowledge in programming..
Brice: Please read bug comments before making one yourself. As you can see by
the attachments at the top of the bug, this is being worked on. Therefore, your
comments are of no value. Please save such comments for
http://forums.mozillazine.org/ and don't litter bugs with them. This goes for
everyone else, too.
(In reply to comment #459)
> Its a shame ...
A comment such as "This bug should really be a blocker for Firefox 1.0" (if I
caught your drift) is more likely to be accepted than your comment. This
example comment is also likely more veridical than your comment.
(In reply to comment #461)
> A comment such as "This bug should really be a blocker for Firefox 1.0" (if I
> caught your drift) is more likely to be accepted than your comment. This
> example comment is also likely more veridical than your comment.
Good idea :) Requesting blocking-aviary1.0
I second the blocking 1.0
There is already a mature patch in the works
.gif is patented by unisys, and .mng would be a good replacement for .gif (and
its even better than .gif). Also, this being released in a 1.0 version would
make people notice it more and put the pressure on other browser makers.
The GIF patents expired last year in the USA. The patents in Japan and Europe
have expired in the past couple of weeks, and I believe the patent in Canada has
about 10 days left. So patents aren't much of an issue any more...
(In reply to comment #464)
> [...] patents aren't much of an issue any more...
but, (for webdesigners, anyway) alpha transparency *is*
The code is to much experimentel to add it to the aviary branch.
There will be xpi's to install mng support.
We also will try to make MngFox/MngZilla on the known sourceforge page.
Please respect the first lines out of comment #413 and don't change blockers and
such thinks.
(In reply to comment #464)
> The GIF patents expired last year in the USA. The patents in Japan and Europe
> have expired in the past couple of weeks, and I believe the patent in Canada has
> about 10 days left. So patents aren't much of an issue any more...
Unisys' patent has expired, but IBM's patent is still valid.
So patents are still an issue (even if the technical advantages of MNG are
enought to choice them instead of GIF)
(In reply to comment #467)
> Unisys' patent has expired, but IBM's patent is still valid.
The article "Why There Are No GIF files on GNU Web Pages" supports your claim:
"... the latest expiration date seems to be Friday 11 August 2006"
I hate to contribute to the bugspam, but I think it's worth noting that IBM has
never tried to enforce its patent, probably because it would likely be found to
be invalid, since it covers exactly the same "invention" as the Unisys patent.
See, for instance, http://www.kyz.uklinux.net/giflzw.
As a basic user, i can't understand why you wonder about GIF patents. MNG is
simply better... So just implements it ! , or remove the PNG support too,
arguing that GIF can replace it and IE doesn't support PNG well !
Found the webpage again that I was referring to in comment #457:
When the MNG decoder is used for PNGs, Mozilla displays the "RGB binary
transparency" and "Grayscale binary transparency" examples with a black background.
Removing .png support, ignoring technical reasons, would be unfair to those who
have put work into making quality .png support in the browser. I also don't see
what we'd gain by dropping .png and we'd lose a lot since some skins and
websites use .png. Also, the .png code is not really that much of the code of
Mozilla since the image library abstracts a lot of the functionality shared
between all image decoders.
Also, from what I've heard, there are CSS tricks to get alpha transparency to
work properly for IE in .png images if people have DirectX installed, which is
nearly everyone. These kind of CSS hacks are becoming more popular to fix IE
bugs on Websites, can be commented out using conditional comments, and are often
even given away as scripts for your website (such as IE7 on sourceforge -- which
doesn't yet afaik handle the .png transparency issue).
(In reply to comments #470 and #472)
I realise the suggestion to remove PNG support is somewhat tongue-in-cheek, but
the reasons not to do so make me cringe.
Not many sites support style sheets or JavaScript properly either, and IE does
it differently, so why not also suggest that these either conform or be removed
altogether? The answer, like the rest of the Mozilla code base, has a lot to do
with doing the right thing and getting it right. A lot of work has gone towards
making Mozilla support these these advances in technology, and at the same time,
because of the ubiquitous and transparent nature of the browser, Mozilla is
something of a flagship for them. The mozilla.org code base has had exceptional
support for CSS, DOM, JavaScript, XML and (yes!) PNG from the very beginning,
and these specifications are only now coming into prominence in the mainstream,
because developers are starting to understand that there's a right way and a
wrong way to do things. Had browsers other than Internet Explorer not bothered
to support these things back then - some six years ago - their importance would
have been lost forever, drowned in a sea of Web pages using IE's busted
Melodrama aside, that is why I voted for this bug, why I'm not surprised this
bug has 701 other votes, why I agree that MNG/JNG support must absolutely be
installed by default, and why I agree that it should block the aviary. (I'll
save the similar argument for Scalable Vector Graphics - SVG themes, anyone? -
for a more relevant time and place.)
reasons why this isn't going to block aviary 1.0 (again, posting to prevent more
advocacy posting. If you want to debate this with me, feel free to email)
a) the code isn't ready, per the owner of the bug and the person responsible for
getting things to a point where it can be added back into CVS. We're on way too
short of a timeline to take major last minute code.
b) no one working on Firefox/Thunderbird really wants this at this point
(speaking as one of the people heavily involved in Firefox). Thunderbird
stopped building with MNG before CVS removal took place. Firebird was probably
going to do the same, but CVS removal came first. Its not something that'll
likely change going forward, unless MNG support is really low cost (i.e. not
200-300k). At 50-80k the case becomes stronger, of course. The "if you support
it, they will come" argument is weak, since we did support this for three years
and the content didn't come.
c) Content that 90% of the web doesn't support isn't going to get created in any
substantive way. MNG has the advantage of being more ideologically pure than
Flash etc, but if people aren't using it, its cruft, and that's the reality.
Given the choice, we'd be much better off bundling Flash with Firefox based on
the "size vs. usability boost" equation. I realize lots of people don't like
Flash for a myriad of reasons, but users don't care.
the point is : we need Mozilla to implement and promote MNG to be able to use it
"noone" used it because IE didn"t implement it. it's simply that. nothing else
but it's also the case with alpha-transparency png and thanks to mozilla and others we are able to use
for mng, we need the same thing, and mozilla CAN support it and KEEP it
it's not 3 years we need, it's 5 or 10 . it will become useful ONLY when mozilla (or others browser with
mng support) will be strong enough to interest developpers. in the meantime, mozilla as to do the
same thing it do with png or xbl or others stuff : support it . to prepare the future (in _years_ , many
animated gif is not enough
flash is not enough
we need animated format with alpha and 24b support (and no, flash is not enough, flash is an other
problem ,and it's good mozilla has plugin for it but it's proprietary and never mozilla will be allowed to
incorporate native flash support)
mozilla foundation should be more thorough and truly support SVG and MNG. we don't need simply a
good webbrowser , we need a better WEB and mozilla is the only browser project which can listen web
designer and developpers.
Please stop arguing for or against the inclusion, it doesn't help either way.
And DO NOT request any blocking flags or considering that, as you only upset people.
opi and Glenn are working on getting libmng and the glue code working well
enough to go into CVS trunk again, but disabled by default for now.
Any other steps, as inclusion of any profile into any builds is up to discussion
on a second step, I'd say. We should just get something working back into CVS
again for now, and consider this first step fixed. There's a "yes" from driver
to support of a certain extent in default builds, but I'd believe that a second
Please STOP SPAMMING THIS BUG REPORT with anything that does not help in the
process of achieving that first step.
I'd just like to point out the ridiculousness of Mr. Conner's comment about
bundling Flash being more important that MNG support. The difference between
Flash and MNG in this context is that you can easily install the Flash plug-in;
I've done it (in other users' profiles, of course).
But it doesn't surprise me that the Firefox developers don't want it. They'd
probably yank out XML, CSS and JS support if not for those languages being used
by the theming system.
Of course the obvious solution is to re-add the code and just not compile the
birds with it. Since Seamonkey users prefer features over smallness, this would
seem to please both camps.
Is this a bug report or a Slashdot story?
Many of the comments I'm seeing here belong on the later rather than the former.
The fact is MNG support was pulled because because of the cost/benifit ratio,
not some dark plot in favor of animated Gifs. Sugestions on reducing the
footprint of MNG support are the way to get it back into the products, not wild
accusations and demands that something of intrest to a tiny minority be included
regardless of it's effects on footprint.
(Sorry for adding to the Spamload)
(In reply to comment #474)
> b) no one working on Firefox/Thunderbird really wants this at this point
> (speaking as one of the people heavily involved in Firefox). Thunderbird
> stopped building with MNG before CVS removal took place. Firebird was probably
> going to do the same, but CVS removal came first. Its not something that'll
> likely change going forward, unless MNG support is really low cost (i.e. not
> 200-300k). At 50-80k the case becomes stronger, of course. The "if you support
> it, they will come" argument is weak, since we did support this for three years
> and the content didn't come.
I think (or at least hope) that Firefox 1.0 will make a _really_ big splash.
Heck, 0.9 was pretty big. There's a unique opportunity here to simultaneously
have a bunch of excellent demos and a much-desired new feature, _and_ throw a
whole bunch of MNG capable browsers out there, at a time when the community is
going to be excited about firefox and keen to play with the features.
I think that not only will they come, but it may drive adoption of firefox,
which will drive adoption of mng...
It sounds like we are talking on the order of 100k, which is presumably before
compression. I believe there's a strong case to include it and testing the hell
out of it before release.
> Given the choice, we'd be much better off bundling Flash with Firefox based on
> the "size vs. usability boost" equation. I realize lots of people don't like
> Flash for a myriad of reasons, but users don't care.
Good flash support is definitely useful, but flash cannot do many of the things
MNG can do, due to its nature as a plugin. MNG support is also much more
compact, and has potential to have a larger benefit (from bundling), IMO.
And yes, I know this is very late in the piece ;-)
RE: comment 479:
"something of intrest to a tiny minority"
702 people voted for this bug. Not a demand or accusation. It seems that this
argument, that there is little interest in mng, has been proven incorrect. If
there is still other valid reasons for leaving it out, then let's discuss those
I understand that a comprimise has been reached, to say that if the code size
can be reduced to a certain point, then it can be included again, just to
clarify, what is that code size? Is 100k not small enough?
I Knew that vote number would come up.
After a campaign to vote for this bug you got 702 people out of about 6 Billion
people on the planet, Tens of millions of Internet users, and tens of thousands
of web developers. That IS a tiny minority of any of those groups.
The Fact is most users don't care because almost no sites have MNGs, and most
site designers don't care because over 90% of the people visiting their sites
wouldn't be able to see the MNGs and that wouldn't change if all Mozilla
products had them starting tomorrow.
I'm part of the tiny minority that would like to see MNG supported, but not at
any cost. I don't have any say on the footprint threshold for MNG inclusion, but
common sense should tell you the smaller it is the greater the liklyhood it will
be picked up.
Keith, John, Sam, Kevin and others, could you please just SHUT UP and stop
spamming us with things that belong into a discussion board but not a bug
report? The more useless comments are made, the less attention will this issue get.
If you want to change something, then help opi and Glenn, if you can't
contribute other than throwing arguments about what to do at the others, then
kindly refrain from commenting (and even from anwering me in this bug report).
okay, i am the rude one who voted for this bug; let me be the one to wrap up the
spam. i dont care how it happened; but a whole bunch of us started to
contribute to making free software. i saw projects where the priorities were
1)freesoftware and 2)good software. one day you wake up and see you volunteer
for 1) propietary software and 2)not good software. you get angry and frustrated.
flash is propietary and not good software. it is popular. i did not volunteer
for popularity and probably many of the people actually writing the code used to
get beat up as kids for not being popular.
mozilla is the high school of software i think. popular **** not good
hearted volunteers. whatever reasons "flash" is there and mng is not all go
back to this same pubescent issue.
please, for heavens sake? what are you doing and why? is there a browser fork
of this peoples browser that is interested in free software first and good
software second and popularity not at all?
one more thing. spam. spam is "Unsolicited e-mail, often of a commercial
nature, sent indiscriminately to multiple mailing lists, individuals, or
newsgroups; junk e-mail." (http://dictionary.reference.com/search?q=spam&r=67)
this email is something you sign up for. the stuff being called spam are
actually questions that are *not* of a commercial nature. the answers seem to
be commercially motivated. if you use the actual definition of spam, the
answers for why this flash condition exists are spam and the questioning of the
policy is not.
i did not consider the recent flurry of "what the hell?" questions to be spam,
less spam in the answer and more actual words of fact would be nice.
(In reply to comment #485)
>one more thing. spam. spam is "[...]; junk e-mail."
Junk e-mail. Junk. Worthless. In the way. Annoying. Exactly what the most of the
comments on this bug is. Besides, any dictionary will always be lacking and
outdated, as every word has different semantics for every person, as well as
continually having its semantics updated. I could refer you to the case of the
Danish word, a "bjørnetjeneste", but I doubt that would mean much to you.
Please, I want MNG and JNG in Gecko too, but I don't spam this report with
reasons why. And I'm tired of reading people arguing *for* inclusion of this.
(No one is against this, from what I can see. There's just a price to pay for
it. As is with everything.) I don't know how to program in C/C++/pretty much
anything but Python, PHP, and a wee bit Perl, but I know that some of you are
able to, so go and mess with the MNG code and try to improve and reduce it
instead of adding more useless (junk!) comments to this bug. Go to the
MozillaZine, lovely place that is, and discuss about including this all you
want, and then leave this bug's comments for people who are *ACTIVELY & ACTUALLY
WORKING ON IT*! That way, those who want to discuss can do that, and those who
want to hack/program/work/test/debug can do that. No one will get annoyed would
be annoyed with that.
- Freso, with his first Mozilla Bugzilla comment ever. Too sad it had to go out
to something like this.
Re: comment #471
A fix for the problem with binary transparency handling in standalone PNG files
has been checked in to libmng-devel CVS. The 16-bit images are still shown
incorrectly under the MNG_BUILD_WEB_NO_JNG and MNG_BUILD_MOZ_MNG configurations
but that cannot be helped, due to the 16-bit transparency information being
deliberately thrown away. MNG_BUILD_RAW_MNG and MNG_BUILD_FULL_MNG show them
all correctly.
Created attachment 152566 [details]
MNG (1.0.8b1+1) patch (trunk) bzip2
* updating to latest libmng cvs (08.07.04)
* PNG transparency problem
resolved, but on 16bit PNG's and no 16Bit support compile the Transparency bit
may be cutted.
* If patch is applied but mng not compiled in, open a mng file directly causes
many windows opened.
Bug is somewhere inside mozilla.
Is something left out?
> * If patch is applied but mng not compiled in, open a mng file directly causes
> many windows opened.
> Bug is somewhere inside mozilla.
hmm, if you're changing the accept-header so that Moz thinks we do handle it,
there might be a nasty loop somewhere in there. This is the whole
network.http.accept.default pref issue that tor mentioned. We shouldn't modify
that unless MNG is indeed being built. (You can use the preprocessor in all.js now)
Created attachment 152660 [details] [diff] [review]
Patch MIME sniffer code in libpr0n/src/imgLoader.cpp
Apply this patch after applying patch #152566. Apply it from the
mozilla/modules/libpr0n/src directory. This should cause imgLoader
to set the MIME type only for those formats that are actually being
built. I can't reproduced the many-windows-opening problem so I don't
know if it fixes that. Someone who is experiencing the problem, please
Where can we get recent nightlies with the new MNG code compiled in so we can
help test it for issues ?
Stable issuefree MNG is a requirement for bug 48893 and implementing bug 48893
goes towards fixing this bug as it reduces the oversize of Mozilla.
BTW I don't see any bug about using the JNG decoder for decoding JPG .. Is there
some reason for this ? (Perhaps the JNG decoder uses functions from the JPG
decoder instead ?)
Where can we get recent nightlies with the new MNG code compiled in so we can
help test it for issues ?
Check the mozillazine forum on 3rd party unofficial builds. There are
several people regularly building MNG (and SVG) enabled Firefox and
Mozilla. There are binaries at mngzilla.sf.net, but not the most recent
Stable issuefree MNG is a requirement for bug 48893 and implementing bug 48893
goes towards fixing this bug as it reduces the oversize of Mozilla.
The recent patches here can be used to implement/test bug #48893. You
simply delete "png" from the IMAGE_DECODERS list:
ac_add_options --enable-image-decoders=mng,gif,jpeg,bmp,xbm
If you are feeling particularly rambunctious, you can also delete
gif and bmp.
BTW I don't see any bug about using the JNG decoder for decoding JPG .. Is there
some reason for this ? (Perhaps the JNG decoder uses functions from the JPG
decoder instead ?)
Right. As mentioned in a couple of comments in bug #48893, libmng uses
libjpeg to decode JNGs so there's no potential savings there.
Created attachment 152759 [details] [diff] [review]
Patch MIME sniffer code (2)
Unwrapped some long lines in the patch that were wrapped.
The patch seems to be ok, can you please make it working without applaying mng
patch, open a new bug, block this bug and add attach the patch on the new bug.
The patch should be done with "diff -u8p -r" and best from ./mozilla ... I think
we can land this patch fast, then I update the mng patch to also had this included.
In fact I'm planning exactly that but have PM'ed Peter to test first because
my platform doesn't exhibit the many-open-windows behavior. I agree that
the bug is probably really unrelated to MNG.
Opi: re comment #494, done. See bug #250936.
How can my business support MNG if the best browser does not want to include it
on its releases due to size. My business is all about open source for
small/medium size businesses. If the open source like mozilla does not include
MNG outright then It will be hard to sell it to the businesses.
There's a free, more efficient way than animated gif to display small animated
pics, and with my last mozilla update, mng is no more supported ? Why ?
Because its still being worked on. Give them time to do it right.
Is size really the hold up for getting mng support? If so that's just dumb. Who
cares about 200-300k extra.
Hereby I propose changing this bug's summary to
"DON'T SPAM THIS BUG!!!1 (its purpose is to restore MNG and JNG support)"
I compared the filesize of two unofficial builds.
A 0.9.2 release build from stipe without MNG and packed with 7z.
And a 0.9.2 release build from amano with MNG and Gopher (and some other small
things) .. also packed with 7z.
The amano build was 58 kilobytes larger.
To make an acurate apples to apples comparison though , we need to compare two
almost identical builds where the only diffence is the MNG support.
No such two builds exist yet but perhaps someone will build them.
Had trouble building this on the AVIARY branch recently.
m:\Build\AVIARY-SAMUKE-SSE2\build\dist\include\gfx\nsColor.h(44) : fatal error C
1083: Cannot open include file: 'nsStringFwd.h': No such file or directory
make[5]: *** [imgContainerMNG.obj] Error 2
Closer inspection led me to the checkin for bug 242254, fixed on the branch,
particularly to the modifications to nsColor.h. Not quite sure how to look at
this (I don't code besides HTML), however normal (without MNG patch) building is
Attachment in question is attachment 153213 [details] [diff] [review]. Particular file in question:
the problem is known there will be an updated patch but at the moment I can't
make win builds with mingw (caused by an other bug of mozilla).
But at the end of next week I'll provide a new patch (including libmng 1.0.8
final) against trunk, maybe I make one against AVIARY BRANCH
I don't get this really. Will mozilla / firefox have MNG support or not ?
:: Shakes magic 8 ball ::
The result comes up: Undoubtedly.
Stefan: As you can see, there has been a lot of activity in this bug, meaning
things are still in the works.
Changing this to "enhancement" and removing the "regression" keyword is a lie
and a skewing of the past.
I unfortunately can't undo those changes myself due to a lack of privileges, but
I hope someone who does will.
And to asa, a heart-felt "**** you".
This is an enhancement, and is not a regression because it was purposely
removed. Nobody is going to replace flags that were removed by a driver.
Also, your profanity is not appropriate.
Go read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html (and you're
breaking all three of the commenting rules) and spare us the useless bugspam.
To everybody else, sorry for the bugspam
firstname.lastname@example.com, go read
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html and feel free to send me
email explaining how now that you've read and understand what is and isn't
acceptible in Bugzilla and are willing to play by those rules, that I should
re-enable your Bugzilla account.
How close is MNG to being put back into Mozilla? Also what is left to be done?
Re: Comment 510
I'm re-iterating a few points made earlier, but some of this should be made
crystal clear, especially to those whose impatience leads to bugspam.
MNG won't be put into Mozilla/Firefox until some bugs are fixed up and the code
that enables it is cleaned up. Someone must maintain the code if/when it is
However, MNG inclusion won't even be considered until there is true reason to
include it. According to some numbers I believe I saw at libmng or
png.org/pub/mng, the number of MNG/JNG images ranges in the hundreds or the low
thousands. Period. Worldwide. Ever. Almost all of these images are also set
up as testcases, not as practical media on sites.
Part of the reason for this is that the MNG spec and the mime types video/x-mng
and image/x-jng are not registered with the IETF, meaning to say that they are
not truly "accepted" or "standard" in an official documented sense. Thus,
software and web servers aren't even configured to handle these filetypes for
clients anyway.
This lack of official recommendation and lack of support in a global perspective
makes it pointless to include MNG because it generally will not be used in a
general-use public web browser such as Mozilla/Firefox. This makes it cruft.
Cruft is to be left out as much as possible to reduce size and improve performance.
I believe if a larger pro-MNG movement were associated and international
recommendation could be found, MNG inclusion would be certain in
Mozilla/Firefox. And hey, once Opi updates the patch code (or I'll try building
Firefox trunk and see if that works) I'll see the size difference between a
normal build and a MNG (with PNG disabled so MNG renders PNG). That would be a
compelling argument against the status of it as "cruft", if libmng could render
PNG as stably as libpng.
Someone should have done this a long time ago.
Rather than the typical "stop spamming this bug" post, I have an alternative
Please stop spamming this bug, and spam this newly created thread at MozillaZine
The Status Whiteboard (READ EVERYTHING BEFORE COMMENTING. PLEASE USE BUG #204520
TO COMMENT ON TECHNICAL ISSUES.) is quite misleading. If not on technical
issues, what is this bug for? Advocacy?
Moreover, concerning the first sentence of the Status Whiteboard, I doubt that
everyone would read everything, in particular because many comments are obsolete
or not interesting. It would be more useful to point to summaries (as this is
done in some other bugs), like comment #511 (thanks for the explanations!) and
comment #512.
Asa: your abuse of power to censor unpleasant opinions just shows again why I
said what I said (and why I still mean it).
There is a problem with Mozilla 1.8a3 and latest available libimgmng.so.
I've submit the bug in the MNGzilla project page :
because I don't know if it is only specific to MNGzilla project. If some one
could tell me...
(Just to ass, with the same extension and Mozilla 1.8a2 there is no problems)
(In reply to comment #514)
> Asa: your abuse of power to censor unpleasant opinions just shows again why I
> said what I said (and why I still mean it).
Please stop spamming this bug,
and spam this newly created thread at MozillaZine instead:
Created attachment 156638 [details]
MNG (1.0.8) patch (trunk) bzip2
The long awaited and now existing new MNG patch.
This patch is updated to libmng 1.0.8 (final) and works against trunk ... maybe
this patch do not work with aviary (firefox/thunderbird 1.0).
Asa you are a cancer inside Mozilla project.
This is why good programmers keep away from Mozilla develop.
Because you are like Hitler.
Please kick Asa from Mozilla and other spammer like "us".
Asa you are a cancer inside Mozilla project.
This is why good programmers keep away from Mozilla develop.
Because you are like Hitler.
Please kick Asa from Mozilla and other spammer like "us".
At this point I must interject. I was one of the first people to object
publically to the CVS removal of MNG+JNG and have long been involved in Mozilla QA.
Asa Dotzler is part of the heart and soul of Mozilla. Without him and those like
him, this project does not exist. To imply that he is a "cancer" is pure idiocy.
One Mozilla developer showed less-than-wise behavior in this matter, but even
that fell far short of being a cancer.
I want to see MNG+JNG returned to Mozilla. This bug is and always has been
useless. I thought it was a terrible idea to reopen it in the first place (a new
one should have been filed instead). Asa, please close this bug, and if possible
let's ensure nobody can reopen or even comment on it. Enough is enough.
Let's let the stats speak for themselves:
Bugs filed by firstname.lastname@example.com (userid 5003): 448.
Bugs filed by firstname.lastname@example.com (userid 153222): 0.
Account suspended for personal abuse.
(In reply to comment #518)
> Asa you are...
(In reply to comment #520)
> At this point I must interject...
(In reply to comment #521)
> Let's let the stats speak for themselves...
Please stop spamming this bug,
and please spam this thread at MozillaZine, instead:
Zachariah, why do you care about spamming this bug? It's a worthless bug at this
point and anyone that's bothered by the spam could remove themselves from the
bug and be no worse off. This bug isn't good for anything but the spam.
The focus of whoever wants to see MNG support adopted, really should be to
develop a MNG extension. The update mechansisms added to Firefox allow this to
be done and managed easily, and fixes to reach this goal if there's blocking
problems, are much more likely to be accepted than trying to land MNG back in
mozilla in the future. If such an extension is created, it can be listed at
update.mozilla.org. Accept this as reality. Flaming people will get you nowhere
and neither will pushing for this to be fixed in an unacceptable or opposed way.
Damn ! I got every spam here three (3!) times in my mailbox and cannot remove
myself from the cc list since I'm no longer listed (why ??). This bugzilla stuff
does not work. Can one of the maintainers help me ?
(In reply to comment #525)
> Damn ! I got every spam here three (3!) times in my mailbox and cannot remove
> myself from the cc list since I'm no longer listed (why ??). This bugzilla stuff
> does not work. Can one of the maintainers help me ?
Remove your vote and you won't get it...
You're getting the repeat notifications because Bugzilla is having a difficult
time processing the long Cc: list. The more of you that remove yourself from the
Cc: list (or remove your vote which also acts as a Cc:) from this bug, the
better that situation will get.
(In reply to comment #523)
> This bug isn't good for anything but the spam.
Asa, then what's the point to keep this bug open ? I'ld like to see MNG support
back into mozilla (at least as a build option), but if it'll never happen, then
this bug should be closed as "WONTFIX"
(In reply to comment #525)
> Remove your vote and you won't get it...
Good way to decrease support for this enhancement request! :-)
(Note: Asa, I really respect and appreciate all your hard work, and I'm sad
about the personal attacks you've received)
Removing votes would, in the eyes of some people who look at bug statistics,
make this bug look as if it were losing public support. To eliminate bugspam
while preserving your votes, remove yourself from this bug's CC list and then
turn off voter bugspam:
1. Go to your e-mail preferences page.
2. Turn off the "New Comments are added" and "CC list changes" checkboxes
in the Voter column.
3. Submit the changes.
> Asa, then what's the point to keep this bug open ? I'ld like to see MNG support
> back into mozilla (at least as a build option), but if it'll never happen, then
> this bug should be closed as "WONTFIX"
Yes, you are quite correct. It should be closed as WONTFIX.
WONTFIXing it might give the impression that MNG is no longer being considered.
Perhaps it could be resolve as a dupe of bug 204520.
Greg, when MNG is in a state that would be acceptable for landing, a new bug
"land the new, fully reviewed and approved MNG implementation" could be filed.
This bug servers about -><- much value from a technical or even a process
standpoint. I don't think it's a dupe of the disk space issue either. Isn't one
of the conditions of taking the MNG implementation back into the tree that it
not supply its own PNG implementation and use the one we have or be capable of
replacing the one we have with a new one that's as performant and small? Either
way, this bug serves little real purpose and those getting spammed by it are
doing so by choice.
@the mng bug close discussion (asa & co.)
Why don't ask the maintainer? Why speak about something without background
information? Why don't give real information on the needs
@the mng spammer
Why you don't test the patches? Why I get no response? Why you don't help in
the mng development? Why you don't spread mng images/animations in the www?
Mng builds on png that's why a libmng will also provide png support. There are
some outstandings ... the latest patch seems to build but isn't invoked on a
mng image, my own build work, but I've one tree for building and one for
patching ... maybe there is a different for mng and the diff between both is
40MB, so it will take some time.
Another problem is bug 250936 but nobody seems realy interested in this bug :-/
Anything else seems to be fine.
In the next time I'll try to include libimgmng into libimg2 so we can reduce
the overhead of the 2 jpeg's (see bug 204520 ). An option to user libmng for
png's already exist.
Greetings Alex//
resolving as invalid sounds like a better option than wontfix to me, actually.
but i don't really like the sound of either. i agree it serves no real purpose,
but such a resolution would just cause confusion.
There is at least one real propose:
TRACKING the MNG support in mozilla main code
i want to know when this is fixed, how and what is missing until we reach the fix, so closing this bug is cheating the propose of bugzilla.
So please dont close this bug and keep posting about the evolution of MNG in mozilla.
"spam" is a problem? yes, but its a side effect of a move that many people didnt like (whatever if it was right or not, each one have his own opinion)
as for the "mng dislikers", accept that mng have alot of support, as in the past PNG and even JPEG had lot of support (and very little real use).
See bug #257263 for discussion of development of "APNG" format which is a
simple animated PNG format. See bug #257197 for implementation of APNG
in Mozilla.
First of all, I'd like to thank Alexander for the great work. I know how hard it
is to work on such a large patch that touches so many files. Thank you for the
updates in comment #533 and comment #517.
I waited a while to comment again, so as to combine a lot into the same comment.
(Hint, hint).
PLEASE test the patch http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c517 if
you want this to be sped along! Don't comment any longer unless you have
information about your tests. Stop complaining and help.
We have now advocacy about the fate of this bug. Please advocate on the forums.
Alexander is the only one that should decide what happens to this bug. I'd like
to remind people there are 700 votes on this bug. Closing it would most
definately piss some people off. If we are going to close this bug, imho, we'd
need to suggest where they can move their votes to.
Advocacy doesn't go in Bugzilla. I remind people to use
http://forums.mozillazine.org/viewtopic.php?t=115619 for discussions of a
non-technical nature. Examples of GOOD comments:
Comment #536 - "See also" comment
Comment #515 - Testing information
mozbugs: Please keep those personal discussions to private email or mozillazine
forums. That is inappropriate for Bugzilla. I'm sorry you are angry. If you feel
that you were unfairly treated, take it to the forums. I have known Asa for 4
years now, though, and in my experience he is very fair.
> i want to know when this is fixed, how and what is missing until we reach the
> fix, so closing this bug is cheating the propose of bugzilla
I agree that it'd be nice, but seriously, how are we supposed to hear the
progress if people keep posting unecessary crap. Nor should he be expected, as a
volunteer, to keep us posted. But he does occasionally mention things and it
gets drowned out by all the noise. What exactly do you want him to say? Things
like its 70% done? In a software project, you just can't make that kind of
statement, especially when a volunteer is doing it on his free time. Long
progress updates would slow down development.
Please, take this bitching to the forums
http://forums.mozillazine.org/viewtopic.php?t=115619 so we can hear what he
says. And yes, we do hear the spam by choice, but I'm actually more interested
in what Alexander Optiz has to say and would like to stop hearing his stuff get
drowned out. That's the only reason I haven't removed my CC. Thank you.
Created attachment 157850 [details]
MNG (1.0.8) patch (aviary) bzip2
This one should work better for Aviary.
Created attachment 157908 [details]
MNG (1.0.8) patch (aviary) bzip2 (2)
Sorry, that one had an error in imgLoader.cpp.
Created attachment 162320 [details]
MNG (1.0.8) + MIME Sniffer Patch (AVIARY) bzip2
Combination of the attachment 152759 [details] [diff] [review] (Patch MIME sniffer code (2)) and
attachment 156638 [details] (MNG (1.0.8) patch (trunk) bzip2), updated for AVIARY. (The
way MIME declarations were handled somewhere in imgLoader weren't the same as
the latest AVIARY.)
This patch applies cleanly as of 20041016 and would allow one to use the
--enable-image-decoders settings correctly, i.e. doing something like
"-png,mng" to have libmng render PNG images and removing libpng from the code.
(More efficient setup space-wise than having both enabled.)
Created attachment 162568 [details]
MNG (1.0.8) patch (trunk) bzip2
update patch to latest cvs trunk
The MIMESniffer Patch is a bit stupid ... if you want build from aviary with
mng you also do not need it. And the problem of openening multible Windows if
MIME not build in should be resolved on other places ... see bug 250936
Comment on attachment 152759 [details] [diff] [review]
Patch MIME sniffer code (2)
Patch obsoleted by bug #250936. Another approach is required.
Created attachment 164748 [details]
Mozilla-mng-1.0.8 (trunk-1.8a5) bzip2
patch sync'ed with current configure.in; no other changes.
Created attachment 166287 [details]
Mozilla-mng-1.0.8 integrated (trunk-1.8a5) bzip2
First (and long awaited) patch of mozilla MNG patch with MNG integrated into
With MNG inside libimg2 we save a lot of diskspace (no need of doubled jpeg
From this point on it is hard to make MNG extensions cause needed API's are not
frozen and not inside the SDK.
Hopefully I've packaged all correctly :)
Great! But how do I enable JNG with this patch? I built with
ac_add_options --enable-image-decoders=default,mng
ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG
but single JNGs cause the many-window-opening effect, while JNGs in a webpage
just don't show up. And
ac_add_options --enable-image-decoders=default,mng,jng
does not work.
Created attachment 166329 [details]
Mozilla-mng-1.0.8 integrated (trunk-1.8a5) bzip2
I forgott some small changes in the makefiles.
So JNG(and PNG with MNG) should work again.
Created attachment 169769 [details]
Mozilla-mng-1.0.8 integrated (trunk-1.8a6) bzip2
update to trunk changes
Created attachment 172808 [details]
Mizilla-mng-1.0.8 integrated (trunk 1.8b) bzip2
Sync patch with minor trunk change in libpr0n/src/imgLoader.cpp
Created attachment 172809 [details]
Mozilla-mng-1.0.8 integrated (trunk 1.8b) bzip2
Change mime type to application/x-bzip2
attachment 172809 [details] has illegal time stamp in mozilla/modules/libpref/src/init/all.js
--- /mnt/mozilla_compile/mozilla/modules/libpref/src/init/all.js
2004-12-28 19:54:39 +0100
+++ ./mozilla/modules/libpref/src/init/all.js 2004-12-28 19:42:33 +0100
(In reply to comment #550)
> attachment 172809 [details]
and patch for mozilla/modules/libpr0n/src/imgLoader.cpp is malformed.
Created attachment 173014 [details]
Mozilla-mng-1.08 integrated (trunk 1.8b) bzip2
Fixed malformed patch and date. Libmng-1.0.9 has been released so this
patch should be replaced soon with a libmng-1.0.9-based patch.
Created attachment 173326 [details]
Mozilla-mng-1.0.9 integrated (trunk 1.8b) bzip2
Update to new libmng 1.0.9
Will do new size comparisions in the next days.
Will MNG and JNG support ever be added to the 'main' builds of Mozilla and/or
Firefox? I can justify telling people to stop using IE to view my website, or
to update their copy of Firefox, but I can't really justify telling them to go
download and install an obscure build of Mozilla that they likely would have no
idea how to install.
As I understand, it's in the upcoming 1.8 (upon which the firefox 1.1 is built)
-- so yes, eventually, once sm1.8/ff1.1 become stable, yeah.
I don't know where that "info" came from, MNG isn't even in CVS yet, and turning
it on by default in Firefox/Thunderbird is by no means an automatic choice even
if that were true. SVG will be built into 1.1, but disabled by default for now,
but that's not MNG.
(In reply to comment #556 and comment #557)
my response is at:
I probably misunderstood what "integrated" meant, then, see #553.
I'm curious about those size comparisons Opi mentioned in February, too :)
Created attachment 182736 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.8b2) bzip2
Hey all,
was long time to see progress on this patch, but there aren't many things to
update ... ok, the last patch was crashy, couse I forgot a file to add to the
As all know, there won't be a Mozilla 1.8 cause Mozilla Foundation will
concentrate on Firefox/Thunderbird. But there are some users who want the
complete suite ... and so it will give a new complete Suite with the name ...
(do I say it? ... hmmm no) ... ok the name stands but Mozilla Foundation will
clear out all legal stuff before we can present the name. So I call it for the
moment "Suite 1.0" ... yes it will start with 1.0.
And the chance is higher then before to get MNG Support into "Suite 1.0" as in
Mozilla 1.8.
So here some answers to latest questions:
@porta slime (#554): The chance to go into Firefox goes at the moment to zero.
For Mozilla 1.8 it is zero, cause there won't be one. For "Suite 1.0" it may be
around 50 percent.
@Henrik Pauli (#555): Thats not true ... or you know more then me.
@Henrik Pauli (#558): Integrated means, that mng is inside the libimg2.so
(imglib.dll) and not in an extern file (libimgmng.so or mnglib.dll). That
reduces the need of 2 JPEG code in libimg2.so and libimgmng.so.
The size comparisons compares the size of libimg2.so as it is yet and the size
if it is compiled with different mng configurations.
But all last sizes are untrue, couse latest patch missed a file to compile (and
so mozilla crashed on some MNG's).
@Mike Connor (#556): That's right.
Greetings Alex//
why zero for Firefox? :-(
Created attachment 187747 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.8b2) bzip2
Sync with recent trunk changes to configure.in and allmakefiles.sh
(In reply to comment #560)
> why zero for Firefox? :-(
Because the FireFox development is driven by the same people who rejected it for
mozilla even before 1.8 was canceled.
Best chance of getting any spread of mng would be an FF extension as many FF
users install extra extensions, one more will not be a problem and even a non
tech user can install an extension.
Once there are active users and sites using the format there will be more
incentive for Mozilla Foundation to include it into the trunc.
> Best chance of getting any spread of mng would be an FF extension as many FF
> users install extra extensions, one more will not be a problem and even a non
> tech user can install an extension.
AFAIK - Extensions can only be written in Javascript. Although it would be
interesting to see such an implementation of a MNG decoder, it may not be
entirely practical.
Perhaps the Javascript could fetch the MNG file, parse the file, write frames to
are already doing currently). As the javascript would be executing from within
an extension, I believe it should have authority to do all of the above.
The advantage of this solution is that it would utilize the existing PNG support
in Mozilla. The disadvantage being the difficultly of writing a new mng
implementation and possible performance issues. Ultimately, such a solution
would need to be replaced.
> AFAIK - Extensions can only be written in Javascript.
they can be written in C++ too
Created attachment 188747 [details]
Mozilla-mng-1.0.9+ integrated (seamonkey-1.0a) bzip2
Sync MNG patch with recent change to config/autoconf.mk.in
Created attachment 190102 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.8b3 050721) bzip2
Sync with trunk; fix problem with Windows library linking.
Created attachment 191141 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.8b3 050731) bzip2
Sync patch with trunk. Added LIBXUL_LIBRARY=1 to mng Makefile.in
Created attachment 191715 [details]
Mozilla-mng-1.09+ integrated (trunk 1.8b3 050805) bzip2
Sync patch with trunk's configure.in
Created attachment 193120 [details]
Mozilla mng-1.0.9+ integrated (trunk 1.9a 050818) bzip2
Sync patch with trunk (change in allmakefiles.sh)
Note that any patch will have to add entries back into prefs if/when bug 305435
is fixed.
Created attachment 193428 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 050822) bzip2
Sync with changes to trunk's configure.in
Undo checkin of patch from bug #305435 to trunk
Created attachment 193639 [details]
Mozilla-mng-1.0.9+ integrated (branch 1.8b4 050819) bzip2
Sync'ed patch with MOZILLA_1.8_BRANCH. Use this patch to add MNG to a 1.8
branch checkout.
Created attachment 193991 [details]
Mozilla-1.9a-mng-1.09+ integrated (trunk 050825) bzip2
Sync with libmng CVS (reduces footprint of "MOZ" and "WEB" configurations,
removes MAGN chunk support from "WEB" configurations, restores 16-bit PNG
support to "WEB" configurations)
Created attachment 193992 [details]
Mozilla-1.8b4-mng-1.0.9+ integrated (branch 050826) bzip2
Sync with libmng CVS (reduces footprint of "MOZ" and "WEB" configurations,
removes MAGN chunk support from "WEB" configurations, restores 16-bit PNG
support to "WEB" configurations). Sync patch with yesterday's changes checked
in to libpr0n/build.
Does not compile for me (VC 6, branch):
D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT /cygdrive/c/mozilla/modules/libpr0n/build/n
C:\Programme\SDK\include\basetsd.h(32) : error C2371: 'INT32' : Neudefinition; u
nterschiedliche Basistypen
../../../dist/include/jpeg\jmorecfg.h(178) : Siehe Deklaration von 'INT3
C:\Programme\SDK\include\wingdi.h(750) : warning C4005: 'BI_RLE8' : Makro-Neudef
c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(135) : S
iehe vorherige Definition von 'BI_RLE8'
C:\Programme\SDK\include\wingdi.h(751) : warning C4005: 'BI_RLE4' : Makro-Neudef
c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(136) : S
iehe vorherige Definition von 'BI_RLE4'
C:\Programme\SDK\include\wingdi.h(752) : warning C4005: 'BI_BITFIELDS' : Makro-N
c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(137) : S
iehe vorherige Definition von 'BI_BITFIELDS'
make[4]: *** [nsImageModule.obj] Error 2
make[4]: Leaving directory `/cygdrive/c/mozilla/modules/libpr0n/build'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/cygdrive/c/mozilla/modules/libpr0n'
make[2]: *** [tier_9] Error 2
make[2]: Leaving directory `/cygdrive/c/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/c/mozilla'
make: *** [build] Error 2
Bernd: can you compile if you don't apply the MNG patch? There was a
checkin of bug #223909 on Aug 26 that involves the JPEG encoder, where
BI_RLE8 and other macros are defined.
< #if defined(XP_WIN32) && defined(IMG_BUILD_jpeg)
< #include "nsJPEGEncoder.h"
< #endif
Bernd: can you compile the same download if you don't apply the MNG patch?
The checkin involved the JPEG encoder but the macros are defined in the BMP
decoder, so that is likely not to be the problem...
At line 179 of mozilla/jpeg/jmorecfg.h
try changing
typedef long INT32;
#ifndef INT32
typedef long INT32;
See bug#223909 which adds an include of a JPEG library that
in turn includes jmorecfg.h.
I had time to build again:
Your suggested fix didn't work just as you indicated it in comment#31 of bug
Created attachment 194334 [details]
Mozilla-1.8b4-mng-1.0.9+ integrated (branch 050830) bzip2
Rearranges order of #includes in nsImageModule.cpp to avoid doubly defining
INT32 on Windows platforms.
Comment on attachment 193991 [details]
Mozilla-1.9a-mng-1.09+ integrated (trunk 050825) bzip2
Incompatible changes to allmakefiles.sh, configure.in, and
libpr0n/build/nsImageModule.cpp have made this patch obsolete.
Created attachment 194728 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 050902) bzip2
Sync trunk patch with changes to allmakefiles.sh, configure.in, and
libpr0n/build/nsImageModule.cpp that were recently checked in to bug #245684
At this point, is the patch to the point where it could be integrated into the
build system with an --enable-mng option that was disabled by default?
This would allow Firefox to not have it by default for size.
Andy: Yes, ever since February 2004 (commment #374),
MNG doesn't compile by default with this patch, you need:
to build MNG in your patched tree.
Also, if you use
mozilla will use libmng to supply the PNG support, saving about 50k
in footprint by eliminating libpng.
Created attachment 194884 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 050904) bzip2
Removed some stray "*.orig" file references that were left in the "050902"
trunk patch.
glennrp: it's great that you continue to update the MNG/JNG patch. But should
not the main goal be to get this reviewed and checked in? Otherwise you can
unbitrot the patches forever (well, at least that might fully test Bugzilla's
limits). Perhaps the SeaMonkey council can help? I remember that at least one of
them was also unhappy with the removal of MNG.
tor, if you still listen: it seems to me that all previous comments were taken
into account some time ago, so is there any chance you might have time to look
at this patch and review it? If you don't who else would be able to do that?
Comment on attachment 194884 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 050904) bzip2
tor: r?
peter: opi already has two open requests (February and May 2005). I'll cancel
those if I can.
Hi there I'm again and I thank glenn that he had done new patches.
Now good news I've set up a tinderbox that builds SeaMonkey 1.0a branch builds
with MNG enabled it uses the "Mozilla-1.8b4-mng-1.0.9+ integrated (branch
050830) bzip2" patch.
You can find the builds on http://mozilla.itkombinat.de/tinderbox/
Created attachment 198263 [details]
Mozilla-1.8b4-mng-1.0.9+ integrated (branch 051002) bzip2
Update patch to work with recent change to configure.in on 1.8 branch
Created attachment 198777 [details]
Mozilla-1.8b5-mng-1.0.9+ integrated (branch 051006) bzip2
Fixes memory overflow bug in MNG_NO_1_2_4BIT_SUPPORTED configuration
Created attachment 198778 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 051006) bzip2
Fixes memory overflow bug in MNG_NO_1_2_4BIT_SUPPORTED configuration; makes
patch consistent with recent checkin of incompatible pref-winhooks* files in
patch for bug #302479.
Created attachment 203443 [details]
Mozilla-mng-1.0.9+ integrated (trunk 1.9a 051117) bzip2
Makes patch compatible with recent checkin from bug #245684
Created attachment 204125 [details]
mozilla-1.9a1-mng-1.0.9+ (trunk 051123)
Compensates for recent incompatible checkins involving automake.in and os2/browser.jst
Created attachment 204902 [details]
mozilla-1.9a1-mng-1.0.9+ (trunk 051203)
Compensates for 11/29 incompatible checkin to configure.in
I've tried to build Firefox 1.5 with the mozilla-1.8b5-mng-051006 patch. Everything works okay, but in the end firefox.exe doesn't compile:
Creating library firefox.lib and object firefox.exp
mng.lib(libmng_chunk_io.obj) : error LNK2019: unresolved external symbol _mng_inflate_buffer referenced in function _create_chunk_storage
firefox.exe : fatal error LNK1120: 1 unresolved externals
make[4]: *** [firefox.exe] Error 96
Compiling on Windows XP with vc7.1.
Created attachment 204990 [details]
Mozilla-1.8-mng-1.0.9+ (branch 051204) bzip2
Fixes problem with unsatisfied reference to mng_inflate_buffer() on 1.8 branch
Created attachment 204991 [details]
mozilla-1.9a1-mng-1.0.9+ (trunk 051204)
Fixes problem with unsatisfied reference to mng_inflate_buffer() on trunk.
Instead of putting new patches in this bug every few days, how about moving the patches to mozdev or sourceforge or libpng.org/mng and keep current versions up there.
It doesn't seem like keeping 100 patches in a bug is really what bugzilla was designed for.
I think it would be even better if it was stored in the current CVS HEAD, but failing that, why move it off into obscurity?
I don't see that happening any time soon and I'd say a bugzilla bug is pretty obscure to start with, so it seems like putting it somewhere else wouldn't be so bad.
I agree that this patch is a bit too large to be updated every few days, perhaps posting the Mozilla part only and not libmng itself would be a better idea. (One could see it as a testcase for Bugzilla, though. ;-) )
The code that needs review and could disturbe any of the other code in CVS are really only a few lines. You are one of the people who could review it and the sooner you do that the sooner this bug could be resolved...
Comment on attachment 204990 [details]
Mozilla-1.8-mng-1.0.9+ (branch 051204) bzip2
tor: r?
Comment on attachment 204990 [details]
Mozilla-1.8-mng-1.0.9+ (branch 051204) bzip2
This patch is now made obsolete by a new patch posted at mngzilla.sf.net in the Download/mngzilla-patches area. Please interpret the "r?" flag as a request to review the patch over there.
What's needed to restore for MNG support to the trunk?Does the recent patches have any serious problems?
If bug 204520 is the big problem, prepare "--enable-mng" option in configure script and it turns off by default. If users want to test MNG featute, they have to turn on.What I mean is that this option is categorize as "Components and Features" at http://webtools.mozilla.org/build/config.cgi
If system has a valid libmng, configure script adds MNG feature automatically. This is the another idea. Maybe the size is not so bigger than that without MNG feature.
Sorry for idea only.
Takanori: This feature has been present in the patches for nearly two years.
See comment#374 and comment #585.
To demonstrate this to yourself, apply the latest patch (for the trunk or the
1.8 branch, as appropriate) from mngzilla.sf.net, run autoconfig, and build.
Notice that the executable is the same as without the patch, and that there
is no MNG support. Then put
in your .mozconfig file (you must do it with a text editor because the
"configurator" doesn't have a checklist for decoders) and build again.
Notice that the image library is about 120kbytes larger and that you
have full MNG support.
I've separated the mng patch into one that adds the mng library and another (with trunk and branch versions) that adds mng "glue" to libpr0n and various configuration files, as Peter suggested in comment #603. You need both the "add-libmng" patch and the appropriate "mng glue" patch. The "add-libmng" patch is not likely to be subject to bit-rot, while the "glue" patches will probably be updated frequently. The patches are available at http://mngzilla.sf.net in the DOWNLOAD area, mngzilla-patches package.
Our research lab makes MNG movies of bio-molecules. We plan to make these publically available. MNG seems like it is probably the best format for us.
We would like to recommend your browser for our web page, but presently
mozilla does not support MNG format.
Feel free to contact me at email@example.com
My vote is to add MNG support to Firefox by version 3 (and Seamonkey).
This niche is currently being filled by the proprietary SWF (Flash) format and aging GIF format. Some say there aren't many MNG creation tools and other browsers support it. The situation is very chicken and egg, and Firefox support would help things out a lot, especially considering that Firefox is #2 in browser market share measurements. I also posted in the forum topic for this bug report.
I assume that a lot of work has been done on the patch in the months that were quiet on this bug-report. May be you could possibly post a recent version of the glue-code in a patch format (non-compressed) over here in bugzilla, and ask for the review? (Please, do post the glue-code non-compressed so that everyone can easily see the changes it makes with default bugzilla patch-browser.)
Also, some update on major changes made in the last year period might be appropriate here, too.
(In reply to comment #611)
> Glenn,
> I assume that a lot of work has been done on the patch in the months that were
> quiet on this bug-report.
No, nothing other than keeping up with bit-rot. Otherwise it is working fine
and doesn't need any work.
>May be you could possibly post a recent version of
> the glue-code in a patch format (non-compressed) over here in bugzilla,
> and ask for the review? (Please, do post the glue-code non-compressed
> so that everyone can easily see the changes it makes with default
> bugzilla patch-browser.)
The glue-code patch is quite fragile, easily broken by changes to
configure.in, allmakefiles.sh, etc. If I were to post it here I'd be
back in the mode of last year, having to update it often, as I do over
on mngzilla.sf.net.
> Also, some update on major changes made in the last year period might be
> appropriate here, too.
There were none.
(In reply to comment #612)
> > I assume that a lot of work has been done on the patch in the months that were
> > quiet on this bug-report.
> No, nothing other than keeping up with bit-rot. Otherwise it is working fine
> and doesn't need any work.
Why don't you ask for a review then, if there is nothing more to be fixed?
> >May be you could possibly post a recent version of
> > the glue-code in a patch format (non-compressed) over here in bugzilla,
> > and ask for the review? (Please, do post the glue-code non-compressed
> > so that everyone can easily see the changes it makes with default
> > bugzilla patch-browser.)
> The glue-code patch is quite fragile, easily broken by changes to
> configure.in, allmakefiles.sh, etc.
It's not like you have to update it every week here, you can update it here every so often, and the reviewer would assume that the patch still applies (and if the patch doesn't apply, the reviewer would then go to the sf.net page for the otherwise identical patch but which applies to most-recent tree).
Having some more or less recent patch in bugzilla would make the review process easier, IMHO. As far as I understand, no-one is reviewing the patch now, because there is simply no official request and no official patch to review.
>If I were to post it here I'd be
> back in the mode of last year, having to update it often, as I do over
> on mngzilla.sf.net.
How will it ever be integrated into the main mozilla source-tree if it's not posted here, and doesn't get a review/superreview from someone? Alternatively, is it the plan to never have it in the main tree? I think something must be done to fix the situation; posting a patch here and requesting a review might be the first step...
>there were none.
Oops, I forgot. There were some minor mods required for CAIRO support.
>Why don't you ask for a review
Please suggest a reviewer.
(In reply to comment #613)
> How will it ever be integrated into the main mozilla source-tree if it's not
> posted here, and doesn't get a review/superreview from someone? Alternatively,
> is it the plan to never have it in the main tree? I think something must be
> done to fix the situation; posting a patch here and requesting a review might
> be the first step...
As an outsider to this whole process, may I just say that I would be saddened if it did not somehow make it into the main tree. My entire goal (and reason for being on this CC list) is for MNG support to exist in some future version of Firefox that I download (pre-built, bundled -- I haven't been building by hand, though I probably could), and thus have it be available to a great many people (who couldn't build it if they wanted to, many of them -- for lack of know-how and tools, even if not for lack of the option). I hope that getting this patch into the main tree would provide that for me, even if there were then future steps to get it there.
So, whatever it does take, I hope that getting this patch into the mozilla tree will happen. I sense a bit of frustration from multiple perspectives on this, and I'm enough of an outsider that I don't know what the frustration factors are, exactly (or even if my sense is correct, really), but I do hope they'll be worked past and that I can see MNGs within Firefox sometime soon (whatever "soon" might mean).
>So, whatever it does take, I hope that getting this patch into the mozilla tree
>will happen. I sense a bit of frustration from multiple perspectives on this,
>and I'm enough of an outsider that I don't know what the frustration factors
>are, exactly (or even if my sense is correct, really), but I do hope they'll be
>worked past and that I can see MNGs within Firefox sometime soon (whatever
>"soon" might mean).
I too would love to see the official release of Firefox with MNG. However, I do not see this happening any time within the near future. In the meantime, I would love to see someone take this work and make an extension out of it. I have noticed that extensions that are often downloaded seem to make their way into newer versions of Firefox. Perhaps that is the solution to getting it recognized since 812 votes seem to have no impact.
> My entire goal (and reason
> for being on this CC list) is for MNG support to exist in some future version
> of Firefox that I download (pre-built, bundled --
You can get prebuilt binaries from mngzilla.sf.net, for FF 1.5, 2.0, and 3.0.
I use the 3.0 build by "auenf" as my regular browser. It uses the MNG library
to provide PNG support.
(In reply to comment #617)
> You can get prebuilt binaries from mngzilla.sf.net, for FF 1.5, 2.0, and 3.0.
> I use the 3.0 build by "auenf" as my regular browser. It uses the MNG library
> to provide PNG support.
That's nice to know, and perhaps I'll go do that... However, it doesn't really solve the problem for me. For me, the problem is not so much as a consumer of content, but as a producer of content. I want _everybody_ who has a certain version of FF or later, and/or who has a certain extension to it (that solution might actually work for me -- though built-in would be better, of course), to have this. I want this to replace GIF for animated images. It can't do that without browser support. Browser support has to start somewhere. I'd think that the mozilla project would be a good place for it to start.
I really hope that my comments here will be taken solely as encouragement to make this happen, somehow. I'd really like to see it. I don't know how much I can help beyond encouragement, but if there's something you think I might do, please do feel free to contact me directly.
Could someone provide a list of what is blocking us from re-implementing MNG? Thanks!
(In reply to comment #619)
> Could someone provide a list of what is blocking us from re-implementing MNG?
> Thanks!
I'd like to know that also
copied from newsgroup posting:
>> Sarreq Teryx wrote:
>> I know this has probably come up at some point, but will MNG/JNG or APNG
>> support be implemented any time soon (without having to resort to a
>> plugin)? mostly I'd just like to see JNG, the lack of compression in PNG
>> really limits my use of them in my web pages, but I'd also like to
>> replace my animated GIFs, I hate having to create a new copy of each just
>> so I can change the background color of my pages (anti-aliasing).
> Eli Friedman wrote:
>I can't really see why you'd want to use JNG; it's exactly the same
>compression as plain old JPG.
the point being JPEGs with an alpha-channel, or alpha-channeled PNGs small
enough to use on a web page and not take forever to load. Tell me this,
over the course of a day's web browsing traffic, what's more bandwidth
efficient, having users download a compiled copy of Firefox with JNG support
then lots of 88.5KB images, or leaving out JNG and having them download lots
of 628.74KB images (example used here: http://sarreq.elflord.net/mngpng/)?
just because the bandwidth is there doesn't mean it needs to be saturated,
and also think of all the hosting sites who give you a limited amount of
total traffic. Yes this particular wish could be fulfilled by (for shame)
MS's HD Photo format, but also, there's no browser support for that either
(except in IE7, as long as you're running either XP with .Net 3 and WIC or
> MNG/JNG support is not planned. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=18574.
saw it, saw nothing but "We don't want to do it" with no really good reasons
behind that
1. code bloat ---> oooh wow, 542KB (from
http://gjuyn.xs4all.nl/libmng/download.html?cat=25) on top of 36MB (220.127.116.11
rc1 source package compressed, wasn't going to DL to check uncompressed),
doesn't seem that much of a bloat to me. And stripping the duplicate JPEG
and PNG code would make it even smaller.
2. An XPI/plugin exists to do just that ---> An XPI needs understanding of
how to compile and merge the sources, or an alternate build which most
people won't realize exists, while a plugin requires the use of the
embed/object tag, and doesn't render the alpha-channel properly, and both
the XPI and the plugin need to be widely known about for them to be used,
which they're not, so neither are particularly appetizing options
3. MNG-LC/VLC or other subset may find their way in ---> sorry but a subset
of certain formats is a joke, this being one of those jokes
4. GIF, Flash and SVG cover this feature ---> GIF is what those of us who
want MNG support are trying to replace, Flash, again, needs a downloaded
plugin (which firefox does know how to find on it's own, granted) and
embed/object tag, and then SVG, point me to a program which actually outputs
the code to duplicate the functionality, I can't seem to find any myself,
and even so, again, NO COMPRESSION
5. MNG/JNG is not w3c recomended ---> but then neither are GIF or Flash,
they're just ubiquitous
6. MNG/JNG is not used much ---> Well, I think there's a good reason for
that, the browser support doesn't exist, woohoo! The same could have been
said about JPEG, GIF, PNG, SVG and Flash when they were first proposed for
browser use. I really hate using this word, but DUH!
7. there's no one to maintain the code ---> FIND someone, out of the
millions of programmers on the planet, I'm sure someone exists that would be
willing to take care of it (don't look at me, I don't even know javascript
that well)
8. GIF patent issues are no longer a problem to GIF use ---> So what, that
has nothing to do with what the format is capable of, GIF is still limited
to 8bit paletted color with one of those used as the transparency mask,
being out of under Unisys's foot doesn't fix that.
> APNG support is planned for Gecko 1.9/Fx 3.0, but of course using it on
> the web would be pretty stupid in most
> cases since no other browser will support it. It's mostly intended for
> XUL/chrome stuff. Work is ongoing in
> https://bugzilla.mozilla.org/show_bug.cgi?id=257197.
Which is fine, but again, no more compression than regular PNGs, and since
we're talking multiple frames in each file, even larger APNGs. As for lack
of browser support, if a feature is used enough it will spread to the other
browsers, how long did Firefox support PNG before it was supported in
Internet Explorer (without javascript workarounds)?
As for use in XUL/chrome, you're willing to have supersized images for
skins/GUI elements over smaller images and an insignificant amount of code
bloat? where's the thinking there?
Adoption of a format, no matter what it is, takes the first larger
competitor to say it's a format wanted by the web developers and end-users.
Konqueror supports MNG/JNG, but it's not exactly one of the larger
We aren't going to add back MNG support. This bug was left open because certain people didn't want it closed but it really just isn't going to happen and people need to realize that. We'll be adding APNG support shortly and we'll look at other image formats down the road.
(In reply to comment #621)
some things to say:
- there aren't good reason to keep out the patch of Glenn Randers-Pehrson.
- reading all the histry of this bug, I learned that much time ago, some of the drivers decide to keep out MNG code arguing of size growing
- lot of user want this feature, looking at the number of votes (831), maybe the most voted bug of mozilla
- periodically new user post an ask to add back MNG
- can normal GPL users, not drivers, decide where Mozilla should go, also respecting all the prerequisite for code manteining and patching?
Wake up, we aren't in a democracy.
Constantine A. Murenin or someone else, please suggest a reviewer for the Glenn patch.
(In reply to comment #623)
> - can normal GPL users, not drivers, decide where Mozilla should go, also
> respecting all the prerequisite for code manteining and patching?
Normal GPL users? Mozilla is built on top of the MPL... not sure what GPL users are.
> Wake up, we aren't in a democracy.
Yes.. and that is why your vote doesn't matter...
> Constantine A. Murenin or someone else, please suggest a reviewer for the Glenn
> patch.
I'm the module owner and we've been over this. People tried to go over my head and got shot down. Please let this bug finally die.
Look people. There is no democracy. It has been made abunduntly clear that this is a personal issue with Stuart and he doesn't want MNG in Firefox for whatever reasons. Maybe he doesn't like the guy who developed MNG, who knows. The point is that no one has offered a rational explanation of why MNG shouldn't be included, and they have made it abunduntly clear that they are not going to explain it in the future either. If you want to agitate for MNG, you need to agitate to have Stuart replaced as the module owner.
Þe next move is to now go to distributions ænd forks. We should now start opening bug reports wið þe patches in distributions in Linux, BSD, etc. ænd forks such as IceWeasel. To þæt end, Ich just filled out a feature request for Debian Linux ænd will post þe bug number here soon.
Þe bug report for þis in Debian linux is:
(In reply to comment #621)
> {{ JNG support }} Yes this particular wish could be fulfilled by (for shame)
> MS's HD Photo format, but also, there's no browser support for that either
> (except in IE7, as long as you're running either XP with .Net 3 and WIC or
> Vista).
As explained above, Microsoft has already taken care of a JPG w/ Alpha Channels format, and it's already supported by the latest-greatest software out there. People are already using it, so there's really no point now in introducing JNG. Let's just support HD Photo and call it a night.
Firefox is not responsible for makeing image formats popular by supporting them. I mean, it's not like web developers built their websites based on what works on end user's browsers. They build websites around what MSDN says. PNG is just a fluke.
(In reply to comment #625)
> Look people. There is no democracy. It has been made abunduntly clear that this
> is a personal issue with Stuart and he doesn't want MNG in Firefox for whatever
> reasons. Maybe he doesn't like the guy who developed MNG, who knows. The point
> is that no one has offered a rational explanation of why MNG shouldn't be
> included, and they have made it abunduntly clear that they are not going to
> explain it in the future either. If you want to agitate for MNG, you need to
> agitate to have Stuart replaced as the module owner.
Then perhaps when he moves on this can get committed? In my opinion, this is something that should have been made part of Mozilla YEARS ago. There is little to no chance of MNG/JNG gaining popularity on the web until Mozilla bundles support in.
Personally, I find it sad when politics and personal problems prevent good code from being checked in. Code should be judged on merit alone.
There is a problem that exists for at least 829 web developers, that of producing open, portable, lossless, native, 32-bit RGBA raster animations.
Glenn and 36 other contributors produced a standard which seeks to solve that with respect to a variety of use cases. The binary size for the implementation would constitute a not insignificant increase to the binary size of libpr0n-derived products.
Stuart and Vladimir produced a minimal standard specifically with respect to Mozilla UI. This standard contains at least least one (minor) conflict with the PNG specification. It is unheard of outside of Mozilla.
The power structure in effect is irrelevant as long as we all agree that:
* SVG, GIF, Flash, embedded video and Javascript-driven image-swapping are not satisfactory in many (minority) cases.
* Firefox should provide a solution to this issue for developers.
* That solution should be "best practice", with a view to cross-browser adoption.
* Until broadband penetration increases, any increases in the download size could harm adoption, most critically for Firefox on Windows.
I don't think marking this as WONTFIX constitutes closure on the issue. Either MNG needs to come back or APNG needs to be ratified by the wider community. Even if APNG was ratified by the wider community, this should not necessarily shut the door on MNG in libpr0n as download times drop or the value of MNG support increases.
(In reply to comment #630)
> (In reply to comment #625)
> > Look people. There is no democracy. It has been made abunduntly clear that this
> > is a personal issue with Stuart [...]
> Then perhaps when he moves on this can get committed?
Whatever issues Stuart Parmenter has, it's not just him. As he just said, this debate was taken to other people, and they also rejected the idea of MNG - see for example Mike Connor's comment 474 especially point c.
"Content that 90% of the web doesn't support isn't going to get created in
any substantive way. MNG has the advantage of being more ideologically pure than Flash etc, but if people aren't using it, its cruft, and that's the reality. Given the choice, we'd be much better off bundling Flash with Firefox based on the "size vs. usability boost" equation. I realize lots of people don't like Flash for a myriad of reasons, but users don't care."
> There is little to no chance of MNG/JNG gaining popularity on the web until Mozilla bundles support in.
And the main argument against is that even if Mozilla bundles support, they will still not gain popularity as most websites aren't going to bother with something that doesn't work in IE.
Re: 632 and through that 464
Which is pretty much the only decent argument in this whole debate, but:
- PNG wasn't popular, still isn't too popular, but apparently MS caved in and finally supports alpha in it now and that might give it a boost -- and even before that, quite an amount of people employed the format for the awesomeness of it (a word which here means "full 8-bit alpha while true colour and lossless") -- in this sense, what is there that makes MNG/JNG impossible to gain popularity, at least among the OSS world? (someone mentioned that Konqueror already supports it, I'm not sure if as a result Safari does too, but that would be cool) And if it takes off, MS might follow suit again.
- noone has ever heard of APNG, so it makes me wonder why it's better than MNG/JNG for _UI_ uses, because I seem to remember that the latter are at least standards that have been around for years and have (been having) tools (for a while) with which to create them.
There is very little value to having MNG support; it's interesting that people immediately think that there are "personal reasons" for WONTFIX'ing this bug. The only personal reason that's left is that this bug should have been left alone years ago, but instead it's lived on in a zombie state. I assume it gets personal when someone's decisions (with agreement from the wider project drivers) keep getting second-guessed.
That said, there are technical reasons for why MNG is not in Firefox right now, indeed why MNG is not anywhere on the web right now. The spec as it is suffers from many of the same problems as SVG (but with far less money behind it) in that it's bloated and tries to do too much -- not to mention the utter lack of tooling, and given the spec's complexity, the virtual impossibility of actually creating any useful fully-general tooling around MNG.
MNG is dead; it was too much to bite off all at once and attempted to ride on the success of PNG. PNG solved a specific concrete problem that the web faced; APNG tries to solve another well-defined and specific problem. "open, portable, lossless, native, 32-bit RGBA raster animations" is /not/ a problem that the web faces right now (and it certainly wasn't 5 years ago); indeed, SVG has a higher chance of solving this at the moment despite a host of other problems.
Download size is at this point not very relevant; if there was a reason to support MNG, it could be made to fit. But I'll reiterate: MNG is dead, just like VRML and many other technologies are dead. Good ideas or not, they did not have enough momentum to propel them to some sort of self-sustaining growth. Sure, they'll always be kicking around in some dusty corner of the net, but for all intents and purposes they are dead.
Please let this bug finally die gracefully; there are plenty of new technologies out there to get behind... there is no reason to keep trying to resurrect this one.
So to summarize:
1. Size issues. Not the actual reason. Maybe it was at the beginning, but hasn't been a valid reason for a long time.
2. No one will use it anyway. A somewhat plausible reason on it's own, but still not a very good reason - how many other things does Firefox support that IE never will? Why don't we take those out?
3. MNG is just a dead format because it's just too complicated, and has no financial backing, and no one else cares anyway. This seems like a good enough reason to me, but is that official from the MNG group, or is it just the official opinion of the devs responsible for Mozilla (which is frankly still good enough for me)?
It seems like this whole thread just keeps going on and on, because we get some really bad emotional excuses for leaving it out, without any real rational ones.
To make matters worse, there was a condition set up for it to be reincluded by default, and when that condition was met, it was still stone walled.
That kind of behavior tends to lead to bitter feelings, and hardening ones. If Comment #634 is really the final word on why this is being left out, can we all accept that, and admit that mistakes were made in how this was handled and just let it go?
> - can normal GPL users, not drivers, decide where Mozilla should go, also
> respecting all the prerequisite for code manteining and patching?
No, if you're not part of the Qabal that run this project, your opinion means
nothing. The Mozilla / Firefox / Seamonkey / Whatever drivers / leaders have
NEVER given a rats ass about input from the community. I've been following
this project since shortly after it's inception (eg, since 1997 or so) and it's
always been that way.
Honestly, if you're not happy with the direction of Firefox / Seamonkey /
Thunderbird / what-have-you, the best thing to do is just fork it... or else
accept things the way they are. The "inner circle" just are not going to
acknowledge any need to respect the wants and needs of the community, period.
(In reply to comment #635)
> 2. No one will use it anyway. A somewhat plausible reason on it's own, but
> still not a very good reason - how many other things does Firefox support that
> IE never will? Why don't we take those out?
Please, don't give these guys any ideas. I'd hate to see any more features taken out for some equally asinine reason.
It's a zombie bug, but there remains the open issue that /some/ lossy format with variable alpha is needed, and has been for many years. APNG is not a solution for that. It would be rather depressing to see FireFox have to be a follower and not a leader in response to Microsoft's HD Photo which will cover this capability.
(In reply to comment #622)
> We aren't going to add back MNG support. This bug was left open because
> certain people didn't want it closed but it really just isn't going to happen
> and people need to realize that. We'll be adding APNG support shortly and
> we'll look at other image formats down the road.
I'm sorry, it seems from what I've read on this page that there's a large majority of people here that don't want it closed, not just certain people. And as far as I can see, APNG is only good for XUL/Chrome.
(In reply to comment #624)
>> Wake up, we aren't in a democracy.
>Yes.. and that is why your vote doesn't matter...
Wow, what an answer, maybe you could be president
>> Constantine A. Murenin or someone else, please suggest a reviewer for the
>> Glenn patch.
> I'm the module owner and we've been over this. People tried to go over my
> head and got shot down. Please let this bug finally die.
If there were real, substantial, non-political reasons to let it die, I'm sure it would have by now. all I see is "nononononono, I'm not listening", with no valid reasoning behind it.
(In reply to comment #628)
> Firefox is not responsible for makeing image formats popular by supporting
> them.
I never said it was, but it does have enough of the browser market to influence things along.
> I mean, it's not like web developers built their websites based on
> what works on end user's browsers. They build websites around what MSDN
> says. PNG is just a fluke.
If that's so, why do we even bother using Firefox? I know plenty of my pages have problems rendering properly under IE (until I link in some form of script to accommodate that).
As for PNG being a fluke, maybe, but I don't believe it really is.
(In reply to comment #630)
> Personally, I find it sad when politics and personal problems prevent good
> code from being checked in. Code should be judged on merit alone.
(In reply to comment #631)
> * SVG, GIF, Flash, embedded video and Javascript-driven image-swapping are not
> satisfactory in many (minority) cases.
GIF is not satisfactory period and hasn't been for a good few years.
Flash for that matter is only really satisfactory if you're writing a very complex interactivity based interface, which does so better than HTML or Java/JS, but not for simple site animations or alpha-channeled static images, if you want to talk about bloat, there we go right there.
I can't comment on SVG, I've not found a good program which supports it except for commercial ones.
> * Until broadband penetration increases, any increases in the download size
> could harm adoption, most critically for Firefox on Windows.
realistically, a hundred or so KB on top of 5.7MB (v188.8.131.52) is not going to hurt anything, the possible 1-2MB worth of APNGs that may end up shipping with v3 might though.
> I don't think marking this as WONTFIX constitutes closure on the issue.
Absolutely not, it just constitutes more ignorance of the community at large.
(In reply to comment #634)
> "open, portable, lossless, native, 32-bit RGBA raster animations" is /not/ a
> problem that the web faces right now (and it certainly wasn't 5 years ago)
I disagree. Even in 2001, Windows XP had 32-bit RGBA raster animations in its
UI. The current state of the art today is, potentially, lossless RGBA
everywhere. It's not a large omission, but it still exists: sometimes web app
UI is best served by an animation, and current capabilities warrant something
along these lines. SVG, as you note, has problems that make it unsuitable. It
will remain unsuitable for at least the next couple of years, probably longer.
> But I'll reiterate: MNG is dead, just
> like VRML and many other technologies are dead.
VRML is a dreadful analogy. It borders on FUD to bring it up in this context.
MNG has never featured in a Firefox release and therefore could not be expected
to reach the momentum for self-sustaining growth. If MNG was shipped in FF3,
you would undoubtedly see it in significant use within 6 months, driven by the
blogosphere and "Web 2.0" sites.
> not to mention the utter lack of tooling, and given the spec's complexity, the
> virtual impossibility of actually creating any useful fully-general tooling
> around MNG
I can point out 4 programs currently on my computer which work with MNG (Jasc AnimShop, XnView, IvanView, Ashampoo PhotoComander), two of which supports JNG also (AShampoo Photo Commander, IvanView) , whereas I can only think of adobe and PSP which work with SVG, and not even for animation.
Sorry, my comment #628 was complete sarcasm.
>> Firefox is not responsible for making image formats popular by supporting
>> them.
> I never said it was, but it does have enough of the browser market to influence
> things along.
>> I mean, it's not like web developers built their websites based on
>> what works on end user's browsers. They build websites around what MSDN
>> says. PNG is just a fluke.
> If that's so, why do we even bother using Firefox? I know plenty of my pages
> have problems rendering properly under IE (until I link in some form of script
> to accommodate that).
> As for PNG being a fluke, maybe, but I don't believe it really is.
Right. Web developers DO build their websites based on what works in the end-user's browsers. Firefox holds a huge share of those users, and MANY web developers are looking for an excuse to support OPEN technologies through Firefox's support of them. There are several thousand developers, right now, waiting for the implementation of MNG and JNG support so they can utilize this technology for the simple sake of using them.
It wasn't until Firefox's support of PNG that Adobe Photoshop supported the PNG file format. Apple Quicktime supported PNG for a while, but it didn't end up in Photoshop until Firefox (feel warm-and-fuzzy). Until Firefox supports JNG (and MNG), Adobe simply refuses to support it themselves. And once they support Microsoft's HD Photo, they may be even less inclined to support JNG there-after. Email Adobe and ask them yourself!
What we need is a Windows software developer to create an MNG animation suite. Contact the author of "GIF Construction Set" at Alchemy Mindworks <www.mindworkshop.com> and ask if he'd write "MNG Construction Set". He was the active forerunner of GIF89a support, loving the idea of animated graphics, but hated all the legal hassle.
I'm willing to bet he'd embrace MNG if his contribution and "vested interest" meant Firefox may actually support it.
expanding on my last comment (#641)
Oh, and then there's these:
viewer/converters - http://www.libpng.org/pub/mng/mngapvw.html
editors - http://www.libpng.org/pub/mng/mngaped.html
(In reply to comment #642)
> What we need is a Windows software developer to create an MNG animation suite.
> Contact the author of "GIF Construction Set" at Alchemy Mindworks
> <www.mindworkshop.com> and ask if he'd write "MNG Construction Set". He was
> the active forerunner of GIF89a support, loving the idea of animated graphics,
> but hated all the legal hassle.
> I'm willing to bet he'd embrace MNG if his contribution and "vested interest"
> meant Firefox may actually support it.
He already has
MNG/PNG Construction Set - http://www.mindworkshop.com/alchemy/pngpro.html
Animation Workshop - http://www.mindworkshop.com/alchemy/animwork.html
Is somebody maintaining seamonkey|firefox forks with MNG support and with binary packages readily downloadable? Something like a "Mozilla Advanced Project", where everything is included in the browser which (1) is implemented, (2) requested and (3) does not make the browser unstable?
Maybe also some Linux distribution maintains a better version of seamonkey|firefox.
those that say that mng isnt used forgot that it's their fault!! mng was made mostly for the web, and mozilla kill it.
nmg and this bug is open since 1999 (YES, 7 YEARS AGO!!)... if firefox did add (and didnt removed later) mng support back then, right now the use of mng would be alot higher, by removing the mng they effectively halted their spread, until today...
all this dragging along gave the opportunity to MS to catch up and create a new format and flash to be required all over the place.
those saying that flash can replace mng, please give the a flash plugin for PPC, for x86_64, for mips, etc... the world isnt just windows you know!
Mozilla blow up their opportunity back then and still do it now, the drivers dont like the mng that its open and works and prefer drag for 7 years a problem and work with a unsupported third part plugin (flash) that only recently (and with some luck) started to work fine (ie: crash's less) in firefox and, again, isnt open enough to work in every machines
to make thing worst, try to hijack the png with a same stupid idea behind the animated gif.
mng was trim down to allow the restore of its code to firefox, a maintainer of the glue code was found, the original issues were solved only to be ignored by mozilla, we all felt cheated and after 7 YEARS the problem is still here!
mozilla is becoming very arrogant to its users, specially their oldest support base, the free software community and advanced web designers.
all this bad management are making the iceweasel fork, and the alternatives opera and konqueror, becoming more attractive... all this is too stupid to be true!!
ps: if votes are useless, remove then, seen bug #374002
(In reply to comment #645)
> Is somebody maintaining seamonkey|firefox forks with MNG support and with
> binary packages readily downloadable?
I must confess, it's very disappointing to see this kind of response (closed/wontfix) to a report that is obviously very highly desired. I dare say it's even heavy handed to assume to know better than voters what is and isn't important to them. No, this isn't a democracy, but still..
This bug is a shame; the arrogance in developer comments is a disgrace; and marking it "resolved" is ridiculous. As a previous commenter duly noted, this stupidity managed to kill MNG and help flash to the position it is today. Wake up folks, these are your users here, we're the people who make websites and we know better than you what features we need!
(In reply to comment #649)
> This bug is a shame; the arrogance in developer comments is a disgrace; and
> marking it "resolved" is ridiculous. As a previous commenter duly noted, this
> stupidity managed to kill MNG and help flash to the position it is today. Wake
> up folks, these are your users here, we're the people who make websites and we
> know better than you what features we need!
Wake up guys. You shouldn't be comparing Flash/Shockwave with MNG as the former can do much much more than MNG, which has no audio, no interactivity, etc. Flash/Shockwave and MNG are 2 categories of files. You should only compare MNG with images of the same type, e.g. GIF, APNG.
Putting negative commments doesn't help in any way. So please stop bug spamming and do something else useful.
OK, so we have APNG which provides animated lossless images.
What about animated lossy images though?
Should a separate bug be filed for JNG (lossy with alpha)?
Should a new format AJNG be made to allow animated lossy images?
If that bug is wontfix, please tell me which bugs I should support for those two issues that need to be addressed in the web of today.
Simply merging everything with MNG seems simpler to me though. And it will need less code. MNG also has some support elsewhere unlike APNG and the yet to be created AJNG.
(In reply to comment #650)
> Wake up guys. You shouldn't be comparing Flash/Shockwave with MNG as the former
> can do much much more than MNG, which has no audio, no interactivity, etc.
> Flash/Shockwave and MNG are 2 categories of files. You should only compare MNG
> with images of the same type, e.g. GIF, APNG.
Excuse me. MNG -DOES- have interactivity. You also don't need a degree in computer science to make an MNG, unlike Flash.
This bug is WONTFIX not because of any personal bias or arrogance, but because there is no desire to ship MNG in Firefox in the future. It shipped in Mozilla 1.0 through 1.3, and Netscape 7.0, and had trivial usage on the web, and was backed out before Mozilla 1.4 and Firebird 0.6.1. There were a small number of MNG images on the web (less than the number of votes on this bug) most posted as examples of the tech, rather than actually being used.
Drivers considered and reconsidered MNG, staff considered it, and the decision stuck. There was an allowance made for bringing it back in CVS subject to finding an appropriate owner, but no committment was made to ship it even in that case. It wasn't the right answer, or even answering the right question, to sum up the opinions.
Ultimately, we have been successful as a project by ensuring that we have strong technical and product leadership, and making the right decisions, whether those decisions are popular or violently opposed. This is one of those decisions that will be controversial, not the first or the last, to be sure. I understand that people who are on the wrong side of such a decision will feel slighted or even rejected, but I would strongly encourage people to give others the benefit of the doubt and believe that decisions are being made in the best interests of the future of the web and of end users.
I don't know Mike. Your sentiment has all the calming reassurances one would expect from an impartial mediator, but completely lacks any concrete set of facts, details, timelines, or even summary of why MNG is not supported by Firefox.
What we DO know is that the one-and-only true opponent is the owner of imglib, who gave seemingly impossible and arbitrary goals for mnglib to fulfill, which it did, and turned out to be not good enough. No further explaination given.
What we DO know is that same imglib had also succomb to the recent PNG exploit which made Firefox look bad, while mnglib had no such affliction. It is most unfortunate that Sir Pavlov refused to adopt mnglib, allowing us to ride out the exploit laughing all the way. For that reason alone, I believe he should be relinquished of his post.
So what that Firebird 0.6 supported MNG, and MNG had less use than the votes in this poll. Firebird had less USERS than the votes in this poll. Even Shockwave Flash sites were fewer than the votes in this poll! Really, 820 is a pretty large number of multi-media sites for 2003, and broadband was only on the verge of becoming available/affordable. Also, MNG support only lasted for 28~30 months yet attracted this much attention and vested interest.
See also comment #78 and bug 163993, and compare to bug 195280. Until someone can explain why this bug was officially sanctioned as a to-do/not-do bug, requiring only 50 votes (and got over 800), and while 195280 won with only 2 votes (!!)... you will ALWAYS have conspiracy theorists abound-- myself included.
mng can be compared to flash, because many simpler flash uses could be replaced by mng... check the ad banners for example...
java cant be compared to flash, but they have a grey area were both can be used. with mng you have the same idea.
just to mention it: MNG isn't the only image format which support has been
rejected for no proper reason. there are also other great image technologies
which could be very beneficial in the web.
for example there was a "decision" going on in bugzilla about the jpeg2k format
which is the improved and newer version of the wide spreaded .jpg image files.
.jp2 files can be smaller at better quality. you can even save images lossless.
the support request was delined. there was also no proper reason given.
So the question if mozilla should support the MNG format is actually more a
question if there should be done any improvements in the imglib.
In my eyes the imglib is totally out of date. have a look at a few formats
which are beeing supported:
- there is the gif format, which has been introduced 20 years ago (1987)
- there is the jpg format, which has been introduced 15 years ago (1992)
- and hey, we also got something really modern, it's the png format, which will
celebrate it's 11th birthday in october!
If the newest part of my computer was 11 years old it would be barely worth
it's name.
(In reply to comment #656)
> just to mention it: MNG isn't the only image format which support has been
> rejected for no proper reason. there are also other great image technologies
> which could be very beneficial in the web.
> for example there was a "decision" going on in bugzilla about the jpeg2k format
> which is the improved and newer version of the wide spreaded .jpg image files.
> .jp2 files can be smaller at better quality. you can even save images lossless.
> the support request was delined. there was also no proper reason given.
> https://bugzilla.mozilla.org/show_bug.cgi?id=36351
Bug 36351 is not "declined". Its status is still "NEW".
> So the question if mozilla should support the MNG format is actually more a
> question if there should be done any improvements in the imglib.
Then file a separate bug instead of bug spamming here. Make sure you search before reporting:
(In reply to comment #654)
> See also comment #78 and bug 163993, and compare to bug 195280. Until someone
> can explain why this bug was officially sanctioned as a to-do/not-do bug,
> requiring only 50 votes (and got over 800), and while 195280 won with only 2
> votes (!!)... you will ALWAYS have conspiracy theorists abound-- myself
> included.
Funny you should mention conspiracies... This bug and all the hoopla
surrounding it somehow came up in conversation with a relative who's never used
mozilla before (he uses Safari on a Mac), and his immediate reaction was that
someone must be on the take.
I don't quite share that view; it just looks like stubbornness and pride to me.
An unwillingness to revisit a prior decision that may have been made for the
wrong reasons or under circumstances that have since changed.
I've been subscribed to this bug for all these years and still hope to see mng
readded. Back then, the reason was that the library was selected to be cut in
an effort to pare back mozilla's download size. The fact that it wasn't used
much was considered minor, as presumably reasonable folk understood that it was
a chicken-and-egg problem. It later became an issue of a lack of maintainer,
but it didn't take long before mnglib received maintenance and was even refined
to be lean and mean. Even then it still didn't receive support, but they were
seemingly out of excuses and began resorting to nebulous explanations that fail
to adequately justify the position, much like those showing up again today.
Funny that lack of mng adoption is now the focus and the reasons for this
completely ignored.
Mng is a solid technology, and the library has become very robust. Since I run
a source-based d