1<?xml version="1.0" encoding="ISO-8859-1"?> 2<!DOCTYPE article PUBLIC 3 "-//OASIS//DTD DocBook XML V4.1.2//EN" 4 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ 5<!ENTITY homepage "http://catb.org/~esr/"> 6<!ENTITY email "[email protected]"> 7]> 8<article><title>The GIFLIB Library</title> 9 10<articleinfo> 11 12<author> 13 <firstname>Eric</firstname> 14 <othername>Steven</othername> 15 <surname>Raymond</surname> 16 <affiliation> 17 <orgname><ulink url="&homepage;"> 18 Thyrsus Enterprises</ulink></orgname> 19 <address> 20 <email>&email;</email> 21 </address> 22 </affiliation> 23</author> 24<copyright> 25 <year>2012</year> 26 <holder role="mailto:&email;">Eric S. Raymond</holder> 27</copyright> 28 29</articleinfo> 30 31<!-- 32Gershon Elber, May 1991 33Eric S. Raymond, Sep 1992 34Toshio Kuratomi, May 2004 35--> 36 37<sect1><title>Introduction</title> 38 39<para>The Graphics Interchange Format(c) is the Copyright property of 40CompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServe 41Incorporated.</para> 42 43<para>This document explains the GIF library code in directory `lib'. The 44code is collected into a service library which is used in all the utilities in 45`util'. It can be used in any application needs to read/write the GIF 46file format. This document does <emphasis>not</emphasis> explain the GIF file 47format and assumes you know it, at least to the level of the GIF file 48structure.</para> 49 50</sect1> 51<sect1><title>Credit and Blame</title> 52 53<para>Gershon wrote: "This library was written because I couldn't find 54anything similar and I wanted one. I was inspired by the RLE Utah tool kit, 55which I hoped to port to an IBM PC, but found it to be too machine specific, 56and its compression ratio too low. I compromised on the GIF format, but I am 57not sure how long 8 bits per pixel will be enough."</para> 58 59<para>During his first spell of maintainership between 1989 and 1994, Eric 60S. Raymond (aka "ESR") ported the code to Unix, wrote the high-level 61DGIfSlurp()/EGifSpew() interface, rationalized the internal data 62structures, and did a lot of general cleanup and refactoring to 63improve the code quality.</para> 64 65<para>Between 1994 and 2012 Toshio Kuratomi fixed various tool bugs, 66build-recipe problems and rare segfaults. He partially untangled the 67somewhat misdesigned extension-block handling in earlier versions. 68The core code was very stable during this period.</para> 69 70<para>During his second spell of maintainership, ESR fixed the 71extension API, made the library re-entrant and thread-safe, wrote a 72regression-test suite, greatly improved the documentation, and 73discarded a lot of obsolete code.</para> 74 75</sect1> 76<sect1><title>The GIF descriptor</title> 77 78<para>When a GIF file is opened, a GIF file descriptor is created which 79is a pointer to GifFileType structure as follows:</para> 80 81<programlisting> 82typedef struct GifFileType { 83 GifWord SWidth, SHeight; /* Size of virtual canvas */ 84 GifWord SColorResolution; /* How many colors can we generate? */ 85 GifWord SBackGroundColor; /* Background color for virtual canvas */ 86 GifByteType AspectByte; /* Used to compute pixel aspect ratio */ 87 ColorMapObject *SColorMap; /* Global colormap, NULL if nonexistent. */ 88 int ImageCount; /* Number of current image (both APIs) */ 89 GifImageDesc Image; /* Current image (low-level API) */ 90 SavedImage *SavedImages; /* Image sequence (high-level API) */ 91 int ExtensionBlockCount; /* Count extensions past last image */ 92 ExtensionBlock *ExtensionBlocks; /* Extensions past last image */ 93 int Error; /* Last error condition reported */ 94 void *UserData; /* hook to attach user data (TVT) */ 95 void *Private; /* Don't mess with this! */ 96} GifFileType; 97</programlisting> 98 99<para>This structure was copied from gif_lib.h - the header file for the GIF 100library. Any application program that uses the libgif.a library should 101include it. Members beginning with S refer to the GIF screen; others hold 102properties of the current image (a GIF file may have more than one image) 103or point to allocated store used by various routines.</para> 104 105<para>The user almost never writes into this structure (exception: it 106may occasionally be useful to alter things in the SavedImages array and 107Trailing member), but can read any of these items at any time it is 108valid (Image information is invalid until the first image has been read; 109read; SavedImages information is valid only after a DGifSlurp() call).</para> 110 111<para>As the library needs to keep its own internal data, a Private pointer 112to hidden data is included. Applications should ignore this.</para> 113 114<para>The library allocates its own memory dynamically, on opening of files, 115and releases that once closed. The user is never required to allocate 116any memory for any of the functions of this library, and is almost never 117required to free them directly. The "almost" in the latter clause is because 118one manual free() call may be required on a failed file close; see the 119documentation of DGifClose() and EGifClose() for details.</para> 120 121<para>Here is a module summary:</para> 122 123<variablelist> 124<varlistentry> 125<term>egif_lib.c</term> 126<listitem> 127<para>Encoding routines, all prefixed with E.</para> 128</listitem> 129</varlistentry> 130 131<varlistentry> 132<term>dgif_lib.c</term> 133<listitem> 134<para>Decoding routines, all prefixed with D.</para> 135</listitem> 136</varlistentry> 137 138<varlistentry> 139<term>gifalloc.c</term> 140<listitem> 141<para>Routines for colormap handling and GIF record allocation.</para> 142</listitem> 143</varlistentry> 144 145<varlistentry> 146<term>gif_font.c</term> 147<listitem> 148<para>The 8x8 font table for the GIF utility font.</para> 149</listitem> 150</varlistentry> 151</variablelist> 152 153<para>The library includes a sixth file of hash-function code which is accessed 154internally only.</para> 155 156<para>Most of the routines return GIF_ERROR (see gif_lib.h) if something 157went wrong, GIF_OK otherwise. After an error return, all routines that 158take a pointer-to-GifFileType argument set the Error member with a code that 159can be interpreted into an explanatory string with the function 160GifErrorString() in gif_err.c. (The exception to this is the 161DGifClose() and EGifClose() routines, which deallocate that structure 162and must therefore return any error code through a pointer argument.)</para> 163 164</sect1> 165<sect1><title>Decoding (dgif_lib.c)</title> 166 167<para>The following functions are used to set up input from a GIF:</para> 168 169<programlisting id="DGifOpenFileName"> 170GifFileType *DGifOpenFileName(char *GifFileName, int *ErrorCode) 171</programlisting> 172 173<para>Open a new GIF file (in binary mode, if under Windows) using the 174given GifFileName, and read its Screen information.</para> 175 176<para>If any error occurs, NULL is returned and ErrorCode is set (if 177non-NULL).</para> 178 179<programlisting id="DGifOpenFileHandle"> 180GifFileType *DGifOpenFileHandle(int FileHandle, int *ErrorCode) 181</programlisting> 182 183<para>Open a new GIF file using the given FileHandle, and read its Screen 184information.</para> 185 186<para>If any error occurs, NULL is returned and ErrorCode is set (if 187non-NULL).</para> 188 189<para>Once you have acquired a handle on a GIF, the high-level 190function</para> 191 192<programlisting id="DGifSlurp"> 193int DGifSlurp(GifFileType) 194</programlisting> 195 196<para>reads the rest of a complete (possibly multi-image) GIF file from the 197indicated file handle into in-core allocated structures. It returns 198GIF_OK on success, GIF_ERROR on failure; on failure, the Error member 199will be set.</para> 200 201<para>Once you have done this, all image, raster, and extension-block 202data in the GIF is accessable in the SavedImages member (see the 203structures in gif_lib.h). When you have modified the image to taste, 204write it out with EGifSpew().</para> 205 206<para>One detail that may not be clear from just looking at the 207structures is how extension blocks and sub-blocks are stored. Each 208ExtensionBlock structure represents an extension data block. Those 209with a zero function code represent continuation data blocks attached 210to previous blocks with nonzero function codes.</para> 211 212<para>You can read from a GIF file through a function hook. Initialize 213with </para> 214 215<programlisting id="DGifOpen"> 216GifFileType *DGifOpen(void *userPtr, InputFunc readFunc, int *ErrorCode) 217</programlisting> 218 219<para>and see the library header file for the type of InputFunc.</para> 220 221<para>There is also a set of deprecated functions for sequential I/O, 222described in a later section.</para> 223</sect1> 224<sect1><title>Encoding (egif_lib.c)</title> 225 226<para>The high-level function</para> 227 228<programlisting id="EGifSpew"> 229int EGifSpew(GifFileType *GifFile) 230</programlisting> 231 232<para>writes a complete (possibly multi-image) GIF file to the indicated file 233handle from in-core allocated structures created by a previous DGifSlurp() 234or equivalent operations. Its argument is a GIF file descriptor, which 235imnplicitly points to storage previously allocated by DGifSlurp().</para> 236 237<para>The file is written with a GIF87 stamp unless it contains one of the four 238special extension blocks defined in GIF89, in which case it is written 239with a GIF89 stamp.</para> 240 241<para>EGifSpew() finishes by closing the GIF (writing a termination 242record to it) and deallocating the associated storage.</para> 243 244<para>You can write to a GIF file through a function hook. Initialize 245with </para> 246 247<programlisting id="EGifOpen"> 248GifFileType *EGifOpen(void *userPtr, OutputFunc writeFunc, int *ErrorCode) 249</programlisting> 250 251<para>and see the library header file for the type of OutputFunc.</para> 252 253<para>There is also a set of deprecated functions for sequential I/O, 254described in a later section.</para> 255</sect1> 256<sect1><title>Color map handling and allocation routines</title> 257 258<programlisting id="GifMakeMapObject"> 259ColorMapObject *GifMakeMapObject(int ColorCount, GifColorType *ColorMap) 260</programlisting> 261 262<para>Allocate storage for a color map object with the given number of 263RGB triplet slots. If the second argument is non-NULL, initialize 264the color table portion of the new map from it. Returns NULL if 265memory is exhausted or if the size is not a power of 2 <= 256.</para> 266 267<programlisting id="GifFreeMapObject"> 268void GifFreeMapObject(ColorMapObject *Object) 269</programlisting> 270 271<para>Free the storage occupied by a ColorMapObject that is no longer 272needed.</para> 273 274<programlisting id="GifUnionColorMap"> 275ColorMapObject *GifUnionColorMap( 276 ColorMapObject *ColorIn1, ColorMapObject *ColorIn2, 277 GifPixelType ColorTransIn2[]) 278</programlisting> 279 280<para>Create the union of two given color maps and return it. If the result 281won't fit into 256 colors, NULL is returned, the allocated union 282otherwise. ColorIn1 is copied as it to ColorUnion, while colors from 283ColorIn2 are copied if they didn't exist before. ColorTransIn2 maps 284the old ColorIn2 into ColorUnion color map table.</para> 285 286<programlisting id="GifAttachImage"> 287SavedImage *GifAttachImage(GifFileType *GifFile) 288</programlisting> 289 290<para>Add an image block to the SavedImages array. The image block is 291initially zeroed out. This image block will be seen by any following 292EGifSpew() calls.</para> 293 294</sect1> 295<sect1><title>Graphics control extension handling</title> 296 297<para>GIF89 added a graphics control extension block, but versions 298of GIFLIB before 5.0 weren't much help in reading or modifying them. 299This lack has been remedied with the following structure and functions:</para> 300 301<programlisting> 302typedef struct GraphicsControlBlock { 303 int DisposalMode; 304#define DISPOSAL_UNSPECIFIED 0 /* No disposal specified. */ 305#define DISPOSE_DO_NOT 1 /* Leave image in place */ 306#define DISPOSE_BACKGROUND 2 /* Set area too background color */ 307#define DISPOSE_PREVIOUS 3 /* Restore to previous content */ 308 bool UserInputFlag; /* User confirmation required before disposal */ 309 int DelayTime; /* pre-display delay in 0.01sec units */ 310 int TransparentColor; /* Palette index for transparency, -1 if none */ 311#define NO_TRANSPARENT_COLOR -1 312} GraphicsControlBlock; 313 314int DGifSavedExtensionToGCB(GifFileType *GifFile, 315 int ImageIndex, 316 GraphicsControlBlock *GCB); 317int EGifGCBToSavedExtension(const GraphicsControlBlock *GCB, 318 GifFileType *GifFile, 319 int ImageIndex); 320</programlisting> 321 322<para>With these functions you can extract the data from a graphics 323control extension associated with a saved image into a 324GraphicsControlBlock, modify it, and write it back out. Note that if 325the specified saved image doesn't have a graphics control extension, 326DGifSavedExtensionToGCB() will fill the GCB with default values and 327return GIF_ERROR (which can be ignored); EGifGCBToSavedExtension() 328will create a new leading extension block.</para> 329 330</sect1> 331<sect1><title>Error Handling (gif_err.c)</title> 332 333<programlisting> 334int GifErrorString(int ErrCode) 335</programlisting> 336 337<para>Returns a sting describing the specified GIFLIB error code. 338Return NULL if the argument is not a valid error code.</para> 339 340</sect1> 341<sect1><title>The GIF Utility Font</title> 342 343<para>The 8x8 utility font used in the (obsolete, no longer installed) 344gifecho and gifcolor lives in the library module gif_font.c, in a 345table called GifAsciiTable. The library header file includes suitable 346externs and defines.</para> 347 348<para>The GIF utility font support includes entry points for drawing legends 349on in-core images, drawing boxes and rectangles, and boxing text. 350These entry points are as follows:</para> 351 352<programlisting id="GifDrawText"> 353void GifDrawText8x8( 354 SavedImage *Image, 355 const int x, const int y, 356 const char *legend, 357 const int color) 358</programlisting> 359 360<para>Draw text using the 8x8 utility font on the saved image. Upper 361left corner of the text is at image pixel (x, y). Use the specified 362color index.</para> 363 364<programlisting id="GifDrawBox"> 365void GifDrawBox(SavedImage *Image, 366 const int x, const int y, 367 const int w, const int h, 368 const int color) 369</programlisting> 370 371<para>Draw a box on the saved image. Upper left corner of the box is at 372image pixels (x, y), width is w, height is h. Use the specified color 373index.</para> 374 375<programlisting id="GifDrawRectangle"> 376void GifDrawRectangle(SavedImage *Image, 377 const int x, const int y, 378 const int w, const int h, 379 const int color) 380</programlisting> 381 382<para>Draw a (filled) rectangle on the saved image. Upper left corner of 383the box is at image pixels (x, y), width is w, height is h. Use the 384specified color index.</para> 385 386<programlisting id="GifDrawBoxedText"> 387void GifDrawBoxedText8x8(SavedImage *Image, 388 const int x, const int y, 389 const char *legend, 390 const int border, 391 const int bg, const int fg) 392</programlisting> 393 394<para>Draw text on a filled rectangle. The rectangle will be sized to fit 395the text, with upper left hand corner at (x, y) on the saved image. 396The `border' argument specifies a pixel margin around the text. The 397`bg' argument is the color table index to fill the rectangle with; 398`fg' is the color table index to draw the text with.</para> 399 400<para>This function interprets some characters in the legend string 401specially. A tab (\t) is interpreted as a command to center the 402following text in the box. A carriage return (\r) is interpreted 403as a request for a line break.</para> 404 405</sect1> 406<sect1><title>Error codes</title> 407 408<para>Errors as reported from the GIFLIB library are divided to two major 409categories: the encoder (errors prefixed by E_GIF_ERR), and the 410decoder (errors prefixed by D_GIF_ERR). This document explains them 411briefly.</para> 412 413<sect2><title>Encoding errors</title> 414 415<variablelist> 416<varlistentry> 417<term><errorname>E_GIF_ERR_OPEN_FAILED</errorname></term> 418<listitem> 419 <para>Message printed using PrintGifError: "Failed to open given file" 420 IO error result when attempt to open the given GIF file.</para> 421</listitem> 422</varlistentry> 423 424<varlistentry> 425<term><errorname>E_GIF_ERR_WRITE_FAILED</errorname></term> 426<listitem> 427 <para>Message printed using PrintGifError: "Failed to Write to given file" 428 IO error result when attempt to write to the given GIF file.</para> 429</listitem> 430</varlistentry> 431 432<varlistentry> 433<term><errorname>E_GIF_ERR_HAS_SCRN_DSCR</errorname></term> 434<listitem> 435 <para>Message printed using PrintGifError: "Screen Descriptor 436 already been set" Attempt to write second screen descriptor to same 437 GIF file. GIF file should have exactly one screen descriptor which 438 should be set directly after the file is opened.</para> 439</listitem> 440</varlistentry> 441 442<varlistentry> 443<term><errorname>E_GIF_ERR_HAS_IMAG_DSCR</errorname></term> 444<listitem> 445 <para>Message printed using PrintGifError: "Image Descriptor is still active" 446 Image descriptor should be sent before and image dump, and no second 447 image descriptor should be sent before current image dump ended. This error 448 occurred probably because current image was not complete.</para> 449</listitem> 450</varlistentry> 451 452<varlistentry> 453<term><errorname>E_GIF_ERR_NO_COLOR_MAP</errorname></term> 454<listitem> 455 <para>Message printed using PrintGifError: "Neither Global Nor 456 Local color map" An image must have either global (screen) or local 457 (image) color map. Neither were given in this case.</para> 458</listitem> 459</varlistentry> 460 461<varlistentry> 462<term><errorname>E_GIF_ERR_DATA_TOO_BIG</errorname></term> 463<listitem> 464 <para>Message printed using PrintGifError: "#Pixels bigger than 465 Width * Height" The number of pixels dumped for this image is 466 bigger than specified by image Height times image Width.</para> 467</listitem> 468</varlistentry> 469 470<varlistentry> 471<term><errorname>E_GIF_ERR_NOT_ENOUGH_MEM</errorname></term> 472<listitem> 473 <para>Message printed using PrintGifError: "Fail to allocate 474 required memory" Once an attemp is made to open GIF file, special 475 structures are allocated to hold internal data for it. If 476 allocation fails this error is returned.</para> 477</listitem> 478</varlistentry> 479 480<varlistentry> 481<term><errorname>E_GIF_ERR_DISK_IS_FULL</errorname></term> 482<listitem> 483 <para>Message printed using PrintGifError: "Write failed (disk full?)" 484 Writing encoded data failed.</para> 485</listitem> 486</varlistentry> 487 488<varlistentry> 489<term><errorname>E_GIF_ERR_CLOSE_FAILED</errorname></term> 490<listitem> 491 <para>Message printed using PrintGifError: "Failed to close given file" 492 Closing file failed.</para> 493</listitem> 494</varlistentry> 495 496<varlistentry> 497<term><errorname> E_GIF_ERR_NOT_WRITEABLE</errorname></term> 498<listitem> 499 <para>Message printed using PrintGifError: "Given file was not 500 opened for write" GIF files can be opened both for read (DGIF part 501 of library) and write (EGIF part of library). This error occurs 502 when a file is opened for read (using DGIF) is given to one of the 503 encoding (EGIF) routines.</para> 504</listitem> 505</varlistentry> 506 507</variablelist> 508 509</sect2> 510<sect2><title>Decoding errors</title> 511 512<variablelist> 513<varlistentry> 514<term><errorname>D_GIF_ERR_OPEN_FAILED</errorname></term> 515<listitem> 516 <para>Message printed using PrintGifError: "Failed to open given file" 517 IO error result when attempt to open the given GIF file.</para> 518</listitem> 519</varlistentry> 520 521<varlistentry> 522<term><errorname>D_GIF_ERR_READ_FAILED</errorname></term> 523<listitem> 524 <para>Message printed using PrintGifError: "Failed to read from given file" 525 IO error result when attempt to write to the given GIF file.</para> 526</listitem> 527</varlistentry> 528 529<varlistentry> 530<term><errorname>D_GIF_ERR_NOT_GIF_FILE</errorname></term> 531<listitem> 532 <para>Message printed using PrintGifError: "Data is not a GIF file" 533 GIF files should have special stamp identifies them as such, If that stamp 534 is not found, this error is issued.</para> 535</listitem> 536</varlistentry> 537 538<varlistentry> 539<term><errorname>D_GIF_ERR_NO_SCRN_DSCR</errorname></term> 540<listitem> 541 <para>Message printed using PrintGifError: "No screen descriptor detected" 542 Each GIF file should have screen descriptor in its header. This error will 543 be generated if no such descriptor was found.</para> 544</listitem> 545</varlistentry> 546 547<varlistentry> 548<term><errorname>D_GIF_ERR_NO_IMAG_DSCR</errorname></term> 549<listitem> 550 <para>Message printed using PrintGifError: "No image descriptor detected" 551 Each image should have image descriptor in its header. This error will 552 be generated if no such descriptor was found.</para> 553</listitem> 554</varlistentry> 555 556<varlistentry> 557<term><errorname>D_GIF_ERR_NO_COLOR_MAP</errorname></term> 558<listitem> 559 <para>Message printed using PrintGifError: "Neither global nor 560 local color map" An image must have either global (screen) or local 561 (image) color map. Neither were given in this case.</para> 562</listitem> 563</varlistentry> 564 565<varlistentry> 566<term><errorname>D_GIF_ERR_WRONG_RECORD</errorname></term> 567<listitem> 568 <para>Message printed using PrintGifError: "Wrong record type detected" 569 Each record in a GIF file has a special identifier in its header. If the 570 record has an unrecognized identifier, this error is generated.</para> 571</listitem> 572</varlistentry> 573 574<varlistentry> 575 <term><errorname>D_GIF_ERR_DATA_TOO_BIG</errorname></term> 576<listitem> 577 <para>Message printed using PrintGifError: "Number of pixels bigger than 578 width * height" The number of pixels dumped for this image is 579 bigger than specified by image Height times image Width.</para> 580</listitem> 581</varlistentry> 582 583<varlistentry> 584<term><errorname>D_GIF_ERR_NOT_ENOUGH_MEM</errorname></term> 585<listitem> 586 <para>Message printed using PrintGifError: "Failed to allocate 587 required memory" Once an attemp is made to open GIF file, special 588 structures are allocated to hold internal data for it. If 589 allocation fails this error is returned.</para> 590</listitem> 591</varlistentry> 592 593<varlistentry> 594<term><errorname>D_GIF_ERR_CLOSE_FAILED</errorname></term> 595<listitem> 596 <para>Message printed using PrintGifError: "Failed to close given file" 597 Closing file failed.</para> 598</listitem> 599</varlistentry> 600 601<varlistentry> 602<term><errorname>D_GIF_ERR_NOT_READABLE</errorname></term> 603<listitem> 604 <para>Message printed using PrintGifError: "Given file was not 605 opened for read" GIF files can be opened both for read (DGIF part 606 of library) and write (EGIF part of library). This error occurs 607 when a file is opened for write (using EGIF) is given to one of the 608 decoding (DGIF) routines.</para> 609</listitem> 610</varlistentry> 611 612<varlistentry> 613<term><errorname>D_GIF_ERR_IMAGE_DEFECT</errorname></term> 614<listitem> 615 <para>Message printed using PrintGifError: "Image is defective, 616 decoding aborted" This error is generated, once the decoding failed 617 - probably image is defect.</para> 618</listitem> 619</varlistentry> 620 621<varlistentry> 622<term><errorname>D_GIF_ERR_EOF_TOO_SOON</errorname></term> 623<listitem> 624 <para>Message printed using PrintGifError: "Image EOF detected, 625 before image complete" This error is generated once EOF errorname 626 is detected in encoded image before all the pixels (Width * 627 Height) has be decoded.</para> 628</listitem> 629</varlistentry> 630</variablelist> 631 632</sect2> 633</sect1> 634<sect1><title>Utility support library</title> 635 636<para>These functions are not part of the core GIF library. They are part 637of the getarg library that supports the utilities.</para> 638 639<sect2><title>Error Handling</title> 640 641<programlisting id="PrintGifError"> 642void PrintGifError(void) 643</programlisting> 644 645<para>Print a one-line diagnostic on the last giflib error to stderr.</para> 646 647</sect2> 648<sect2><title>Command Line Parsing</title> 649 650<programlisting id="GAGetArgs"> 651bool GAGetArgs(int argc, char **argv, char *CtrlStr, ...) 652</programlisting> 653 654<para>Main routine of this module. Given argc & argv as received by 655the main procedure, the command line CtrlStr, and the addresses of 656all parameters, parse the command line, and update the parameters.</para> 657 658<para>The CtrlStr defines what types of variables should follow. Look at the 659beginning of getarg.c for exact usage.</para> 660 661<para>Returns false if successful, returns true on failure.</para> 662 663<programlisting id="GAPrintErrMsg"> 664void GAPrintErrMsg(int Error) 665</programlisting> 666 667<para>If an error occurred in GAGetARgs, this routine may be used to print 668one line diagnostic to stderr.</para> 669 670<programlisting id="GAPrintHowTo"> 671void GAPrintHowTo(char *CtrlStr) 672</programlisting> 673 674<para>Given the same CtrlStr as for GAGetArgs, can be used to print a one line 675'how to use'. </para> 676 677</sect2> 678</sect1> 679<sect1 id="sequential"><title>Sequential access</title> 680 681<para>If you are handling large images on an extremely memory-limited 682machine, you may need to use the following functions for sequential 683read and write. It's better to avoid them and use the simpler 684DGifSlurp()/EGifSpew() interface.</para> 685 686<sect2><title>Sequential reading</title> 687 688<programlisting id="DGifGetScreenDesc"> 689int DGifGetScreenDesc(GifFileType *GifFile) 690</programlisting> 691 692<para>Reads the screen information into the GifFile structure. Note this 693routine is automatically called once a file is opened, and therefore 694usually need not be called explicitly.</para> 695 696<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 697 698<programlisting id="DGifGetRecordType"> 699int DGifGetRecordType(GifFileType *GifFile, GifRecordType *GifType) 700</programlisting> 701 702<para>As the GIF file can have different records in arbitrary order, this 703routine should be called once the file was open to detect the next 704record type, and act upon it. It can return these types in GifType:</para> 705 706<variablelist> 707<varlistentry> 708<term>1. UndefinedRecordType </term> 709<listitem> 710<para>something is wrong!</para> 711</listitem> 712</varlistentry> 713 714<varlistentry> 715<term>2. ScreenDescRecordType </term> 716<listitem> 717<para>screen information. As the screen info is automatically read in when the file is open, this should not happen.</para> 718</listitem> 719</varlistentry> 720 721<varlistentry> 722<term>3. ImageDescRecordType </term> 723<listitem> 724<para> next record is an image descriptor.</para> 725</listitem> 726</varlistentry> 727 728<varlistentry> 729<term>4. ExtensionRecordType</term> 730<listitem> 731<para> next record is extension block.</para> 732</listitem> 733</varlistentry> 734 735<varlistentry> 736<term>5. TrailerRecordType</term> 737<listitem> 738<para>last record reached, can close the file.</para> 739</listitem> 740</varlistentry> 741</variablelist> 742 743<para>The first two types can usually be ignored. The function 744returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 745 746<programlisting id="DGifGetImageDesc"> 747int DGifGetImageDesc(GifFileType *GifFile) 748</programlisting> 749 750<para>Reads image information into the GifFile structure. 751Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 752 753<programlisting id="DGifGetLine"> 754int DGifGetLine(GifFileType *GifFile, PixelType *GifLine, int GifLineLen) 755</programlisting> 756 757<para>Load a block of pixels from the GIF file. The line can be 758of any length. More than that, this routine may be interleaved with 759DGifGetPixel until all pixels have been read.</para> 760 761<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 762 763<programlisting> 764int DGifGetPixel(GifFileType *GifFile, PixelType GifPixel) 765</programlisting> 766 767<para>Loads one pixel from the GIF file. This routine may be interleaved 768with <link linkend="DGifGetLine">DGifGetLine()</link>, until all pixels are 769read. Because of the overhead per each call, use of this routine is 770not recommended.</para> 771 772<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 773 774<programlisting> 775int DGifGetExtension( 776 GifFileType *GifFile, 777 int *GifExtCode, 778 ByteType **GifExtension) 779</programlisting> 780 781<para>Loads an extension block from the GIF file. Extension blocks 782are optional in GIF files. This routine should be followed by 783<link linkend="DGifGetExtensionNext">DGifGetExtensionNext</link>.</para> 784 785<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 786 787<para><programlisting id="DGifGetExtensionNext"> 788int DGifGetExtensionNext(GifFileType *GifFile, ByteType **GifExtension) 789</programlisting> 790 791As extensions may contain more than one block, use this routine to 792continue after DGifGetExtension, until *GifExtension is NULL.</para> 793 794<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 795 796<programlisting> 797int DGifGetCode( 798 GifFileType *GifFile, 799 int *GifCodeSize, ByteType **GifCodeBlock) 800</programlisting> 801 802<para>It sometimes may be desired to read the compressed code as is 803without decoding it. This routine does exactly that (with 804DGifGetCodeNext), and can be used instead of DGifGetLine.</para> 805 806<para>This compressed code information can be written out using the 807EGifPutCode/EGifPutCodeNext sequence (see gifpos.c for example). 808Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 809 810<programlisting id="DGifGetCodeNext"> 811int DGifGetCodeNext(GifFileType *GifFile, ByteType **GifCodeBlock) 812</programlisting> 813 814<para>See DGifGetCode above.</para> 815 816<programlisting id="DGifGetLZCodes"> 817int DGifGetLZCodes(GifFileType *GifFile, int *GifCode) 818</programlisting> 819 820<para>This routine can be called instead of DGifGetLine/DGifGetPixel or 821DGifGetCode/DGifGetCodeNext to get the 12 bits LZ codes of the images. 822It will be used mainly for debugging purposes (see GifText.c for 823example).</para> 824 825<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 826 827<programlisting id="DGifCloseFile"> 828int DGifCloseFile(GifFileType *GifFile, int *ErrorCode) 829</programlisting> 830 831<para>Write a termination block to the GIF, close the GIF file and 832free all memory allocated for managing it. GifFile should not be used after 833this routine has been called.</para> 834 835<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise. When 836GIF_ERROR is returned, the diagnostic error code is left in ErrorCode. 837The GifFile structure is unconditionally freed.</para> 838 839<para>(Note: In versions before 5.1.0, the ErrorCode argument was 840absent and the GifFile structure was not freed so that the 841diagnostic error code will remain accessible in GifFile->Error. 842This behavior was changed because it caused problems for the 843implementation of library wrappers in dynamic languages.)</para> 844 845<programlisting id="DGetGifVersion"> 846const char * DGifGetGifVersion(GifFileType *GifFile) 847</programlisting> 848 849<para>Get the GIF version collected during sequential read. This is 850handy for sequential API users who want to set an encoder's version 851from a decoder (e.g. for gif resizing). For the all-at-once users this 852isn't necessary because gif encoder inspects all the extension blocks, 853but sequential users do not have that luxury.</para> 854 855</sect2> 856<sect2><title>Sequential writing</title> 857 858<para>If you are handling large images on a memory-limited machine, you may need 859to use the following functions for sequential write.</para> 860 861<programlisting id="EGifOpenFileName"> 862GifFileType *EGifOpenFileName(char *GifFileName, bool GifTestExistance, int *ErrorCode) 863</programlisting> 864 865<para>Open a new GIF file using the given GifFileName (in binary mode, 866if under Windows). If GifTestExistance is TRUE, and file exists, the 867file is not destroyed, and NULL returned.</para> 868 869<para>If any error occurs, NULL is returned and the ErrorCode is set.</para> 870 871<programlisting id="EGifOpenFileHandle"> 872GifFileType *EGifOpenFileHandle(int GifFileHandle, int *ErrorCode) 873</programlisting> 874 875<para>Open a new GIF file using the given GifFileHandle.</para> 876 877<para>If any error occurs, NULL is returned and ErrorCode is set.</para> 878 879<para>The file is opened in binary mode, and its buffer size is set to 880FILE_BUFFER_SIZE bytes.</para> 881 882<programlisting> 883char *EGifGetGifVersion(GifFileType *GifFile) 884</programlisting> 885 886<para>That version computation is available through this function.</para> 887 888<programlisting id="EGifSetGifVersion"> 889void EGifSetGifVersion(GifFileType *GifFile, bool gif89) 890</programlisting> 891 892<para>Set the GIF type, to GIF89 if the argument is true and GIF87 if 893it is false. The default type is GIF87. This function may be called 894aftert the GifFile record is allocated but before 895EGifPutScreenDesc().</para> 896 897<programlisting> 898int EGifPutScreenDesc(GifFileType *GifFile, 899 const int GifWidth, const GifHeight, 900 const int GifColorRes, const int GifBackGround, 901 ColorMapObject *GifColorMap) 902</programlisting> 903 904<para>Update the GifFile Screen parameters, in GifFile structure and in 905the real file. If error occurs, returns GIF_ERROR (see gif_lib.h), 906otherwise GIF_OK.</para> 907 908<para>This routine should be called immediately after the GIF file was 909opened.</para> 910 911<programlisting> 912int EGifPutImageDesc(GifFileType *GifFile, 913 const int GifLeft, const int GifTop, 914 const int GifWidth, const GifHeight, 915 const bool GifInterlace, 916 ColorMapObject *GifColorMap) 917</programlisting> 918 919<para>Update GifFile Image parameters, in GifFile structure and in the real 920file. if error occurs returns GIF_ERROR (see gif_lib.h), otherwise 921GIF_OK.</para> 922 923<para>This routine should be called each time a new image must be 924dumped to the file.</para> 925 926<programlisting id="EGifPutLine"> 927int EGifPutLine(GifFileType *GifFile, PixelType *GifLine, int GifLineLen) 928</programlisting> 929 930<para>Dumps a block of pixels out to the GIF file. The slab can be of 931any length. More than that, this routine may be interleaved with 932<link linkend="EGifPutPixel">EGifPutPixel()</link>, until all pixels 933have been sent.</para> 934 935<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 936 937<programlisting id="EGifPutPixel"> 938int EGifPutPixel(GifFileType *GifFile, const PixelType GifPixel) 939</programlisting> 940 941<para>Dumps one pixel to the GIF file. This routine may be interleaved with 942<link linkend="EGifPutLine">EGifPutLine()</link>, until all pixels were sent. 943Because of the overhead for each call, use of this routine is not 944recommended.</para> 945 946<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 947 948<programlisting id="EGifPutComment"> 949int EGifPutComment(GifFileType *GifFile, char *GifComment) 950</programlisting> 951 952<para>Uses extension GIF records to save a string as a comment is the file. 953The extension code is 'C' (for Comment).</para> 954 955<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 956 957<programlisting id="EGifPutExtension"> 958int EGifPutExtension( 959 GifFileType *GifFile, 960 const int GifExtCode, 961 const int GifExtLen, 962 void *GifExtension) 963</programlisting> 964 965<para>Dumps the given extension block into the GIF file. Extension blocks 966are optional in GIF file. Extension blocks of more than 255 bytes or 967more than one block are not supported in this function. Please use 968EGifPutExtensionFirst, EGifPutExtensionBlock, and EGifPutExtensionTrailer 969if your extension blocks may fall into this category.</para> 970 971<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 972 973<programlisting id="EGifPutExtensionLeader"> 974int EGifPutExtensionLeader( 975 GifFileType * GifFile, 976 const int GifExtCode) 977</programlisting> 978 979<para>Dumps the beginning of a GIF extension block to a GIF file. 980Extension blocks are optional in GIF files. This function outputs the 981type code information necessary for a GIF extension block.</para> 982 983<para>Further blocks of the GIF Extension should be dumped using 984EGifPutExtensionBlock. When finished with this extension block, 985EGifPutExtensionTrailer should be called to output the block termination.</para> 986 987<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 988 989<programlisting id="EGifPutExtensionBlock"> 990int EGifPutExtensionBlock( 991 GifFileType * GifFile, 992 const int GifExtLen, 993 const VoidPtr GifExtension) 994</programlisting> 995 996<para>Dumps a subblock of a GIF extension to a GIF File; should be 997used only following an initializing call to EGifPutExtensionLeader(). 998Extension blocks are optional in GIF files. This function will write 999the Extension Data in GifExtension to the file as a subblock of the 1000preceding Extension Block. Repeat calling of this function until all 1001data subblocks have been output.</para> 1002 1003<para>Note that EGifPutExtensionLeader needs to be called before any 1004calls to this function. EGifPutExtensionTrailer should be called to 1005finish the Extension block after all data subblocks have been 1006output.</para> 1007 1008<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1009 1010<programlisting id="EGifPutExtensionTrailer"> 1011int EGifPutExtensionTrailer( 1012 GifFileType * GifFile, 1013 const VoidPtr GifExtension) 1014</programlisting> 1015 1016<para>Dumps the GIF extension block terminator to a GIF File to end 1017the current Extension block.</para> 1018 1019<para>Note that a call to EGifPutExtensionLeader is needed to open the GIF 1020Extension Block prior to calling this function.</para> 1021 1022<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1023 1024<programlisting id="EGifPutCode"> 1025int EGifPutCode( 1026 GifFileType *GifFile, 1027 int *GifCodeSize, 1028 ByteType **GifCodeBlock) 1029</programlisting> 1030 1031<para>It sometimes may be desired to write the compressed code as is 1032without decoding it. For example a filter for a GIF file that change 1033only screen size (GifPos), does not need the exact pixel values. 1034Piping out the compressed image as is makes this process much 1035faster.</para> 1036 1037<para>This routine does exactly that (with EGifPutCodeNext), and can be 1038used instead of EGifPutLine. You'll usually use this with the 1039DGifGetCode/DgifGetCodeNext routines, which reads the compressed 1040code, while EGifPutCode/EGifPutCodeNext write it out. See gifpos.c 1041for example.</para> 1042 1043<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1044 1045<programlisting id="EGifPutCodeNext"> 1046int EGifPutCodeNext(GifFileType *GifFile, ByteType **GifCodeBlock) 1047</programlisting> 1048 1049<para>See EGifPutCode above.</para> 1050 1051<programlisting id="EGifCloseFile"> 1052int EGifCloseFile(GifFileType *GifFile) 1053</programlisting> 1054 1055<para>Write a termination block to the GIF, close the GIF file, and 1056free all memory allocated for managing it. GifFile should not be used 1057after this routine has been called.</para> 1058 1059<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise. When 1060GIF_ERROR is returned, the diagnostic error code is left in ErrorCode. 1061The GifFile structure is unconditionally freed.</para> 1062 1063<para>(Note: In versions before 5.1.0, the ErrorCode argument was 1064absent and the GifFile structure was not freed so that the 1065diagnostic error code will remain accessible in GifFile->Error. 1066This behavior was changed because it caused problems for the 1067implementation of library wrappers in dynamic languages.)</para> 1068</sect2> 1069 1070</sect1> 1071<sect1 id="compatibility"><title>Forward and Backward Compatibility</title> 1072 1073<para>Except for some details of extension-block handling and the addition 1074of read/write function hooks, the DGifSlurp()/EGifSpew() interface has 1075been stable since 1990. It is expected to remain so.</para> 1076 1077<para>However, the signatures of the file-opener functions were changed in 5.0 1078in order to make the library fully reentrant and thread-safe - earlier library 1079versions did not feature the final pointer-to-error-code argument in 1080DGifOpen() and friends. For the same reason, the static storage queried by 1081GifLastError() in older versions is gone, and that function abolished.</para> 1082 1083<para>The library header contains some version #defines you can use if you 1084need to condition your code so it can compile with different library 1085versions</para> 1086 1087<para>Versions up to 4.1.6 defined a GIF_LIB_VERSION macro that was 1088string-valued with a tricky format to parse. This macro has been 1089retired.</para> 1090 1091<para>Versions after 4.1.6 define integer-valued GIFLIB_MAJOR, GIFLIB_MINOR, 1092and GIFLIB_RELEASE macros for the three components of the version. See the 1093NEWS file in the GIFLIB distribution to track API changes.</para> 1094 1095<para>The following functions are entirely new:</para> 1096 1097<itemizedlist> 1098<listitem><para>New functions DGifSavedExtensionToGCB() and 1099EGifGCBToSavedExtension() make it easy to read and edit GIF89 graphics 1100control blocks in saved images.</para></listitem> 1101<listitem><para>The new function DGifGetGifVersion() is convenient 1102for people doing sequential reads.</para></listitem> 1103</itemizedlist> 1104 1105<para>A few changes in behavior were introduced in 5.0:</para> 1106 1107<sect2><title>General behavior</title> 1108 1109<itemizedlist> 1110<listitem><para>The library is now fully re-entrant and 1111thread-safe.</para></listitem> 1112</itemizedlist> 1113<itemizedlist> 1114<listitem><para> All functions exported by this library now have DGif, 1115EGif, or Gif as a name prefix.</para></listitem> 1116<listitem><para>The default GIF version to write is now computed at 1117write time from the types of an image's extension blocks. (Formerly 1118EGifSpew() behaved this way, but the sequential-writing code didn't.) 1119The result of this computation is available through the new function 1120EGifGetGifVersion().</para></listitem> 1121</itemizedlist> 1122 1123</sect2> 1124<sect2><title>In documented functions:</title> 1125 1126<itemizedlist> 1127<listitem><para>GIF file openers and closers - DGifOpenFileName(), 1128DGifOpenFileHandle(), DGifOpen(), DGifClose(), EGifOpenFileName(), 1129EGifOpenFileHandle(), EGifOpen(), and EGifClose() - all now take a 1130final integer address argument. If non-null, this is used to pass 1131back an error code when the function returns NULL.</para></listitem> 1132<listitem><para>EGifSlurp() and EGifSpew() read and write 1133extension blocks trailing after the last image, handle interlaced 1134images properly.</para></listitem> 1135<listitem><para>EGifPutExtensionFirst() has been replaced by 1136EGifPutExtensionLeader(); the difference is the new function doesn't 1137take an optional block, it just writes a block 1138leader.</para></listitem> 1139<listitem><para>EGifPutExtensionNext() has been replaced by 1140EGifPutExtensionBlock(); the difference is that the new function does 1141not take and then discard a function code argument.</para></listitem> 1142<listitem><para>EGifPutExtensionLast() has been replaced by 1143EGifPutExtensionTrailer(); all it does is write the terminator 1144block. Split your old EGifPutExtensionLast() calls into 1145EGifPutExtensionBlock() followed by 1146EGifPutExtensionTrailer().</para></listitem> 1147</itemizedlist> 1148 1149</sect2> 1150<sect2><title>In undocumented functions:</title> 1151 1152<itemizedlist> 1153<listitem><para>Some undocumented functions have been renamed. 1154AddExtensionBlock() is now GifAddExtensionBlock(), and takes an additional 1155function code argument. ApplyTranslation() is now GifApplyTranslation(); 1156FreeExtension() has become GifFreeExtensions() and takes a different argument 1157type; MakeSavedImage() is now GifMakeSavedImage(), FreeSavedImages() is 1158now GifFreeSavedImages(), and BitSize() is now GifBitSize().</para></listitem> 1159<listitem><para>Three documented functions - MakeMapObject(), 1160FreeMapObject(), and UnionColorMap() - have been renamed to 1161GifMakeMapObject(), GifFreeMapObject(), and GifUnionColorMap() 1162respectively.</para></listitem> 1163</itemizedlist> 1164 1165</sect2> 1166<sect2><title>Error handling:</title> 1167 1168<itemizedlist> 1169<listitem><para>Library error handling no longer uses a static cell to 1170store the last error code registered; that made the library 1171thread-unsafe.</para></listitem> 1172<listitem><para>For functions other than GIF file openers, the Error 1173code is now put in an Error member of the GifFileType 1174structure.</para></listitem> 1175<listitem><para>The GifError() and 1176GifLastError() functions that referenced that static cell are gone, 1177and the GifErrorString() function introduced in the 4.2 release now 1178takes an explicit error code argument.</para></listitem> 1179</itemizedlist> 1180</sect2> 1181</sect1> 1182<sect1><title>Skeletons of GIF filters</title> 1183 1184<para>If you are developing on a virtual-memory OS such as most flavors of 1185UNIX, or are otherwise sure of having enough memory to keep all of GIFs you 1186need to operate in core, writing a filter is trivial. See the file 1187gifsponge.c in util.</para> 1188 1189<para>A sequential filter skeleton will usually look like the example file 1190giffilter.c in util.</para> 1191 1192<para>Please look at the utilities in the util directory for more ideas once 1193you feel comfortable with these skeletons. Also try to follow the coding 1194standards of this package if you want the maintainer to officially add your new 1195utility to it.</para> 1196 1197</sect1> 1198<sect1><title>Unimplemented features</title> 1199 1200<para>Some features of the original GIF specification have not stood the 1201test of time. This library mostly ignores them, but they are described 1202here for completeness.</para> 1203 1204<para>The GIF standard fails to be explicit about a small but crucial detail: 1205the unsigned two-byte integer fields in it are little-endian.</para> 1206 1207<para>The GIF format seems to have been designed with the idea that viewers 1208would render multiple images in a GIF on a common canvas, giving an effect like 1209a picture wall. The 'logical screen descriptor block' (LSDB), 6 bytes right 1210after the 6-byte GIF stamp and version header at the beginning of a 1211GIF file, includes both two-byte canvas width and canvas height 1212fields and a canvas background color. Each image, besides height and 1213width, also has 'left' and 'top' cordinates specifying where it is to 1214be placed on the canvas.</para> 1215 1216<para>GIFLIB can read and set these fields; the gifpos and giftool 1217utilities will enable you to script such changes. But browsers and 1218modern image viewers ignore them. Nowadays multiple-image GIFs are 1219generally used either as animations in which each sub-image is a frame 1220or as image libraries, with the GIF client handling compositing into 1221some canvas about which the GIF format holds no information.</para> 1222 1223<para>Another feature of the LSDB that is generally ignored is the 1224pixel aspect ratio byte. Until 5.0, GIFLIB ignored this flag on input 1225and zeroed it on output; now it is read and preserved if present. The 1226GIF standard doesn't give a rationale for it, but it seems likely that 1227the designers intended it for representing image captures from the 1228analog television of the day, which had rectangular pixel-equivalents.</para> 1229 1230<para>Yet another ignored feature of both the LSDB and sub-images is 1231the sort flag, which is supposed to signal whether the colors in the 1232associated color map are sorted by decreasing importance in case the 1233display device can only render a limited number of them. This feature 1234reflected the high cost of dual-port memory at the time the GIF 1235specification was written in the late 1980s. That kind of limit 1236disappeared in the mid-1990s. Until 5.0, GIFLIB ignored this flag on 1237input and zeroed it on output; now it is read and preserved if 1238present.</para> 1239 1240<para>Finally, the plaintext extension block. This is an extension block 1241that contains instructions for overlaying text captions on a following image. 1242GIFLIB treats these blocks as raw data, not attempting to parse out the 1243location and text data.</para> 1244</sect1> 1245</article> 1246