Edit utils to get rid of use of all deprecated Functions. - icon2gif has MakeExtension Check how the library uses MakeExtension and AddExtensionBlock. I have the vague impression that the library currently requires a two step process: MakeExtension adds the Function type to deprecated: SavedImage->Function. Then, AddExtensionBlock must be called to add it to SavedImage->ExtensionBlock (The Function type is passed in via the SavedImage->Function so that's why we have to do that step first. Need to untangle those functions.) - Why do we have so many colormaps? GifFile->SColorMap is the screen descriptor colormap. GifFile->Image.ColorMap ? GifFile->SavedImages[x].ColorMap = Local colormap - Also check how we push the Extensions out to a gif file. We should never touch SavedImage->Function when we write to file. All information is saved in the ExtensionBlock. EGifPutExtension*/DGifGetExtension* needs to be looked at. Why is there a First, Next, Last, and generic version of these functions? Does the application programmer really need to know all this? Shouldn't the library take care of it? Also, they should use WRITE rather than fwrite directly to output the data. Make sure we set pointers that we don't fill to NULL. (gifalloc.c seems pretty clean. But GifFile isn't allocated in gifalloc.c) I found a reported bug about libungif not handling interlaced images correctly. However, the latest library seems to work. Need to figure out what change fixed it and if it fixed it correctly or in a manner that is apt to break later. Make sure tmpnam is secure in gifinto.c (Use mkstemp if possible..) Audit for sprintf => snprintf # Make sure all malloc calls check their return value. Still need to check dev2gif.c (Know there's problems there) dgif_lib.c egif_lib.c Merge the windows changes from the last cvs version. Contact Lennie Araki about whether he is interested in maintaining the windows changes Run the utils through indent Make sure the backlog is really all merged and then delete things from there. Some is in my mailbox at home. Others were on the old CVS server. I think most of the CVS backlog has been merged but I've just started ot look at the stuff at home. Start thinking about function naming and standardizing things. The MakeXXX, FreeXXX is a good step, but should things operate on GifFiles or the interior data structures? What about the functions in the rest of the library? Should I be able to (MakeGifFileType(), FreeGifFileType(GifFile *) just like MakeMapObject?) Start thinking about namespacing all our code! This will break so many things in simple ways. Need to deprecate so we can do this in 5.0 Release 4.1.3 sync giflib ======= Theoretical release 5.0 Move utilities into a separate package. - Move GIF_ERROR and GIF_MESSAGE from gif_lib.h into getarg. - Move qprintf into getarg - Rename getarg utilsupport.a and move to the util directory. Now that we have sourceforge hosting, look into putting documentation and a website onto sourceforge. Don't know how much stuff I want to sync into this, though, as I keep hoping gif's will take their last gasp and die. (Why do we need gif now that we have png and mng?) ====== Besides fixing bugs, what's really needed is for someone to work out how to calculate a colormap for writing gifs from rgb sources. Right now, an rgb source that has only two colors (b/w) is being converted into an 8 bit gif.... Which is horrendously wasteful without compression. Any volunteers? ======= The Present Extension code is pretty hacky. It looks like giflib's ability to do Extension code was added on at a later time and also was not implemented entirely in conformance with the gif89a spec. I've hacked it further to make it conform to the spec, but it would benefit greatly from a complete rewrite. If there is ever a version-5.0 of this library (with API level changes), this should definitely be one of the areas that gets worked on. ======= Documentation needs updating to reflect additions to the API. This would best be done with auto-extraction from the SOURCES.... ======= [UPDATE at bottom] Here's a change to the library code that has been proposed: Pulling known extensions (comment blocks, etc) out of the Extensions array and putting them in actual places within the GifType structure so application programmers don't have to search through the Extension array for them. I'm not sure how I want to implemement this yet -- Actually removing them from the extension array would break the API compatibility with libungif. Making copies would waste resources needlessly. Making convenience links with the idea of deprecating the access of the extension block directly for standard features would be okay, but creates extra work in the long run -- really we need to put the convenience links into the current Extension array. We have to decide where in the structure each extension belongs, generalize the AddExtensionBlock function to be able to add the extensionblock to any area of the structure, rework the gif writing code to place the structures where they belong, rework the code writing to the Extension Array so that it can handle links as well as blocks. And on the other hand, it could turn out that putting extensions into the main structure is not intuitive to everyone. Extensions are "extensions" and people may want to look for them grouped together.... I suppose this could either mean leaving everything in the extension array, or creating a new extension field that has the extensions dangling off of it (comment, gifanim stuff, unknown, etc.) This is okay except that it'd be best to have real copies of the extension in the fields instead of links (so that we could make arrays rather than arrays of pointers.) [UPDATE:1998 3 Dec] After reading through the gif89a specification, I'm not sure this is all that great. It seems that each image in a gif stream needs to have separate extension blocks. This means that an animated gif will have a Graphics Extension Block for each Image in the animation. Linking this up to the GifFileType is wrong. Making a link in each SaveFile is correct, but will take space that won't be needed when that particular extension doesn't appear in this file.... Unless someone wants to correct me here, I don't think I'm going to implement this.