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 "esr@thyrsus.com"> 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 iff 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 gifecho and gifcolor lives in the library 344module gif_font.c, in a table called GifAsciiTable. The library header file 345includes suitable externs and defines.</para> 346 347<para>The GIF utility font support includes entry points for drawing legends 348on in-core images, drawing boxes and rectangles, and boxing text. 349These entry points are as follows:</para> 350 351<programlisting id="GifDrawText"> 352void GifDrawText8x8( 353 SavedImage *Image, 354 const int x, const int y, 355 const char *legend, 356 const int color) 357</programlisting> 358 359<para>Draw text using the 8x8 utility font on the saved image. Upper 360left corner of the text is at image pixel (x, y). Use the specified 361color index.</para> 362 363<programlisting id="GifDrawBox"> 364void GifDrawBox(SavedImage *Image, 365 const int x, const int y, 366 const int w, const int h, 367 const int color) 368</programlisting> 369 370<para>Draw a box on the saved image. Upper left corner of the box is at 371image pixels (x, y), width is w, height is h. Use the specified color 372index.</para> 373 374<programlisting id="GifDrawRectangle"> 375void GifDrawRectangle(SavedImage *Image, 376 const int x, const int y, 377 const int w, const int h, 378 const int color) 379</programlisting> 380 381<para>Draw a (filled) rectangle on the saved image. Upper left corner of 382the box is at image pixels (x, y), width is w, height is h. Use the 383specified color index.</para> 384 385<programlisting id="GifDrawBoxedText"> 386void GifDrawBoxedText8x8(SavedImage *Image, 387 const int x, const int y, 388 const char *legend, 389 const int border, 390 const int bg, const int fg) 391</programlisting> 392 393<para>Draw text on a filled rectangle. The rectangle will be sized to fit 394the text, with upper left hand corner at (x, y) on the saved image. 395The `border' argument specifies a pixel margin around the text. The 396`bg' argument is the color table index to fill the rectangle with; 397`fg' is the color table index to draw the text with.</para> 398 399<para>This function interprets some characters in the legend string 400specially. A tab (\t) is interpreted as a command to center the 401following text in the box. A carriage return (\r) is interpreted 402as a request for a line break.</para> 403 404</sect1> 405<sect1><title>Error codes</title> 406 407<para>Errors as reported from the GIFLIB library are divided to two major 408categories: the encoder (errors prefixed by E_GIF_ERR), and the 409decoder (errors prefixed by D_GIF_ERR). This document explains them 410briefly.</para> 411 412<sect2><title>Encoding errors</title> 413 414<variablelist> 415<varlistentry> 416<term><errorname>E_GIF_ERR_OPEN_FAILED</errorname></term> 417<listitem> 418 <para>Message printed using PrintGifError: "Failed to open given file" 419 IO error result when attempt to open the given GIF file.</para> 420</listitem> 421</varlistentry> 422 423<varlistentry> 424<term><errorname>E_GIF_ERR_WRITE_FAILED</errorname></term> 425<listitem> 426 <para>Message printed using PrintGifError: "Failed to Write to given file" 427 IO error result when attempt to write to the given GIF file.</para> 428</listitem> 429</varlistentry> 430 431<varlistentry> 432<term><errorname>E_GIF_ERR_HAS_SCRN_DSCR</errorname></term> 433<listitem> 434 <para>Message printed using PrintGifError: "Screen Descriptor 435 already been set" Attempt to write second screen descriptor to same 436 GIF file. GIF file should have exactly one screen descriptor which 437 should be set directly after the file is opened.</para> 438</listitem> 439</varlistentry> 440 441<varlistentry> 442<term><errorname>E_GIF_ERR_HAS_IMAG_DSCR</errorname></term> 443<listitem> 444 <para>Message printed using PrintGifError: "Image Descriptor is still active" 445 Image descriptor should be sent before and image dump, and no second 446 image descriptor should be sent before current image dump ended. This error 447 occurred probably because current image was not complete.</para> 448</listitem> 449</varlistentry> 450 451<varlistentry> 452<term><errorname>E_GIF_ERR_NO_COLOR_MAP</errorname></term> 453<listitem> 454 <para>Message printed using PrintGifError: "Neither Global Nor 455 Local color map" An image must have either global (screen) or local 456 (image) color map. Neither were given in this case.</para> 457</listitem> 458</varlistentry> 459 460<varlistentry> 461<term><errorname>E_GIF_ERR_DATA_TOO_BIG</errorname></term> 462<listitem> 463 <para>Message printed using PrintGifError: "#Pixels bigger than 464 Width * Height" The number of pixels dumped for this image is 465 bigger than specified by image Height times image Width.</para> 466</listitem> 467</varlistentry> 468 469<varlistentry> 470<term><errorname>E_GIF_ERR_NOT_ENOUGH_MEM</errorname></term> 471<listitem> 472 <para>Message printed using PrintGifError: "Fail to allocate 473 required memory" Once an attemp is made to open GIF file, special 474 structures are allocated to hold internal data for it. If 475 allocation fails this error is returned.</para> 476</listitem> 477</varlistentry> 478 479<varlistentry> 480<term><errorname>E_GIF_ERR_DISK_IS_FULL</errorname></term> 481<listitem> 482 <para>Message printed using PrintGifError: "Write failed (disk full?)" 483 Writing encoded data failed.</para> 484</listitem> 485</varlistentry> 486 487<varlistentry> 488<term><errorname>E_GIF_ERR_CLOSE_FAILED</errorname></term> 489<listitem> 490 <para>Message printed using PrintGifError: "Failed to close given file" 491 Closing file failed.</para> 492</listitem> 493</varlistentry> 494 495<varlistentry> 496<term><errorname> E_GIF_ERR_NOT_WRITEABLE</errorname></term> 497<listitem> 498 <para>Message printed using PrintGifError: "Given file was not 499 opened for write" GIF files can be opened both for read (DGIF part 500 of library) and write (EGIF part of library). This error occurs 501 when a file is opened for read (using DGIF) is given to one of the 502 encoding (EGIF) routines.</para> 503</listitem> 504</varlistentry> 505 506</variablelist> 507 508</sect2> 509<sect2><title>Decoding errors</title> 510 511<variablelist> 512<varlistentry> 513<term><errorname>D_GIF_ERR_OPEN_FAILED</errorname></term> 514<listitem> 515 <para>Message printed using PrintGifError: "Failed to open given file" 516 IO error result when attempt to open the given GIF file.</para> 517</listitem> 518</varlistentry> 519 520<varlistentry> 521<term><errorname>D_GIF_ERR_READ_FAILED</errorname></term> 522<listitem> 523 <para>Message printed using PrintGifError: "Failed to read from given file" 524 IO error result when attempt to write to the given GIF file.</para> 525</listitem> 526</varlistentry> 527 528<varlistentry> 529<term><errorname>D_GIF_ERR_NOT_GIF_FILE</errorname></term> 530<listitem> 531 <para>Message printed using PrintGifError: "Data is not a GIF file" 532 GIF files should have special stamp identifies them as such, If that stamp 533 is not found, this error is issued.</para> 534</listitem> 535</varlistentry> 536 537<varlistentry> 538<term><errorname>D_GIF_ERR_NO_SCRN_DSCR</errorname></term> 539<listitem> 540 <para>Message printed using PrintGifError: "No screen descriptor detected" 541 Each GIF file should have screen descriptor in its header. This error will 542 be generated if no such descriptor was found.</para> 543</listitem> 544</varlistentry> 545 546<varlistentry> 547<term><errorname>D_GIF_ERR_NO_IMAG_DSCR</errorname></term> 548<listitem> 549 <para>Message printed using PrintGifError: "No image descriptor detected" 550 Each image should have image descriptor in its header. This error will 551 be generated if no such descriptor was found.</para> 552</listitem> 553</varlistentry> 554 555<varlistentry> 556<term><errorname>D_GIF_ERR_NO_COLOR_MAP</errorname></term> 557<listitem> 558 <para>Message printed using PrintGifError: "Neither global nor 559 local color map" An image must have either global (screen) or local 560 (image) color map. Neither were given in this case.</para> 561</listitem> 562</varlistentry> 563 564<varlistentry> 565<term><errorname>D_GIF_ERR_WRONG_RECORD</errorname></term> 566<listitem> 567 <para>Message printed using PrintGifError: "Wrong record type detected" 568 Each record in a GIF file has a special identifier in its header. If the 569 record has an unrecognized identifier, this error is generated.</para> 570</listitem> 571</varlistentry> 572 573<varlistentry> 574 <term><errorname>D_GIF_ERR_DATA_TOO_BIG</errorname></term> 575<listitem> 576 <para>Message printed using PrintGifError: "Number of pixels bigger than 577 width * height" The number of pixels dumped for this image is 578 bigger than specified by image Height times image Width.</para> 579</listitem> 580</varlistentry> 581 582<varlistentry> 583<term><errorname>D_GIF_ERR_NOT_ENOUGH_MEM</errorname></term> 584<listitem> 585 <para>Message printed using PrintGifError: "Failed to allocate 586 required memory" Once an attemp is made to open GIF file, special 587 structures are allocated to hold internal data for it. If 588 allocation fails this error is returned.</para> 589</listitem> 590</varlistentry> 591 592<varlistentry> 593<term><errorname>D_GIF_ERR_CLOSE_FAILED</errorname></term> 594<listitem> 595 <para>Message printed using PrintGifError: "Failed to close given file" 596 Closing file failed.</para> 597</listitem> 598</varlistentry> 599 600<varlistentry> 601<term><errorname>D_GIF_ERR_NOT_READABLE</errorname></term> 602<listitem> 603 <para>Message printed using PrintGifError: "Given file was not 604 opened for read" GIF files can be opened both for read (DGIF part 605 of library) and write (EGIF part of library). This error occurs 606 when a file is opened for write (using EGIF) is given to one of the 607 decoding (DGIF) routines.</para> 608</listitem> 609</varlistentry> 610 611<varlistentry> 612<term><errorname>D_GIF_ERR_IMAGE_DEFECT</errorname></term> 613<listitem> 614 <para>Message printed using PrintGifError: "Image is defective, 615 decoding aborted" This error is generated, once the decoding failed 616 - probably image is defect.</para> 617</listitem> 618</varlistentry> 619 620<varlistentry> 621<term><errorname>D_GIF_ERR_EOF_TOO_SOON</errorname></term> 622<listitem> 623 <para>Message printed using PrintGifError: "Image EOF detected, 624 before image complete" This error is generated once EOF errorname 625 is detected in encoded image before all the pixels (Width * 626 Height) has be decoded.</para> 627</listitem> 628</varlistentry> 629</variablelist> 630 631</sect2> 632</sect1> 633<sect1><title>Utility support library</title> 634 635<para>These functions are not part of the core GIF library. They are part 636of the getarg library that supports the utilities.</para> 637 638<sect2><title>Error Handling</title> 639 640<programlisting id="PrintGifError"> 641void PrintGifError(void) 642</programlisting> 643 644<para>Print a one-line diagnostic on the last giflib error to stderr.</para> 645 646</sect2> 647<sect2><title>Command Line Parsing</title> 648 649<programlisting id="GAGetArgs"> 650bool GAGetArgs(int argc, char **argv, char *CtrlStr, ...) 651</programlisting> 652 653<para>Main routine of this module. Given argc & argv as received by 654the main procedure, the command line CtrlStr, and the addresses of 655all parameters, parse the command line, and update the parameters.</para> 656 657<para>The CtrlStr defines what types of variables should follow. Look at the 658beginning of getarg.c for exact usage.</para> 659 660<para>Returns false if successful, returns true on failure.</para> 661 662<programlisting id="GAPrintErrMsg"> 663void GAPrintErrMsg(int Error) 664</programlisting> 665 666<para>If an error occurred in GAGetARgs, this routine may be used to print 667one line diagnostic to stderr.</para> 668 669<programlisting id="GAPrintHowTo"> 670void GAPrintHowTo(char *CtrlStr) 671</programlisting> 672 673<para>Given the same CtrlStr as for GAGetArgs, can be used to print a one line 674'how to use'. </para> 675 676</sect2> 677</sect1> 678<sect1 id="sequential"><title>Sequential access</title> 679 680<para>If you are handling large images on an extremely memory-limited 681machine, you may need to use the following functions for sequential 682read and write. It's better to avoid them and use the simpler 683DGifSlurp()/EGifSpew() interface.</para> 684 685<sect2><title>Sequential reading</title> 686 687<programlisting id="DGifGetScreenDesc"> 688int DGifGetScreenDesc(GifFileType *GifFile) 689</programlisting> 690 691<para>Reads the screen information into the GifFile structure. Note this 692routine is automatically called once a file is opened, and therefore 693usually need not be called explicitly.</para> 694 695<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 696 697<programlisting id="DGifGetRecordType"> 698int DGifGetRecordType(GifFileType *GifFile, GifRecordType *GifType) 699</programlisting> 700 701<para>As the GIF file can have different records in arbitrary order, this 702routine should be called once the file was open to detect the next 703record type, and act upon it. It can return these types in GifType:</para> 704 705<variablelist> 706<varlistentry> 707<term>1. UndefinedRecordType </term> 708<listitem> 709<para>something is wrong!</para> 710</listitem> 711</varlistentry> 712 713<varlistentry> 714<term>2. ScreenDescRecordType </term> 715<listitem> 716<para>screen information. As the screen info is automatically read in when the file is open, this should not happen.</para> 717</listitem> 718</varlistentry> 719 720<varlistentry> 721<term>3. ImageDescRecordType </term> 722<listitem> 723<para> next record is an image descriptor.</para> 724</listitem> 725</varlistentry> 726 727<varlistentry> 728<term>4. ExtensionRecordType</term> 729<listitem> 730<para> next record is extension block.</para> 731</listitem> 732</varlistentry> 733 734<varlistentry> 735<term>5. TrailerRecordType</term> 736<listitem> 737<para>last record reached, can close the file.</para> 738</listitem> 739</varlistentry> 740</variablelist> 741 742<para>The first two types can usually be ignored. The function 743returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 744 745<programlisting id="DGifGetImageDesc"> 746int DGifGetImageDesc(GifFileType *GifFile) 747</programlisting> 748 749<para>Reads image information into the GifFile structure. 750Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 751 752<programlisting id="DGifGetLine"> 753int DGifGetLine(GifFileType *GifFile, PixelType *GifLine, int GifLineLen) 754</programlisting> 755 756<para>Load a block of pixels from the GIF file. The line can be 757of any length. More than that, this routine may be interleaved with 758DGifGetPixel until all pixels have been read.</para> 759 760<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 761 762<programlisting> 763int DGifGetPixel(GifFileType *GifFile, PixelType GifPixel) 764</programlisting> 765 766<para>Loads one pixel from the GIF file. This routine may be interleaved 767with <link linkend="DGifGetLine">DGifGetLine()</link>, until all pixels are 768read. Because of the overhead per each call, use of this routine is 769not recommended.</para> 770 771<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 772 773<programlisting> 774int DGifGetExtension( 775 GifFileType *GifFile, 776 int *GifExtCode, 777 ByteType **GifExtension) 778</programlisting> 779 780<para>Loads an extension block from the GIF file. Extension blocks 781are optional in GIF files. This routine should be followed by 782<link linkend="DGifGetExtensionNext">DGifGetExtensionNext</link>.</para> 783 784<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 785 786<para><programlisting id="DGifGetExtensionNext"> 787int DGifGetExtensionNext(GifFileType *GifFile, ByteType **GifExtension) 788</programlisting> 789 790As extensions may contain more than one block, use this routine to 791continue after DGifGetExtension, until *GifExtension is NULL.</para> 792 793<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 794 795<programlisting> 796int DGifGetCode( 797 GifFileType *GifFile, 798 int *GifCodeSize, ByteType **GifCodeBlock) 799</programlisting> 800 801<para>It sometimes may be desired to read the compressed code as is 802without decoding it. This routine does exactly that (with 803DGifGetCodeNext), and can be used instead of DGifGetLine.</para> 804 805<para>This compressed code information can be written out using the 806EGifPutCode/EGifPutCodeNext sequence (see gifpos.c for example). 807Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 808 809<programlisting id="DGifGetCodeNext"> 810int DGifGetCodeNext(GifFileType *GifFile, ByteType **GifCodeBlock) 811</programlisting> 812 813<para>See DGifGetCode above.</para> 814 815<programlisting id="DGifGetLZCodes"> 816int DGifGetLZCodes(GifFileType *GifFile, int *GifCode) 817</programlisting> 818 819<para>This routine can be called instead of DGifGetLine/DGifGetPixel or 820DGifGetCode/DGifGetCodeNext to get the 12 bits LZ codes of the images. 821It will be used mainly for debugging purposes (see GifText.c for 822example).</para> 823 824<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 825 826<programlisting id="DGifCloseFile"> 827int DGifCloseFile(GifFileType *GifFile, int *ErrorCode) 828</programlisting> 829 830<para>Write a termination block to the GIF, close the GIF file and 831free all memory allocated for managing it. GifFile should not be used after 832this routine has been called.</para> 833 834<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise. When 835GIF_ERROR is returned, the diagnostic error code is left in ErrorCode. 836The GifFile structure is unconditionally freed.</para> 837 838<para>(Note: In versions before 5.1.0, the ErrorCode argument was 839absent and the GifFile structure was not freed so that the 840diagnostic error code will remain accessible in GifFile->Error. 841This behavior was changed because it caused problems for the 842implementation of library wrappers in dynamic languages.)</para> 843 844<programlisting id="DGetGifVersion"> 845const char * DGifGetGifVersion(GifFileType *GifFile) 846</programlisting> 847 848<para>Get the GIF version collected during sequential read. This is 849handy for sequential API users who want to set an encoder's version 850from a decoder (e.g. for gif resizing). For the all-at-once users this 851isn't necessary because gif encoder inspects all the extension blocks, 852but sequential users do not have that luxury.</para> 853 854</sect2> 855<sect2><title>Sequential writing</title> 856 857<para>If you are handling large images on a memory-limited machine, you may need 858to use the following functions for sequential write.</para> 859 860<programlisting id="EGifOpenFileName"> 861GifFileType *EGifOpenFileName(char *GifFileName, bool GifTestExistance, int *ErrorCode) 862</programlisting> 863 864<para>Open a new GIF file using the given GifFileName (in binary mode, 865if under Windows). If GifTestExistance is TRUE, and file exists, the 866file is not destroyed, and NULL returned.</para> 867 868<para>If any error occurs, NULL is returned and the ErrorCode is set.</para> 869 870<programlisting id="EGifOpenFileHandle"> 871GifFileType *EGifOpenFileHandle(int GifFileHandle, int *ErrorCode) 872</programlisting> 873 874<para>Open a new GIF file using the given GifFileHandle.</para> 875 876<para>If any error occurs, NULL is returned and ErrorCode is set.</para> 877 878<para>The file is opened in binary mode, and its buffer size is set to 879FILE_BUFFER_SIZE bytes.</para> 880 881<programlisting> 882char *EGifGetGifVersion(GifFileType *GifFile) 883</programlisting> 884 885<para>That version computation is available through this function.</para> 886 887<programlisting id="EGifSetGifVersion"> 888void EGifSetGifVersion(GifFileType *GifFile, bool gif89) 889</programlisting> 890 891<para>Set the GIF type, to GIF89 if the argument is true and GIF87 if 892it is false. The default type is GIF87. This function may be called 893aftert the GifFile record is allocated but before 894EGifPutScreenDesc().</para> 895 896<programlisting> 897int EGifPutScreenDesc(GifFileType *GifFile, 898 const int GifWidth, const GifHeight, 899 const int GifColorRes, const int GifBackGround, 900 ColorMapObject *GifColorMap) 901</programlisting> 902 903<para>Update the GifFile Screen parameters, in GifFile structure and in 904the real file. If error occurs, returns GIF_ERROR (see gif_lib.h), 905otherwise GIF_OK.</para> 906 907<para>This routine should be called immediately after the GIF file was 908opened.</para> 909 910<programlisting> 911int EGifPutImageDesc(GifFileType *GifFile, 912 const int GifLeft, const int GifTop, 913 const int GifWidth, const GifHeight, 914 const bool GifInterlace, 915 ColorMapObject *GifColorMap) 916</programlisting> 917 918<para>Update GifFile Image parameters, in GifFile structure and in the real 919file. if error occurs returns GIF_ERROR (see gif_lib.h), otherwise 920GIF_OK.</para> 921 922<para>This routine should be called each time a new image must be 923dumped to the file.</para> 924 925<programlisting id="EGifPutLine"> 926int EGifPutLine(GifFileType *GifFile, PixelType *GifLine, int GifLineLen) 927</programlisting> 928 929<para>Dumps a block of pixels out to the GIF file. The slab can be of 930any length. More than that, this routine may be interleaved with 931<link linkend="EGifPutPixel">EGifPutPixel()</link>, until all pixels 932have been sent.</para> 933 934<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 935 936<programlisting id="EGifPutPixel"> 937int EGifPutPixel(GifFileType *GifFile, const PixelType GifPixel) 938</programlisting> 939 940<para>Dumps one pixel to the GIF file. This routine may be interleaved with 941<link linkend="EGifPutLine">EGifPutLine()</link>, until all pixels were sent. 942Because of the overhead for each call, use of this routine is not 943recommended.</para> 944 945<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 946 947<programlisting id="EGifPutComment"> 948int EGifPutComment(GifFileType *GifFile, char *GifComment) 949</programlisting> 950 951<para>Uses extension GIF records to save a string as a comment is the file. 952The extension code is 'C' (for Comment).</para> 953 954<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 955 956<programlisting id="EGifPutExtension"> 957int EGifPutExtension( 958 GifFileType *GifFile, 959 const int GifExtCode, 960 const int GifExtLen, 961 void *GifExtension) 962</programlisting> 963 964<para>Dumps the given extension block into the GIF file. Extension blocks 965are optional in GIF file. Extension blocks of more than 255 bytes or 966more than one block are not supported in this function. Please use 967EGifPutExtensionFirst, EGifPutExtensionBlock, and EGifPutExtensionTrailer 968if your extension blocks may fall into this category.</para> 969 970<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 971 972<programlisting id="EGifPutExtensionLeader"> 973int EGifPutExtensionLeader( 974 GifFileType * GifFile, 975 const int GifExtCode) 976</programlisting> 977 978<para>Dumps the beginning of a GIF extension block to a GIF file. 979Extension blocks are optional in GIF files. This function outputs the 980type code information necessary for a GIF extension block.</para> 981 982<para>Further blocks of the GIF Extension should be dumped using 983EGifPutExtensionBlock. When finished with this extension block, 984EGifPutExtensionTrailer should be called to output the block termination.</para> 985 986<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 987 988<programlisting id="EGifPutExtensionBlock"> 989int EGifPutExtensionBlock( 990 GifFileType * GifFile, 991 const int GifExtLen, 992 const VoidPtr GifExtension) 993</programlisting> 994 995<para>Dumps a subblock of a GIF extension to a GIF File; should be 996used only following an initializing call to EGifPutExtensionLeader(). 997Extension blocks are optional in GIF files. This function will write 998the Extension Data in GifExtension to the file as a subblock of the 999preceding Extension Block. Repeat calling of this function until all 1000data subblocks have been output.</para> 1001 1002<para>Note that EGifPutExtensionLeader needs to be called before any 1003calls to this function. EGifPutExtensionTrailer should be called to 1004finish the Extension block after all data subblocks have been 1005output.</para> 1006 1007<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1008 1009<programlisting id="EGifPutExtensionTrailer"> 1010int EGifPutExtensionTrailer( 1011 GifFileType * GifFile, 1012 const VoidPtr GifExtension) 1013</programlisting> 1014 1015<para>Dumps the GIF extension block terminator to a GIF File to end 1016the current Extension block.</para> 1017 1018<para>Note that a call to EGifPutExtensionLeader is needed to open the GIF 1019Extension Block prior to calling this function.</para> 1020 1021<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1022 1023<programlisting id="EGifPutCode"> 1024int EGifPutCode( 1025 GifFileType *GifFile, 1026 int *GifCodeSize, 1027 ByteType **GifCodeBlock) 1028</programlisting> 1029 1030<para>It sometimes may be desired to write the compressed code as is 1031without decoding it. For example a filter for a GIF file that change 1032only screen size (GifPos), does not need the exact pixel values. 1033Piping out the compressed image as is makes this process much 1034faster.</para> 1035 1036<para>This routine does exactly that (with EGifPutCodeNext), and can be 1037used instead of EGifPutLine. You'll usually use this with the 1038DGifGetCode/DgifGetCodeNext routines, which reads the compressed 1039code, while EGifPutCode/EGifPutCodeNext write it out. See gifpos.c 1040for example.</para> 1041 1042<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise.</para> 1043 1044<programlisting id="EGifPutCodeNext"> 1045int EGifPutCodeNext(GifFileType *GifFile, ByteType **GifCodeBlock) 1046</programlisting> 1047 1048<para>See EGifPutCode above.</para> 1049 1050<programlisting id="EGifCloseFile"> 1051int EGifCloseFile(GifFileType *GifFile) 1052</programlisting> 1053 1054<para>Write a termination block to the GIF, close the GIF file, and 1055free all memory allocated for managing it. GifFile should not be used 1056after this routine has been called.</para> 1057 1058<para>Returns GIF_ERROR if something went wrong, GIF_OK otherwise. When 1059GIF_ERROR is returned, the diagnostic error code is left in ErrorCode. 1060The GifFile structure is unconditionally freed.</para> 1061 1062<para>(Note: In versions before 5.1.0, the ErrorCode argument was 1063absent and the GifFile structure was not freed so that the 1064diagnostic error code will remain accessible in GifFile->Error. 1065This behavior was changed because it caused problems for the 1066implementation of library wrappers in dynamic languages.)</para> 1067</sect2> 1068 1069</sect1> 1070<sect1 id="compatibility"><title>Forward and Backward Compatibility</title> 1071 1072<para>Except for some details of extension-block handling and the addition 1073of read/write function hooks, the DGifSlurp()/EGifSpew() interface has 1074been stable since 1990. It is expected to remain so.</para> 1075 1076<para>However, the signatures of the file-opener functions were changed in 5.0 1077in order to make the library fully reentrant and thread-safe - earlier library 1078versions did not feature the final pointer-to-error-code argument in 1079DGifOpen() and friends. For the same reason, the static storage queried by 1080GifLastError() in older versions is gone, and that function abolished.</para> 1081 1082<para>The library header contains some version #defines you can use if you 1083need to condition your code so it can compile with different library 1084versions</para> 1085 1086<para>Versions up to 4.1.6 defined a GIF_LIB_VERSION macro that was 1087string-valued with a tricky format to parse. This macro has been 1088retired.</para> 1089 1090<para>Versions after 4.1.6 define integer-valued GIFLIB_MAJOR, GIFLIB_MINOR, 1091and GIFLIB_RELEASE macros for the three components of the version. See the 1092NEWS file in the GIFLIB distribution to track API changes.</para> 1093 1094<para>The following functions are entirely new:</para> 1095 1096<itemizedlist> 1097<listitem><para>New functions DGifSavedExtensionToGCB() and 1098EGifGCBToSavedExtension() make it easy to read and edit GIF89 graphics 1099control blocks in saved images.</para></listitem> 1100<listitem><para>The new function DGifGetGifVersion() is convenient 1101for people doing sequential reads.</para></listitem> 1102</itemizedlist> 1103 1104<para>A few changes in behavior were introduced in 5.0:</para> 1105 1106<sect2><title>General behavior</title> 1107 1108<itemizedlist> 1109<listitem><para>The library is now fully re-entrant and 1110thread-safe.</para></listitem> 1111</itemizedlist> 1112<itemizedlist> 1113<listitem><para> All functions exported by this library now have DGif, 1114EGif, or Gif as a name prefix.</para></listitem> 1115<listitem><para>The default GIF version to write is now computed at 1116write time from the types of an image's extension blocks. (Formerly 1117EGifSpew() behaved this way, but the sequential-writing code didn't.) 1118The result of this computation is available through the new function 1119EGifGetGifVersion().</para></listitem> 1120</itemizedlist> 1121 1122</sect2> 1123<sect2><title>In documented functions:</title> 1124 1125<itemizedlist> 1126<listitem><para>GIF file openers and closers - DGifOpenFileName(), 1127DGifOpenFileHandle(), DGifOpen(), DGifClose(), EGifOpenFileName(), 1128EGifOpenFileHandle(), EGifOpen(), and EGifClose() - all now take a 1129final integer address argument. If non-null, this is used to pass 1130back an error code when the function returns NULL.</para></listitem> 1131<listitem><para>EGifSlurp() and EGifSpew() read and write 1132extension blocks trailing after the last image, handle interlaced 1133images properly.</para></listitem> 1134<listitem><para>EGifPutExtensionFirst() has been replaced by 1135EGifPutExtensionLeader(); the difference is the new function doesn't 1136take an optional block, it just writes a block 1137leader.</para></listitem> 1138<listitem><para>EGifPutExtensionNext() has been replaced by 1139EGifPutExtensionBlock(); the difference is that the new function does 1140not take and then discard a function code argument.</para></listitem> 1141<listitem><para>EGifPutExtensionLast() has been replaced by 1142EGifPutExtensionTrailer(); all it does is write the terminator 1143block. Split your old EGifPutExtensionLast() calls into 1144EGifPutExtensionBlock() followed by 1145EGifPutExtensionTrailer().</para></listitem> 1146</itemizedlist> 1147 1148</sect2> 1149<sect2><title>In undocumented functions:</title> 1150 1151<itemizedlist> 1152<listitem><para>Some undocumented functions have been renamed. 1153AddExtensionBlock() is now GifAddExtensionBlock(), and takes an additional 1154function code argument. ApplyTranslation() is now GifApplyTranslation(); 1155FreeExtension() has become GifFreeExtensions() and takes a different argument 1156type; MakeSavedImage() is now GifMakeSavedImage(), FreeSavedImages() is 1157now GifFreeSavedImages(), and BitSize() is now GifBitSize().</para></listitem> 1158<listitem><para>Three documented functions - MakeMapObject(), 1159FreeMapObject(), and UnionColorMap() - have been renamed to 1160GifMakeMapObject(), GifFreeMapObject(), and GifUnionColorMap() 1161respectively.</para></listitem> 1162</itemizedlist> 1163 1164</sect2> 1165<sect2><title>Error handling:</title> 1166 1167<itemizedlist> 1168<listitem><para>Library error handling no longer uses a static cell to 1169store the last error code registered; that made the library 1170thread-unsafe.</para></listitem> 1171<listitem><para>For functions other than GIF file openers, the Error 1172code is now put in an Error member of the GifFileType 1173structure.</para></listitem> 1174<listitem><para>The GifError() and 1175GifLastError() functions that referenced that static cell are gone, 1176and the GifErrorString() function introduced in the 4.2 release now 1177takes an explicit error code argument.</para></listitem> 1178</itemizedlist> 1179</sect2> 1180</sect1> 1181<sect1><title>Skeletons of GIF filters</title> 1182 1183<para>If you are developing on a virtual-memory OS such as most flavors of 1184UNIX, or are otherwise sure of having enough memory to keep all of GIFs you 1185need to operate in core, writing a filter is trivial. See the file 1186gifsponge.c in util.</para> 1187 1188<para>A sequential filter skeleton will usually look like the example file 1189giffilter.c in util.</para> 1190 1191<para>Please look at the utilities in the util directory for more ideas once 1192you feel comfortable with these skeletons. Also try to follow the coding 1193standards of this package if you want the maintainer to officially add your new 1194utility to it.</para> 1195 1196</sect1> 1197<sect1><title>Unimplemented features</title> 1198 1199<para>Some features of the original GIF specification have not stood the 1200test of time. This library mostly ignores them, but they are described 1201here for completeness.</para> 1202 1203<para>The GIF standard fails to be explicit about a small but crucial detail: 1204the unsigned two-byte integer fields in it are little-endian.</para> 1205 1206<para>The GIF format seems to have been designed with the idea that viewers 1207would render multiple images in a GIF on a common canvas, giving an effect like 1208a picture wall. The 'logical screen descriptor block' (LSDB), 6 bytes right 1209after the 6-byte GIF stamp and version header at the beginning of a 1210GIF file, includes both two-byte canvas width and canvas height 1211fields and a canvas background color. Each image, besides height and 1212width, also has 'left' and 'top' cordinates specifying where it is to 1213be placed on the canvas.</para> 1214 1215<para>GIFLIB can read and set these fields; the gifpos and giftool 1216utilities will enable you to script such changes. But browsers and 1217modern image viewers ignore them. Nowadays multiple-image GIFs are 1218generally used either as animations in which each sub-image is a frame 1219or as image libraries, with the GIF client handling compositing into 1220some canvas about which the GIF format holds no information.</para> 1221 1222<para>Another feature of the LSDB that is generally ignored is the 1223pixel aspect ratio byte. Until 5.0, GIFLIB ignored this flag on input 1224and zeroed it on output; now it is read and preserved if present. The 1225GIF standard doesn't give a rationale for it, but it seems likely that 1226the designers intended it for representing image captures from the 1227analog television of the day, which had rectangular pixel-equivalents.</para> 1228 1229<para>Yet another ignored feature of both the LSDB and sub-images is 1230the sort flag, which is supposed to signal whether the colors in the 1231associated color map are sorted by decreasing importance in case the 1232display device can only render a limited number of them. This feature 1233reflected the high cost of dual-port memory at the time the GIF 1234specification was written in the late 1980s. That kind of limit 1235disappeared in the mid-1990s. Until 5.0, GIFLIB ignored this flag on 1236input and zeroed it on output; now it is read and preserved if 1237present.</para> 1238 1239<para>Finally, the plaintext extension block. This is an extension block 1240that contains instructions for overlaying text captions on a following image. 1241GIFLIB treats these blocks as raw data, not attempting to parse out the 1242location and text data.</para> 1243</sect1> 1244</article> 1245