XEmacs + GIF

Martin> Unisys http://www.unisys.com/LeadStory/lzwfaq.html says: Unisys> License Information on GIF and Other LZW-based Unisys> Technologies Unisys> hardware providing LZW conversion capability (for Unisys> example, downloaded software used for creating/displaying Unisys> GIF images). That certainly looks like Unisys is trying to claim decompression is covered.... GNU http://www.gnu.org/philosophy/gif.html says: Martin> Decoding GIFs is a different issue. The Unisys and IBM Martin> patents are both written in such a way that they do not Martin> apply to a program which can only uncompress LZW format Martin> and cannot compress. Therefore we can and will include Martin> support for displaying GIF files in GNU software. That looks clear enough. (BTW, I can't see how a patent that applied to the decoding algorithm wouldn't apply to every decompression algorithm known to man; they're all basically sed scripts....) Ghostscript provides a trivial LZW-compatible encoder, by which I think is meant an encoder which for any given input produces a bitstream that an LZW-decoder will invert into the original input. So Jareth could provide the capability for making pseudo-GIFs in his library, I think. The size of the file would be about the same as a raw PPM, I would think. I'm not going to post the code (I'll send it on request) because it's trivial, except for the parts that integrate it with the internal filter mechanism of Ghostscript, and the code is not GPL. The description of the algorithm is below. I once got Ghostscript to display a "GIF" file produced with this encoder; I don't know what xv would do with it but I guess it would be OK. (I don't have a capable Ghostscript around; there is no longer a GIF output device provided, presumably for patent reasons. It would take me a while to cobble one up....) As long as Jareth arranges that all of the various formats use filters satisfying a certain API, and GIFlib provides only the trivial encoder to fake out decoders for formats that specify LZW, he should be OK. Even if a plug-compatible LZW compressor should appear, if Jareth doesn't provide it and doesn't try to claim responsibility (ie, copyright) for it, I don't see where the hook for legal liability could possibly be. /* Copyright (C) 1994, 1995, 1996 Aladdin Enterprises. All rights reserved. This file is part of Aladdin Ghostscript. Aladdin Ghostscript is distributed with NO WARRANTY OF ANY KIND. No author or distributor accepts any responsibility for the consequences of using it, or for whether it serves any particular purpose or works at all, unless he or she says so in writing. Refer to the Aladdin Ghostscript Free Public License (the "License") for full details. Every copy of Aladdin Ghostscript must include a copy of the License, normally in a plain ASCII text file named PUBLIC. The License grants you the right to copy, modify and redistribute Aladdin Ghostscript, but only under certain conditions described in the License. Among other things, the License requires that the copyright notice and this notice be preserved on all copies. */ /* slzwce.c */ /* Simple encoder compatible with LZW decoding filter */ #include "stdio_.h" /* includes std.h */ #include "gdebug.h" #include "strimpl.h" #include "slzwx.h" /* ------ Alternate LZWEncode filter implementation ------ */ /* The encoded data stream produced by this implementation of the LZWEncode filter consists of a sequence of 9-bit data elements. These elements are packed into bytes in big-endian order, e.g. the elements 100000000 001100001 occurring at the very beginning of the data stream would be packed into bytes as 10000000 00011000 01...... The first bit of each data element is a control bit. If the control bit is 0, the remaining 8 bits of the data element are a data byte. If the control bit is 1, the remaining 8 bits of the data element define a control function: 1 00000000 synchronization mark, see below 1 00000001 end of data 1 xxxxxxxx not used (all other values) The synchronization mark occurs at the beginning of the data stream, and at least once every 254 data bytes thereafter. This format is derived from basic principles of data encoding (the use of a separate flag bit to distinguish out-of-band control information from data per se, and the use of a periodic synchronization mark to help verify the validity of a data stream); it has no relationship to data compression. It is, however, compatible with LZW decompressors. It produces output that is approximately 9/8 times the size of the input. */