2001.03.29 22:00 "TIFF 3.5.6 Beta Bugs", by Scott Marovich

If you're familiar with "xv(1)", you may know that whenever something like the TIFF Library generates a message on a UNIX user's standard error stream, this usually-terse text is displayed under "X Windows" using a small pop-up window. For a naive user who's innocently trying display an image downloaded from the Web, because "xv(1)" gets invoked from Netscape Navigator via "metamail(1)" and a "mailcap" file, the source and significance of these messages is often mysterious, hard to diagnose, and very annoying. We have therefore engaged in a local campaign to help stamp out TIFF Library (and other) spurious diagnostic messages whenever this is reasonably possible. As you may know, a common cause of spurious messages is when a user's TIFF file contains a vendor-specific TIFF record tag that isn't described in the TIFF Library's "tiffFieldInfo[]" array, in the "tif_dirinfo.c" file. In general, I think that this array should strive to describe "all known" TIFF tags, even if they are vendor-specific and even if the associated (default) parsing action is "FIELD_IGNORE". I realize updating this array could be a never-ending job, since there are probably thousands of these things, and Adobe Systems doesn't seem to publish a complete list of registered tags on its Web site. So, as a small step in that direction, we've added definitions for a couple of extra Adobe tags that their documents state (and our testing confirms) may appear in PageMaker or Photoshop output. This is the reason for my suggested "tiff.h" and "tif_dirinfo.c" changes, shown below.

The "tif_thunder.c" change is an attempt to solve a different, but related problem: Without it, when "xv(1)" tries to display the "text.tif" file in Sam's test suite, we get the TIFF Library error message:

ThunderDecode: Not enough data at scanline 320 (0 != 1512)

and our "xv(1)" fails to display the image because of this error. Upon investigation, it appears that this file represents a 768x359 pixel image for which the last 3 rows (2268 pixels exactly) are missing from the compressed- image data. I'm not very familiar with the details of "Thunder" compression or with how this file was generated, so I don't know whether this discrepancy represents a defective test file or a defective decoding algorithm in the TIFF Library, but as a "hack" solution, I changed the "ThunderDecode()" subroutine to issue a warning message (not a fatal error) and automatically pad the image with rows of all-zero pixels. Our "xv(1)" then displays this image and I can barely see anything wrong on my CRT screen. Notice that the old- and new code might also similarly complain if a file's "Thunder" compressed image data encodes *too many* pixels, rather than too few. Although it would be possible to issue a warning message and truncate the image, I've chosen to leave the TIFF Library's fatal-error response intact here. Frankly, I'm not sure what the "best" answer is in this case.

Concerning an unrelated subject, I had a bunch of problems getting the auto- configure and build process to work for this software under HP-UX, and I severely hacked many of the shell scripts and "Makefile.in" templates in your distribution. I don't know whether you're interested in the details of these changes, but I could make up an additional set of "diff(1)" outputs if you care. The basic problems that I found were:

1. HP-UX Version 10+ uses an SVR4-style file-directory structure, which has no "/bin" directory. Hence, all references to paths like "/bin/sh" must be changed to "/usr/bin/sh", etc.

2. Shell environment variables in the "configure" script should NOT be unconditionally initialized to the null string or any other value; instead, they should be *conditionally* initialized so that they can be potentially over- ridden by a developer. For example, instead of initializing:

JPEG=

a more helpful syntax would be something like:

JPEG=${JPEG:=no}

3. In "Makefile.in" templates, recursive invocations of "make(1)" should always include the MAKEFLAGS macro (e.g., "${MAKE} -${MAKEFLAGS}... ") so that command-line flags are properly inherited.

4. "configure" and the "Makefile.in" templates should support an OPTIMIZE parameter for a "C" compiler's optimization flags, since "-O" isn't always a developer's preferred choice.

5. Finally, a bunch of HP-UX specific compiler and linker command flags have changed between Version 9 (when these templates were apparently built) and Version 11. I could send more details if you're interested.

Finally, to summarize, please do not intepret this long message as an attempt to trash the TIFF Library. On the contrary: it's great and I love it! But I hope that perhaps these suggestions might help to make it better.

Editor's note: This mail was not originally archived, and has been reconstructed from quotes.