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