#517441 tiff2pdf does not produce pdf when writing to stdout

Package:
libtiff-tools
Source:
tiff
Description:
TIFF manipulation and conversion tools
Submitter:
Joerg Dorchain
Date:
2015-06-15 19:15:18 UTC
Severity:
normal
#517441#5
Date:
2009-02-27 19:58:42 UTC
From:
To:
Hello,

when creating a pdf to stdout with tiff2pdf tt.tiff, the stdout
has the beginning of a tiff header prepended. tiff2pdf tt.tiff |
od -c looks like this:

0000000   I   I   *  \0  \0  \0  \0  \0   %   P   D   F   -   1  .   1
0000020      \n   % 342 343 317 323  \n   1       0       o   b  j  \n

This is especially bad as the magic autodetection by file does
not recognize it as pdf.

Writing a a file (tiff2pdf -o tt.pdf tt.tiff) works btw.

Test tiff file is attached.

Bye,

Joerg

#517441#12
Date:
2013-02-02 12:48:37 UTC
From:
To:
And after nearly four years the bug is still open.

These are the errors I get...

TIFFAppendToStrip: Maximum TIFF file size exceeded.
tiff2pdf: Error writing encoded strip to output PDF -.
TIFFAppendToStrip: Maximum TIFF file size exceeded.
TIFFWriteDirectorySec: Error flushing data before directory write.
tiff2pdf: Error writing virtual directory to output PDF -.
tiff2pdf: An error occurred creating output PDF file.
TIFFAppendToStrip: Maximum TIFF file size exceeded.



# tiffinfo fax.tiff
TIFF Directory at offset 0x1d0ce (118990)
   Image Width: 1728 Image Length: 2135
   Resolution: 204, 196 pixels/inch
   Bits/Sample: 1
   Compression Scheme: CCITT Group 3
   Photometric Interpretation: min-is-white
   FillOrder: lsb-to-msb
   Orientation: row 0 top, col 0 lhs
   Samples/Pixel: 1
   Rows/Strip: (infinite)
   Planar Configuration: single image plane
   Page Number: 0-1
   ImageDescription: 13148634530
   Software: Spandsp 20110122 075024
   DateTime: 2013/02/01 22:22:30
   HostComputer: asterisk
   FaxRecvTime: 76
   FaxDcs: 00 46 1F 23 01 01 01 01 01 00
   Group 3 Options: 2-d encoding+EOL padding (5 = 0x5)
   Fax Data: clean (0 = 0x0)

#517441#17
Date:
2013-02-02 12:45:51 UTC
From:
To:

#517441#22
Date:
2013-02-04 02:48:50 UTC
From:
To:
"Marc F. Clemente" <marc@mclemente.net> wrote:

I'm very sorry that this bug is still open after four years.  However,
you may notice that the bug is marked as forward to upstream, and the
bug can be found upstream at
http://bugzilla.maptools.org/show_bug.cgi?id=2078.  The problem is that
there is very light work on libtiff upstream right now as no one is
focused on it as a primary focus.  For the most part, bugs in utilities
like this only get fixed if someone supplies a patch, even though this
bug is caused by something inside the library.  I am not personally in a
position to study this enough to generate a patch, particularly since
there are other alternatives available.

My recommendation would be to use a different tool to generate PDF files
from tiff files.  A disproportionate number of the debian bugs reported
against the tiff software in the years since I've been maintaining it
have been with tiff2pdf.  I don't think that particular tool was well
written.  It seems to make a lot of incorrect assumptions.

Instead, I would recommend that you use a different tool for creating
PDF files from tiff files.  Imagemagick and graphicsmagick can both
convert tiff to PDF and write to stdout.  You can use "convert file.tiff
PDF:-" or "gm convert file.tiff PDF:-" instead to do the conversion.  I
think this will generally give you better results.  GraphicsMagick
creates better PDF files than ImageMagick since it uses better
compression on the image, so my recommendation if you want to create PDF
files to stdout from tiff files is to use gm convert as in the example
above.

I hope this helps.  I can continue leave this bug open if you want,
though, realistically, it's not likely to get addressed.  Perhaps
someone will contribute a completely rewritten tiff2pdf someday that
won't have this problem.

#517441#27
Date:
2013-02-08 00:06:48 UTC
From:
To:
Jay Berkenbilt <qjb@debian.org> wrote:

I appreciate this bug being here and open as I just ran into this
today.  The open bug helped me understand the situation and confirmed
I wasn't crazy.

Interestingly this problem doesn't happen on libtiff 3.9.4.  I hit the
bug when migrating a service from a debian box running that version to
one running libtiff 4.0.2.

Since we have a working version to compare against, perhaps I'll get
ambitious sometime and bisect the issue to figure out where it got
introduced.