AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
March 2000

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



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" <ghost@aladdin.com> -----

X-POP3-Rcpt: utx@k332
Date: Mon, 20 Mar 2000 00:45:57 -0800
From: "L. Peter Deutsch" <ghost@aladdin.com>
To: utx@k332.feld.cvut.cz
CC: bug-gs@aladdin.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 -----

-- 
Stanislav Brabec