Latin-1 Text Annotations (tEXt, zTXt)
- Status: PNG Specification
- Location: anywhere
- Multiple: yes
That brings us to PNG's original text chunks, which are perhaps its most
popular nonessential chunks. Regardless of how many words a picture is
worth, it is often useful or necessary to add a few more in order to record
pertinent information like title and author, store requisite legal
notices such as a copyright or disclaimer, or merely to transfer text
from one image to another.
PNG supports two types of Latin-1-based text chunks, uncompressed
(tEXt) and compressed (zTXt). There is also a new Unicode-based chunk
(iTXt) that I'll discuss next. For the first two, the format is
basically the same: an uncompressed keyword or key phrase, a null
(zero) byte, and the actual text. In zTXt the text is compressed; the
first byte after the null indicates the compression method, for which
only deflate is currently defined (method zero). The remainder is the
compressed stream, which for method zero must be in zlib 1.x format,
just as for image data. (The zlib 1.x format is described by revision
3.3 of the zlib specification, which is available from
Both keyword and raw text should be encoded with the Latin-1 (ISO/IEC 8859-1)
character set; neither may contain null bytes. Since the keyword is intended
to be recognizable by both humans
and computer programs, additional restrictions are placed on it: it may not
contain leading, trailing, or consecutive spaces, and it is restricted to
characters in the range 32-126 and 161-255 (which, in particular, rules
out both control characters and the nonbreaking space, decimal value 160).
The only other restriction on the main text of the chunk is that newlines
should be in Unix format, i.e., represented by a single line-feed character
(decimal value 10).
I mentioned in Chapter 7, "History of the Portable Network Graphics Format", that the Unicode UTF-8 character set was one of the
items in the design of PNG that was voted down. In retrospect this was,
perhaps, a lamentable decision; it was finally addressed early in 1999
with the iTXt chunk. But at the time, UTF-8 was very new and had not been
extensively tested in the field. In particular, it had little or no
operating-system support and no support in standard programming libraries,
either for encoding and decoding or for the translation and display of UTF-8
characters in the native character set(s) of existing systems. Since PNG's
design goals included both the use of well-tested technologies and the
avoidance of undue burdens on developers of PNG applications, support for
UTF-8 was dropped in favor of the more familiar Latin-1 character set.
The following list summarizes all of the keywords that are either
included in the specification itself or officially registered as extensions
to the spec:
The name of the author of the image. If the original image were a painting or
other nonelectronic medium, both the original artist and the person who
scanned the image might be listed.
A one-line title or caption. Longer captions should generally
use the Description keyword, but see the end of this section for an unofficial alternative.
A longer description of or caption for the image, perhaps including details
about the tools and settings used; the name, age, and/or location of the
subject matter; or the mood the artist was trying to convey. See also the
Software and Source keywords.
- Creation Time
The time the image was created, in whatever sense is most appropriate.
The recommended format is that prescribed by Internet RFC 822 (Section 5), as
amended by RFC 1123 (Section 5.2.14); specifically:
day month year hour:minute timezone
where day is either one or two digits; month is a three-letter
English abbreviation such as Jun; year is two or four digits
(though the latter is strongly recommended); hour and minute
are two digits each; and timezone is either a three-letter abbreviation
(e.g., PST for Pacific Standard Time), or a one-letter U.S. military designation,
or a four-digit number with a leading positive or negative sign indicating the
hour:minute offset from Coordinated Universal Time (e.g., -0800 for Pacific
Standard Time, which is eight hours and zero minutes earlier than UTC). In
addition, the entire string may optionally be preceded by a weekday
field, where weekday is a three-letter English abbreviation (e.g.,
Fri). A colon and two-digit seconds field may also be
appended to the time (that is, hour:minute:second). Note that this
is merely a recommendation; strings such as ``circa 1492'' are allowed, as is
explanatory text following an RFC-style date string.
The legal copyright notice for the image. For example, ``Copyright 1999
by Greg Roelofs. This image may be freely used and distributed provided that
it is not modified in any way and that this notice remains intact.''
A legal disclaimer notice for the image. This might include a company's
standard boilerplate on all copyrighted works; in particular, it might be
lengthy enough to store in a compressed (zTXt) chunk, while the copyright
notice remains uncompressed.
A warning about the content or effects of the image. For example, certain
types of popular material may not be suitable for minors, or a random-dot
stereogram (``Magic Eye'' 3D image) may induce headaches in some people.
The name and possibly the version of the software used to create the image. This
is most often generated automatically, but it need not be. More than one
software application may be listed.
Information about the device used to generate the image, such as a digital
camera or a scanner.
A miscellaneous comment, often converted from a GIF comment (which lacks
In addition to these official keywords, one of the technical
reviewers of this book and I have been known to make use of a few unofficial
keywords. The Caption keyword is used to provide a brief description
of an image that is more specifically tailored for use as a
publishable caption than the generic Description keyword; it is
also generally lengthier than is appropriate for the Title keyword.
The E-mail keyword stores the email address of the author in standard
Internet format (RFC 822, Section 6, as amended by RFC 1123, Sections
5.2.15 through 5.2.19); for example,
firstname.lastname@example.org . And
the URL keyword is for a standard WWW Uniform Resource Locator (RFC
2068, Section 3.2); for example,
http://www.oreilly.com/ . If
the URL is reasonably self-explanatory, it is recommended that the
chunk consist of the single URL and nothing else, but this is not a
requirement. Multiple URLs should be separated by newline characters.
Note that spaces and other white space (tabs, newlines, and so forth)
are considered unsafe by the URL standard and therefore must be
escaped within a conforming URL. For example, a space character must
be encoded as %20. This allows easy parsing
of optional explanatory text after a URL:
the URL ends when the first white space
(space, tab, or newline) is encountered.