I'm writing to request support for JIF be added to mozilla. Information on JIF is at: http://jeff.cafe.net/jif JIF is a format designed to be a complete replacement for GIF (animated and still) that is very easy to add to an application that supports GIF and PNG. JIF simply replaces the LZW compressed raster data in GIF with zlib compressed data (which is what PNG uses). Applications supporting JIF should be arriving fairly soon (the next release of the popular GraphicConverter on the Mac should support JIF - several developers are working on adding JIF support to their apps currently). I can provide some help for this, but I would like to know if the mozilla developers are receptive to this. For example, I could patch libgif to support JIF fairly easily, but I would like to know if such patches would be taken in by the mozilla developers. The amount of work to bring JIF support up to the level of GIF support should be fairly minimal since JIF has the exact same set of features as GIF and is parsed the same way, with the exception of compressed raster data. Jeff Tupper firstname.lastname@example.org
Jeff: The image is now componentized and you could write your own jif decoder component. This would be much cleaner than modifying the current gif decoder module. -pn
Writing a separate decoder is possible, but perhaps I wasn't clear before (http://jeff.cafe.net/jif has more details) - JIF is parsed *the same way* as GIF. There are two differences: "JIF99a" is the signature (instead of "GIF87a" or "GIF89a") and zlib is used in place of LZW. The rest of the format is the exact same (logical screens, extension blocks, graphic control extensions, image descriptors, ... all the exact same to minimize the amount of changes needed to add JIF support to a GIF supporting application). Would writing a separate JIF decoder allow animations and looping? Is there concerns about code bloat? The image parsing code is the same for both formats - just raster decoding
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
As this bug is so old and no new activity, I'm going to resolve as won't fix, reporter please reopen if you believe this is still an issue
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
Umm, email@example.com, the JIF format still exists and isn't in the code base. I can't see any reason why you should close RFEs that have seen no activity.
Reopening in light of that. and pav can always use more bugs.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
One reason to WONTFIX this is that PNGs are the way forward, but since we now have PPM support (ish) that really isn't a good reason... Tupper: Are you still interested in working on this?
What a flurry of activity. JIF is still moving along; a handful of applications support it now. It isn't an epic quest or anything - I have more than enough to do! It is just the simplest way away from GIF, as stated on the JIF page. PNG doesn't include all of the features of GIF yet also includes new features (which means that software has to be reworked to use PNG properly). I don't have anything against PNG, but it is useful to have a simple alternative to GIF. All that should require changing is to allow JIFs wherever GIFs are allowed and to check the header for "JIF99a" and then invoke zlib instead of your LZW code where appropriate. (See the JIF page for more details and some sample code.)
tor: could you help?
Personally I don't see much point to JIF and don't see it catching on. However if someone is interested in adding support, it wouldn't be that hard to make the GIF decoder also listen for x-jif mimetype, record which type of file it's decoding, and call the appropriate decompression routine (do_lzw() in the current code). "case gif_lzw_start" in gif_write() might also need modification. This should stay as enhancement/future. Reassigning to firstname.lastname@example.org would probably be appropriate, as I doubt pavlov is interested in doing this work.
JIF is a pretty trivial format: the main point is that those who want to do GIF-like things and avoid LZW licensing can do so. The number of man- hours we've spent discussing this is probably comparable to the number of man-hours it would take to implement it for someone familiar with the source. I'm pretty sure the cost / benefit ratio is pretty good, given the low cost of implementation. I get semi-regular email from people asking how to use JIF; I'd gladly point them towards a compliant browser. I might be able to do the modifications in the future, but I'm a full-time computer graphics Ph.D. student that is behind in his studies... If someone is interested in doing this, I could provide licenses to any of my software (http://www.peda.com/) [GrafEq, Tess, and Poly betas do] that produce JIFs.
tupper, I can understand your frustration trying to convince other Mozilla contributors for months about the value of your idea. This is a well-know stigma that inventors face. For an independent observer, the real issue so far appears to be that adding JIF is going to be more beneficial to JIF than Mozilla. Once it get to this stage, only a patch can make a significant difference. Following what tor said earlier, here is a link to get started. It will point to the exact spots where to start investigating: http://lxr.mozilla.org/seamonkey/ident?i=do_lzw Since the footprint of a variant 'do_zlib' is likely to be minuscule if the existing png version can be re-used, a patch may stand a chance to be accepted -- thereby bringing your JIF to the masses. This a constructive way forward that I can suggest.
The chance of this getting added at this point is zero, especially considering that the format seems to be completely dead.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.