Message-ID: <200103292202.OAA04506@hpmarov.hpl.hp.com>
Date: Thu, 29 Mar 2001 17:00:00 -0500
From: Scott Marovich <marovich@hpl.hp.com>
Subject: TIFF 3.5.6 Beta Bugs

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.
  
