The PNG Guide is an eBook based on Greg Roelofs' book, originally published by O'Reilly.



GIF Plain Text (gIFt)

  • Status:   officially deprecated (PNG Extensions)
  • Location:   anywhere
  • Multiple:   yes

GIF's Plain Text Extension is a way to define an image composed entirely of text without actually storing the text as a bitmapped image. It defines a rectangular grid of character cells into which text characters of the specified foreground and background colors are placed, starting from the upper left and proceeding left to right and top to bottom; the decoder chooses the font that is the closest match to the specified size.

A casual reading of the GIF specification might suggest that the Plain Text Extension defines a method for cheaply overlaying fixed-width text on top of ordinary pixel data--and, indeed, that was probably the primary motivation behind the extension. But a more careful inspection reveals that the Plain Text Extension is treated as a separate subimage within the GIF stream, on equal terms with any block of bitmap data. It may, in fact, be the only graphic rendering block within the stream. And since PNG images are required to include bitmap data (i.e., IDAT chunks), allowing GIF Plain Text information to be included is perilously close to sanctioning multi-image PNGs. Largely because of this, the gIFt chunk was officially deprecated in October 1998. It is still allowed for backward compatibility (the horses have already left the barn, so to speak), but the current recommendation is that all decoders ignore the chunk and that encoders not write it in the first place. In fact, it is quite possible that no encoder or decoder ever did support gIFt; the Plain Text Extension was rarely used even in GIF's heyday, and even gif2png (see Chapter 5, "Applications: Image Converters") never supported it.

In any case, the format of the gIFt chunk is as shown in Table 11-11.

Table 11-11. gIFt Chunk

Field Length and Valid Range
Text grid left position, pixels 4 bytes (0-2,147,483,647)
Text grid top position, pixels 4 bytes (0-2,147,483,647)
Text grid width, pixels 4 bytes (0-2,147,483,647)
Text grid height, pixels 4 bytes (0-2,147,483,647)
Character cell width, pixels 1 byte (0-255)
Character cell height, pixels 1 byte (0-255)
Text foreground color 3 bytes (R, G, B samples, 0-255 each)
Text background color 3 bytes (R, G, B samples, 0-255 each)
Plain text data n bytes

There are several differences from the GIF data structure. The actual text in the GIF block is divided into sub-blocks of between 1 and 255 bytes; the PNG plain text data is a single stream. In addition to the reversed order for integer values (big-endian in PNG), gIFt's width and height fields for the grid are 4 bytes each, twice as big as in GIF. The position fields are also twice as wide, which makes little sense from a preserve-the-GIF-data standpoint, but apparently was chosen for consistency with PNG's image-offset chunk. Both the Plain Text Extension and oFFs give positions relative to a logical page, not relative to the main image; thus, in the presence of oFFs data, the gIFt positions should be adjusted accordingly. Note that this may not be possible if the PNG image uses microns in the oFFs chunk and has no pHYs chunk--in that case, there is no conversion information between pixels (the only unit defined for gIFt) and microns.

Possibly the biggest difference, however, is that the Plain Text Extension is affected by the Graphic Control Extension, which means it implicitly includes transparency and timing effects. PNG's gIFt chunk does not include any transparency information, so effectively there is no way to float the gIFt text over the main image by giving it a transparent background color. This limitation appears to have been an oversight in the design of the PNG chunk and was another reason for its official deprecation. On the other hand, if the gIFt chunk appears before the first IDAT chunk, a hypothetical gIFt-aware PNG decoder might assume that the text amounts to a background image and render the pixel data on top of it, applying any transparency effects the main image possesses.




Last Update: 2010-Nov-26