2000.03.21 20:09 "tiff2ps [was Re: gs: pxlmono image bug]", by Stanislav Brabec
Hallo tiff developers, I am forwarding you mail from L. Peter Deutsch. The problematic image in dvips was created by tiff2ps, so this mail speaks about tiff2ps.
This describes tiff2ps behavior, which is legal in PostScript, but PostScript code is not so clear to be simply converted to other page description languages (here it was pxl).
----- Forwarded message from "L. Peter Deutsch" <firstname.lastname@example.org> -----
Date: Mon, 20 Mar 2000 00:45:57 -0800
From: "L. Peter Deutsch" <email@example.com>
In-reply-to: <200003200832.AAA08887@aladdin.com> (message from Stanislav
Brabec on Sun, 19 Mar 2000 11:01:28 +0100)
Subject: Re: gs: pxlmono image bug
> Details: I am adding small test file, which is incorrectly rendered on HP > LaserJet 6P with pxlmono. Similar bug occur on most greyscale
> images. Images are deformed (contain fuzzy data) and are ended by big > black rectangle.
This is not the first time I have seen an image from dvips that has this problem. The problem appears to be a bug in dvips. The image is rendered in strips, each of which has Height set to 72. However, in this case the image only has 106 rows. Thus the second image has Height = 72, but the input data terminates after 34 rows. In PostScript, this is perfectly legal. However, PCL XL, unlike PostScript, has no way to represent an image in which the amount of data is different from the initially declared height. The current PCL XL driver fills out the missing rows with black. There is even a comment in the source code saying that this is wrong. However, handling this correctly would require buffering the entire image in memory until the code knew whether or not all the rows were going to be supplied; this is not really feasible. I think the best course is to fill the missing rows with (opaque) white instead. I can certainly make this change as a fix.
----- End forwarded message -----