Obviously, this has raised the question of “what about MNG?” I’ve been surprised to see several people, who normally talk a great deal of sense, stating things about MNG which are just not true, or not relevant to the discussion. Here’s a quick Q & A:
- The MNG standard contains loads of cruft! It’s overdesigned!
- So? Even if that is true, there’s loads not to like about XHTML, SVG and XForms. We have still implemented, or are planning to implement all of them.
Besides, no-one’s asking us to write an MNG implementation. We have libmng, which is mature, stable and used in several products.
- But there are no MNG images on the web! No-one uses it.
- So? There are no APNG images either. If MNG provides a capability we want, and it’s there and mature, what’s the problem?
- Adding MNG will bloat our product with hundreds of K of code!
- MNG_BUILD_WEB_NO_JNG is a build option containing all the imporant bits of MNG for the web. It is a superset of animated GIF, and has 8-bit alpha and disposal methods. It could be added to Firefox or Mozilla for a max. 48k increase in on-disk footprint, less for download. (48k is the FreeBSD figure; better Windows compilers could probably make it smaller.)
(If this were done, the resulting PNG + MNG would still be smaller than the PNG decoder included in Mozilla 1.4, due to excellent work done by the PNG/MNG team in reducing the size of both decoders.)
- All we want is an animated GIF replacement!
- So MNG provides that. It can provide a lot more, too – but why is that a reason to actively reject it, if the size increase is so small?
- email@example.com have made it clear that they don’t want MNG.
- That decision was made when adding the MNG decoder added 300k+ to the product. Surely a six-fold size reduction merits a reconsideration of the issue?
I hold no particular candle for MNG (although I do think the guys working on it are very nice, and that the Mozilla project hasn’t treated them well). I’ve never created an MNG image, and must have viewed about three. But I must confess it surprises me that we are rejecting a mature standard library for our own implementation for the sake of 48k of on-disk footprint.
I look forward to the same principle being applied to XForms.