external/giflib 4.1.6

1 files changed, 140 insertions, 0 deletions

diff --git a/giflib-4.1.6/TODO b/giflib-4.1.6/TODO
new file mode 100644
index 0000000..780739c
--- /dev/null
+++ b/giflib-4.1.6/TODO
@@ -0,0 +1,140 @@
+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.