Revision r10710 changed MaxStripSize for TIFF devices to default to 8 KB. This changes causes some fax software to not be able to read our TIFF files, since the expect the entire page to be in one strip. There is a work-around, involving specifying a command line parameter to change MaxStripSize, but it is preferable to change the default MaxStripSize to a larger value (one megabyte?), so that fax TIFF files are written as one strip.
*** Bug 691174 has been marked as a duplicate of this bug. ***
I don't see a problem with changing the default value. I initially chose 8 KB because it is the size recommended by the TIFF specs. Is there any specific reason you chose one megabyte?
1 Mb is above the page size for the largest expected fax page (11x17 page at 200 dpi). It's small enough that host based Ghostscript implementations that generate tiffs should have no problem with that much ram.
Thank you, I am convinced :) I've just committed the change (r10928).
From where do you conclude that the maximum size of an 11x17" page at 200 dpi is 1MB? Data compression varies with the data itself, and if we're talking about G4/MMR compression there are some images which actually encode *worse* than leaving them uncompressed (so encoding them actually increases the data space used). Furthermore, 200 dpi is by no means the highest resolution supported by fax. Currently ITU-T.30 supports resolutions at least up to 1200 dpi. Do you recommend, therefore, that those applications always use -dMaxStripSize=0 ?
(In reply to comment #5) > From where do you conclude that the maximum size of an 11x17" page at 200 dpi > is 1MB? Data compression varies with the data itself, and if we're talking > about G4/MMR compression there are some images which actually encode *worse* > than leaving them uncompressed (so encoding them actually increases the data > space used). I can't comment on the rest of your questions, but 11x 17 at 200dpi (at 1 bit) comes to 0.935 MiB exactly, and with overheads, would be under 1MB. I don't remember the details of the worse case scenario for G4, but I think it is possibly adding 1/8 on top. Any "normal" work load never get anywhere near the worst-case compression scenario. e.g. if you have 1/8 of areas as white borders, which compresses very well, would compensate for the rest of the page being white-noise.
Created attachment 6255 [details] 11x17 blue background PDF
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.
(In reply to comment #8) > 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 is up to Lars, but I think there is a penalty (memory?) for too-large a MAxStripSize. The current decision is based on a compromise between not punishing normal usage vs inconvenience of special/large applications.
> It is up to Lars, but I think there is a penalty (memory?) for too-large a > MAxStripSize. The current decision is based on a compromise between not > punishing normal usage vs inconvenience of special/large applications. Exactly. Libtiff holds the data for a single strip in memory, so putting the whole image into one strip is just not reasonable in the general case. The 1M-default for MaxStripSize was chosen because some fax software cannot read Multi-Strip TIFF files: Since *most* fax pages fall under the 1M limit, the whole image ends up in one strip for those cases (just as it did for gs < 8.71). Lee, do you have a specific problem with such faulty fax software? Only then would I recommend -dMaxStripSize=0.