[gs-bugs] [Bug 691175] Multi-strip TIFF files cause problems with fax software

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Wed May 5 16:50:53 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691175

--- Comment #8 from Lee Howard <faxguy at howardsilvan.com> 2010-05-05 16:50:52 UTC ---
You'd probably be surprised at what fax software will see.  Of course it's not
frequent, but it's certainly not unheard-of that a fax user will scan a
print-out made on a blue-colored multipart form, and then attempt to fax it.

To show you just how bad this scenario can get for G4 encoding, please take a
look at the "blue.pdf" file I just attached.  Then I run it through Ghostscript
8.63 like this:

cat blue.pdf | gs -q -sDEVICE=tiffg4 -sOutputFile=bluefax.tif stocht.ps -c "<<
/HalftoneMode 1 >> setuserparams" -

... and I end up with a TIFF file that has a single strip size of 2,119,705
bytes.

So what I'm saying by all of this is that with the 1MB default all fax software
that intends to be reliable for all user-supplied data will necessarily have to
use -dMaxStripSize=0 because the 1MB default is likely to get hit more than a
few times with enough use.

Furthermore, if fax software supports resolutions beyond 200 dpi (and HylaFAX
currently supports up to 400 dpi, but 1200 dpi is not inconceivable since it's
within spec), then users who regularly employ such extended resolutions will
almost certainly hit on the 1MB limit routinely.

The lesson here is that fax applications who do not otherwise restrict input to
cope with this 1MB limit will necessarily need to specify some other limit with
MaxStripSize.  It's a mistake for those applications to look at the 1MB limit
as adequate.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list