Bug 8345 - fax2ps prints blank pages
Summary: fax2ps prints blank pages
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtiff
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact:
: 10067 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-01-10 20:17 UTC by Peter Hunter
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-07-25 19:47:31 UTC

Attachments (Terms of Use)

Description Peter Hunter 2000-01-10 20:17:27 UTC
Since the Y2k update (libtiff-3.5.4-1) fax2ps prints blank pages on our
printer (HP 4000). ee shows that the tiffs are not blank, and indeed,
tiff2ps prints them fine.

Comment 1 Fabian Kroenner 2000-03-02 16:25:59 UTC
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):


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

Comment 2 Fabian Kroenner 2000-03-04 13:44:59 UTC
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

Comment 3 Nalin Dahyabhai 2000-03-08 18:55:59 UTC
*** Bug 10067 has been marked as a duplicate of this bug. ***

Comment 4 Joe Harrington 2000-03-26 16:50:59 UTC
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!


Comment 5 Nalin Dahyabhai 2000-03-27 13:06:59 UTC
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.

Comment 6 Nalin Dahyabhai 2000-03-27 16:44:59 UTC
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.

Comment 7 Joe Harrington 2000-03-28 17:05:59 UTC
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


Comment 8 Nalin Dahyabhai 2000-03-28 18:02:59 UTC
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").

Comment 9 Joe Harrington 2000-03-28 18:21:59 UTC
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

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.


Comment 10 Nalin Dahyabhai 2000-03-28 18:52:59 UTC
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.

Comment 11 Joe Harrington 2000-03-28 19:58:59 UTC
You win!  The latest version works.  Thanks for the fix!


Comment 12 Nalin Dahyabhai 2000-03-28 20:03:59 UTC
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.

Comment 13 Darren Nickerson 2000-03-28 20:53:59 UTC
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.

Comment 14 Nalin Dahyabhai 2000-04-06 19:53:59 UTC
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

Note You need to log in before you can comment on or make changes to this bug.