Might warrant higher severity as it is causing my fax program
(hylafax) to fail.  However, it seems to only arise in certain
circumstances.

gv fails when reading the attached file.
<quote>
status:Error: /undefined in ff\
Operand stack:\
\
Execution stack:\
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--\
Dictionary stack:\
   --dict:1155/1684(ro)(G)--   --dict:0/20(G)--   --dict:92/200(L)--   --dict:1/100(L)--\
Current allocation mode is local\
Last OS error: 2\
GPL Ghostscript GPL Ghostscript 8.628.62: : Unrecoverable error, exit code 1\
Unrecoverable error, exit code 1
</quote>

This file was created with the following steps:
1. scan a small image to a .png file.  Uses iscan, not a debian package.
2. edit the file in gimp and save as .png.
3. send a fax.  This results in the following transforms (key commands pulled out and intermediate file names assigned)
   a) convert -depth 8 -density 80.000000x77.000000 -units PixelsPerCentimeter -geometry 1251x319! test1s2.png tiff:test1s3.tiff
     That's from a helper script I wrote to normalize the images.
   b) tiff2ps -a test1s3.tiff > test1s4.ps
     That's invoked by hylafax
   c) gv test1s4.ps

I usually do this without step 2 and it usually works.  gimp saves the
image in a different format (256c vs 2c) than the scanned png's, and I
think this triggers the misbehavior.  If I use ImageMagick's convert
to make the file produced in 2) have -type BiLevel, everything works.

reassign 611141 libtiff-tools
retitle 611141 tiff2ps: producing broken file (4 hex digits for 8 bits)
thanks

* Ross Boylan <RossBoylan@stanfordalumni.org> [110125 23:19]:

Actually it is gs failing to parse the file and that is no surprise
as the file is broken.

It looks like something is writing 4 hex digits for any value instead
of two. Thus there is image data after gs finished the image, so gs
complains about the unknown "ff".

This can be easily verified by replacing the 8 in line 19 with a 16.
After this modification the file is handled just fine.

Thus I'm reassigning to libtiff-tools, as I guess that is where
your tiff2ps is from.

Please send information to this bug report about the version of
libtiff-tools and its dependencies, so that the maintainer of that
package has all the information needed. (Perhaps attaching the png
file given to tiff2ps might also help).

	Bernhard R. Link

ii  libc6                  2.7-18lenny7      GNU C Library: Shared libraries
ii  libjpeg62              6b-14             The Independent JPEG Group's JPEG
ii  libtiff4               3.8.2-11.3        Tag Image File Format (TIFF) libra
ii  zlib1g                 1:1.2.3.3.dfsg-12 compression library - runtime

BTW, is there a good way to get that list?  I ran reportbug to start a
bug report, and then copied out the relevant parts.

I've attached the input (s3 for stage 3 in the name) for tiff2ps, as
well as prior stages in the processing.  test1 is the raw scan; test1s2
is stage 2, after processing by gimp.

Ross

Problem was lack of proper handling for EXTRASAMPLE_UNASSOCALPHA in tiff2ps.
Attached patch should fix this and related issues (should be applicable to
3.9.latest and 4.0.latest)
Warning: only minimal testing passed, likely should be forwarded to and handled
by upstream.

Yuriy M. Kaminskiy wrote:

Sorry, previous patch (completely) incorrectly handled PLANARCONFIG_SEPARATE
(however, that has not introduced regression, it was broken before too). Better
patch attached (I've dropped *lvl2 changes, as they would require much more to
make it work and was not directly related to this bug).

And I noticed that this bug is actually duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552382
(which is also fixed by this patch).