2020.05.19 16:45 "Re: [Tiff] Tiff Digest, Vol 19, Issue 2", by Bob Friesenhahn
I'm using pdfimages to process a PDFs which results in some ccitt files. Using fax2tiff I'm able to turn those into slightly more manageable tiffs. Here's the problem: in some cases fax2tiff produces files that seem to be 1 row too long. Here's some example output when I use the verbose mode on one such file:
> Fax4Decode: Warning, Premature EOL at line 5200 of strip 4294967295 (got 0, expected 3450).
> 5201 rows in input
> 0 total bad rows
> 0 max consecutive bad rows
I downloaded your file and ran fax2tiff -v -4 -P -X 3450 -B -M -o alex-039.tif alex-039.ccitt, followed by tiffinfo alex-039.tif. I was suspicious of the large value for the strip number reported in your error message and this is confirmed by the output of tiffinfo on the output file.
Since FAX and CCITT Group 3 are normally compressed as one big chunk and the underlying nature of FAX is a continual data stream, it does not seem unusual to have an abnormally large Rows/Strip value. A simple solution is to set rows per strip to be image length, or treat it as such. If image length is wrong, then there is a problem with the input file.
While I am not familiar with the code for fax2tiff, it appears this behavior is due to running off the end of the data when the rows per strip tag doesn't get set correctly. The fix might be as simple as updating the Image Length field when this happens. Hope this helps.
It is likely that libtiff's focus on fixing security weaknesses makes it less good at "repairing" files which contain usable data but bad metadata. An apparently truncated input file could be "repaired" up to the last good decoded pixel row.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt