You need to log in before you can comment on or make changes to this bug.
I have the following problem creating a pdf file with tiff2pdf (v 1.37.2.6 2008/09/03): Using a tiled input tiff file consisting of jpeg-encoded tiles, all the tiles on the right edge are broken (the lines are shifted against each other). The problem only appears, if the image width is not a multiple of the tilewidth, which means that every last horizontal tile does not have the full width. It seems that the displacement of the lines behaves as follows: If the rightmost tiles of the input tiff contain N columns less than the others, each line in those tiles in the output pdf is N pixels shifted to the right in relation to the line above. The problem only occurs with jpeg compressed, tiled input tiff.
Created an attachment (id=272) [details] The input TIFF file (with jpeg compressed tiles), which produces the problem
Created an attachment (id=273) [details] The PDF output created by: tiff2pdf -o cp-tiled.pdf cp-tiled.tif
I think what is going on here is that each JPEG-compressed tile is of dimensions 1024x64, ie, the nominal tile size (which is what is specified by TIFF Tech Note #2). However, for the tiles at right and bottom edges, tiff2pdf.c emits /Width 590 and/or /Height 41 in the object definitions in the PDF file. The messed-up display is consistent with the idea that the PDF decoder is expecting /Width and /Height to match the actual raster dimensions of the compressed data. I think the correct fix is to emit /Width and /Height matching the logical tile dimensions in all cases, and then make use of a Postscript graphical masking operator to hide the garbage data at right/bottom. The latter is unfortunately far beyond my Postscript-fu.
I did a quick experiment with hacking tiff2pdf.c to produce the /Width and /Length as suggested above. This produced the effects I expected: in evince, instead of complete garbage for the edge tiles, we see the expected data out to the intended image edge, and then junk beyond that. With this particular image the "junk" is a repetition of some of the image data, which no doubt tells us something about the buffer layout used by the image creator. Interestingly, this display matches what I see in Apple's Preview for *either* version of the output file. So apparently Apple's implementation doesn't pay much mind to the /Width and /Length tags, and just decompresses and displays the image data no matter what. The graphical masking hack would be the only way to make that work as desired.
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.
