TODO

   1 Edit utils to get rid of use of all deprecated Functions.
   2 - icon2gif has MakeExtension
   3
   4 Check how the library uses MakeExtension and AddExtensionBlock.  I have the
   5 vague impression that the library currently requires a two step process:
   6 MakeExtension adds the Function type to deprecated: SavedImage->Function.
   7 Then, AddExtensionBlock must be called to add it to SavedImage->ExtensionBlock
   8 (The Function type is passed in via the SavedImage->Function so that's why we
   9 have to do that step first.  Need to untangle those functions.)
  10 - Why do we have so many colormaps?  GifFile->SColorMap is the screen
  11   descriptor colormap.
  12   GifFile->Image.ColorMap ?
  13   GifFile->SavedImages[x].ColorMap = Local colormap
  14
  15 - Also check how we push the Extensions out to a gif file.  We should never
  16 touch SavedImage->Function when we write to file.  All information is saved in
  17 the ExtensionBlock.
  18
  19 EGifPutExtension*/DGifGetExtension* needs to be looked at.  Why is there a
  20 First, Next, Last, and generic version of these functions?  Does the
  21 application programmer really need to know all this?  Shouldn't the library
  22 take care of it?  Also, they should use WRITE rather than fwrite directly to
  23 output the data.
  24
  25 Make sure we set pointers that we don't fill to NULL.  (gifalloc.c seems
  26 pretty clean.  But GifFile isn't allocated in gifalloc.c)
  27
  28 I found a reported bug about libungif not handling interlaced images
  29 correctly.  However, the latest library seems to work.  Need to figure out
  30 what change fixed it and if it fixed it correctly or in a manner that is
  31 apt to break later.
  32
  33 Make sure tmpnam is secure in gifinto.c (Use mkstemp if possible..)
  34
  35 Audit for sprintf => snprintf
  36
  37 # Make sure all malloc calls check their return value.
  38 Still need to check dev2gif.c (Know there's problems there)
  39 dgif_lib.c
  40 egif_lib.c
  41
  42 Merge the windows changes from the last cvs version.  Contact Lennie Araki
  43 about whether he is interested in maintaining the windows changes
  44
  45 Run the utils through indent
  46
  47 Make sure the backlog is really all merged and then delete things from there.
  48 Some is in my mailbox at home.  Others were on the old CVS server.  I think
  49 most of the CVS backlog has been merged but I've just started ot look at
  50 the stuff at home.
  51
  52 Start thinking about function naming and standardizing things.  The MakeXXX,
  53 FreeXXX is a good step, but should things operate on GifFiles or the interior
  54 data structures?  What about the functions in the rest of the library?
  55 Should I be able to (MakeGifFileType(), FreeGifFileType(GifFile *) just like
  56 MakeMapObject?)
  57
  58 Start thinking about namespacing all our code!  This will break so many things
  59 in simple ways.  Need to deprecate so we can do this in 5.0
  60
  61 Release 4.1.3
  62
  63 sync giflib
  64
  65 =======
  66
  67 Theoretical release 5.0
  68
  69 Move utilities into a separate package.
  70   - Move GIF_ERROR and GIF_MESSAGE from gif_lib.h into getarg.
  71   - Move qprintf into getarg
  72   - Rename getarg utilsupport.a and move to the util directory.
  73
  74 Now that we have sourceforge hosting, look into putting documentation and a
  75 website onto sourceforge.  Don't know how much stuff I want to sync into this,
  76 though, as I keep hoping gif's will take their last gasp and die.  (Why do we
  77 need gif now that we have png and mng?)
  78
  79 ======
  80
  81 Besides fixing bugs, what's really needed is for someone to work out how to
  82 calculate a colormap for writing gifs from rgb sources.  Right now, an rgb
  83 source that has only two colors (b/w) is being converted into an 8 bit gif....
  84 Which is horrendously wasteful without compression.
  85
  86 Any volunteers?
  87
  88 =======
  89 The Present Extension code is pretty hacky.  It looks like giflib's ability to
  90 do Extension code was added on at a later time and also was not implemented
  91 entirely in conformance with the gif89a spec.  I've hacked it further to make
  92 it conform to the spec, but it would benefit greatly from a complete rewrite.
  93
  94 If there is ever a version-5.0 of this library (with API level changes), this
  95 should definitely be one of the areas that gets worked on.
  96
  97 =======
  98 Documentation needs updating to reflect additions to the API.  This would best
  99 be done with auto-extraction from the SOURCES....
 100
 101 =======
 102 [UPDATE at bottom]
 103 Here's a change to the library code that has been proposed:  Pulling known
 104 extensions (comment blocks, etc) out of the Extensions array and putting them
 105 in actual places within the GifType structure so application programmers don't
 106 have to search through the Extension array for them.
 107
 108 I'm not sure how I want to implemement this yet -- Actually removing them from
 109 the extension array would break the API compatibility with libungif.  Making
 110 copies would waste resources needlessly.  Making convenience links with the
 111 idea of deprecating the access of the extension block directly for standard
 112 features would be okay, but creates extra work in the long run -- really we
 113 need to put the convenience links into the current Extension array.
 114
 115 We have to decide where in the structure each extension belongs, generalize
 116 the AddExtensionBlock function to be able to add the extensionblock to any
 117 area of the structure, rework the gif writing code to place the structures
 118 where they belong, rework the code writing to the Extension Array so that it
 119 can handle links as well as blocks.
 120
 121 And on the other hand, it could turn out that putting extensions into the main
 122 structure is not intuitive to everyone.  Extensions are "extensions" and
 123 people may want to look for them grouped together.... I suppose this could
 124 either mean leaving everything in the extension array, or creating a new
 125 extension field that has the extensions dangling off of it (comment, gifanim
 126 stuff, unknown, etc.)  This is okay except that it'd be best to have real
 127 copies of the extension in the fields instead of links (so that we could make
 128 arrays rather than arrays of pointers.)
 129
 130 [UPDATE:1998 3 Dec]
 131 After reading through the gif89a specification, I'm not sure this is all that
 132 great.  It seems that each image in a gif stream needs to have separate
 133 extension blocks.  This means that an animated gif will have a Graphics
 134 Extension Block for each Image in the animation.  Linking this up to the
 135 GifFileType is wrong.  Making a link in each SaveFile is correct, but will
 136 take space that won't be needed when that particular extension doesn't appear
 137 in this file....
 138
 139 Unless someone wants to correct me here, I don't think I'm going to implement
 140 this.