On Mon, 2005-09-19 at 16:14 -0700, Toshio Kuratomi wrote: > The history of libungif and giflib is that GNOME 1 (via imlib) began to > use giflib for its GIF support. Red Hat and other distributions > realized this would cause problems due to the Unisys LZW patent. I > found a posting that showed how to create uncompressed gifs that > wouldn't invoke the patent (Unisys patented the encoder and combined > decoder+encoder... Not a standalone decoder) and created libungif as a > drop in replacement for giflib to circumvent the patent issues. > > As time went on, bugfixes and a desire for new features led to a need > for API/ABI changes. I sent fixes and enhancements to Eric Raymond to > coordinate a release so we could continue to have compatible libraries. > He wasn't interested in maintaining giflib any more so I took over > maintenence of that. The sourceforge page reflects that libungif is a > superset of esr's giflib but not the present sourceforge hosted giflib. > > I'll go carify the web page now. I'm glad to hear that giflib has an active maintainer now. Replacing libungif with a maintained module makes a lot of sense. However, looking at my distribution, it doesn't look like a whole lot of software actually uses this library. This is a pity, as it's better to have just one image loader available instead of multiple, especially when the inevitable security errata happens. When we did the gif loaders for gdk-pixbuf, we looked at using libungif. However, it didn't support two vital features -- incremental loading and sane threading support. I imagine that we could switch away from our current code to libgif if those features appeared. Are you doing new development on it? Is this in your roadmap at all? Thanks, -Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
