Bug 8345

It looks as if the update causes more trouble than it was supposed to fix.
libtiff-3.4 is working perfectly for me and other (see below):

http://www.hylafax.org/archive/2000-01/msg00280.html

Maybe redhat should post an update to the update. And better make sure it works
in 6.2 ;)

Further investigation indicates that the mentioned problem still exists in
versions 3.5.4-4 and 3.5.4-5 of the package available in 6.1.92 & Rawhide
respectively.

*** Bug 10067 has been marked as a duplicate of this bug. ***

Hello, any action here?  I have the same problem, 100% reproducible.  Neither gv
nor my Lexmark Optra S 1620 show anything on the fax2ps page, but ee shows it in
the tiff file.  Please fix asap!

--jh--

Yes, actually I spent the second half of last week looking at this.  The problem
is in libtiff itself and not fax2ps, and it cropped up between 3.5.1 and 3.5.2,
when support was added for images wider than 65536 pixels.  The libtiff
developers are also looking into this.

This are more complicated because ee uses ImageMagick's convert program behind
the scenes to convert raw .fax files to a viewable format, but the fax2ps
program has never been able to read raw .fax files, only .tiff files compressed
using the same scheme as .fax files use.  This alone makes generating sample
files for testing more difficult.

Aaargh.  I think I've found the problem.  Please download and try the latest
revs in http://people.redhat.com/nalin/test/ and let me know if this solves it
for you.  If it works, I'll see about making the fix an errata.

Almost!  It creates a .ps file that prints fine (and compresses with gzip to be
smaller than the original fax!).  However, the bounding box is bogus.  Try
looking at it with gv and selecting BBox from the menu for the display size.  I
can supply sample files if wanted.  Send me an email and I'll put one on my FTP
site.

--jh--

Bounding box problems were present in 3.4 as well, but the new test release at
http://people.redhat.com/nalin/test/ appears to work correctly with the test
images I have here (created with "efix -o tiffg3").

Yup, efix and tiff2ps are fixed in your version, but fax2ps has a bounding box
bug.  All these are binaries that link the libtiff library, not shell scripts,
so the bug is probably just in fax2ps.

The bounding box from fax2ps is the right size but in landscape orientation.  If
I use tiff2ps I get a correct portrait bounding box.  Examples are at
ftp://oobleck.tn.cornell.edu/outgoing/jh/fax2ps/0324233854.001
ftp://oobleck.tn.cornell.edu/outgoing/jh/fax2ps/0324233854.001.fps
ftp://oobleck.tn.cornell.edu/outgoing/jh/fax2ps/0324233854.001.ps

The first is the fax file, from efax.  The others were made with:
fax2ps 0324233854.001 > 0324233854.001.fps
tiff2ps 0324233854.001 > 0324233854.001.ps

The bounding boxes are:
0324233854.001.fps:%%BoundingBox: 0 0 792 612
0324233854.001.ps:%%BoundingBox: 0 0 610 784

Looks like the .fps bounding box has the last two numbers swapped.

Please let me know when I can delete the files from my site.

--jh--

Hang on -- did you grab the fresh copies I put up there an hour ago?  The
release number didn't change (it never went through our build system, so I
didn't bump the number up).  The change is a quick one-liner that swaps the
height and width of the bounding box to be correct per PostScript docs....

Testing with 0324233854.001 should give a bounding box of "0 0 612 792",
which is the bounding box for the whole page.

You win!  The latest version works.  Thanks for the fix!

--jh--

Woohoo!  For clarification, the bug was not in libtiff, but was triggered from
a callback that got registered with libtiff.  The bugs were in fax2ps, and I've
gotten email confirmation that at least the second will be fixed in the next
libtiff release.

Of course, HylaFAX is still incompatible with this libtiff. The tiff
maintainers changed a few of the internal interfaces to
achieve large run lengths (from 16 to 32 bits).  Hylafax uses one of
libtiffs header files(faxd/tif_fax3.h) for some undocumented macros and
interfaces and was only expecting 16 bits, and broke.

A patch is in development for HylaFAX, but it's a shame these two packages,
originally authored by the same individual, have diverged.

Darren, I guess HylaFAX needs to incorporate some sort of test to figure out how
to deal with this change.  From a look at the headers, it appears that parsing
the value returned by TIFFGetVersion() at configure-time to see if it's >= 3.5.2
is the only way to make HylaFAX work correctly with both older and newer
versions of libtiff.  Alternatively, HylaFAX could just require a newer libtiff.

Version 3.5.5 of libtiff has been released, and incorporates the two fixes we
made, so I'm going to mark this as resolved, with the fix available in Raw Hide
(ftp://ftp.redhat.com/pub/rawhide/i386/RedHat/RPMS/).