Bug 2502 - Premature EOL at line 0 of strip 0 (got 0, expected 1728)
: Premature EOL at line 0 of strip 0 (got 0, expected 1728)
Status: RESOLVED LATER
: libtiff
default
: unspecified
: PC Windows XP
: P2 normal
: ---
Assigned To:
: https://issues.apache.org/jira/browse...
:
: migrated_to_gitlab
:
:
  Show dependency treegraph
 
Reported: 2015-02-02 12:44 by
Modified: 2019-10-01 14:20 (History)


Attachments
TIFF file created by PDFBox (94.50 KB, image/tiff)
2015-02-02 12:44, Tilman Hausherr
Details


Note

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


Description From 2015-02-02 12:44:30
Created an attachment (id=611) [details]
TIFF file created by PDFBox

I get this with ImageMagick:

convert.exe: Premature EOL at line 0 of strip 0 (got 0, expected 1728).
`Fax3Decode1D' @ warning/tiff.c/TIFFWarnings/857.

The file is created by taking a CCITT stream from a PDF and attaching a
tailored TIFF header to it. IrfanView, ImageMagick and GIMP (tools that use
libtiff) can't display this file, Microsoft tools can. The data is CCITT G3
encoded.

I wonder whether the header is wrong, the data is wrong or whether the decoding
by libtiff is wrong. Or is it so that EOLs are allowed in CCITT G3 and PDF, but
not in TIFF? There's a quote in the TIFF spec "No EOL code words are used" and
in the PDF spec "The CCITTFaxDecode filter always accepts end-of-line bit
patterns".

I can't tell what version of libtiff is used, but it is probably not too old, I
downloaded ImageMagick today.
------- Comment #1 From 2019-10-01 14:20:02 -------
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets,
such as this one, have been migrated to the libtiff GitLab instance at
https://gitlab.com/libtiff/libtiff/issues .

The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is
the initial Bugzilla issue number.