fix tiff parsing in CCITTFactory.extractFromTiff method - #508
Conversation
|
There's a tiff file here: I notice that the error messages in the existing code are switched. |
|
I tried with that file yesterday, wasn't successful, and today I think I understand what happens: the two options are not the same. The TIFF option inserts zeroes before the EOL so that the EOL ends at a byte boundary, the PDF option inserts zeroes before the next line so that it starts at a byte boundary. |
|
This is getting more and more mysterious. GROUP3OPT_BYTEALIGNED is from a file we copied from the twelvemonkeys project in 2016. However a look at its history shows that this didn't exist. He introduced it in 2020. The constant isn't used anywhere else in the code. |
I checked one more time by the tif file from PDFBOX-934 and here is really no bug. The GROUP3OPT_BYTEALIGNED constant is confusing. |

GROUP3OPT_BYTEALIGNED (bit 3, value 8) is silently ignored.
The tag-292 block never checks val & 8. But COSName.ENCODED_BYTE_ALIGN ("EncodedByteAlign") is a real, wired-up PDF DecodeParms key — CCITTFaxFilter.java:61 reads it (default false) and passes it straight to CCITTFaxDecoderStream. Since extractFromTiff copies the compressed bytes through unmodified, if the source TIFF was Group-3-encoded with byte-aligned rows, the resulting PDF needs /EncodedByteAlign true in its DecodeParms to decode correctly. Currently that flag is never set, so any such TIFF would produce a PDF image that decodes with progressively misaligned rows (visually corrupted/garbled output).