Bug 688992

Summary:	Problem while printing logo with pxlmono/pxlcolor drivers
Product:	Ghostscript	Reporter:	Francois Donnay <donnayf>
Component:	Other Driver	Assignee:	Marcos H. Woehrmann <marcos.woehrmann>
Status:	NOTIFIED FIXED
Severity:	normal	CC:	htl10
Priority:	P4
Version:	8.54
Hardware:	All
OS:	All
Customer:		Word Size:	---
Attachments:	Test file PXL ghostscript result Print result (scanned) proposed patch

Description Francois Donnay 2006-11-13 00:28:37 UTC

When I use the pxlmono/pxlcolor driver to print the file “test.pdf”, I have a 
black vertical line before the image logo.

I don’t have this problem with other driver.

I have scanned the result; you can see it in the file “test.tif”.

Thanks for your help,
Francois.

Comment 1 Francois Donnay 2006-11-13 00:30:01 UTC

Created attachment 2598 [details]
Test file

Comment 2 Francois Donnay 2006-11-13 00:31:07 UTC

Created attachment 2599 [details]
PXL ghostscript result

Comment 3 Francois Donnay 2006-11-13 00:31:47 UTC

Created attachment 2600 [details]
Print result (scanned)

Comment 4 Marcos H. Woehrmann 2006-11-13 07:01:54 UTC

What model printer are you using?

Comment 5 Francois Donnay 2006-11-13 07:55:22 UTC

I have this problem with all following printer:

HP Laser Jet 4100
HP Laser Jet 4200
Xerox Workcentre Pro 55
Xerox M165

Comment 6 Marcos H. Woehrmann 2006-11-14 09:54:44 UTC

I've been able to duplicate this on an LaserJet 4100; I'll look into fixing it.

Comment 7 Hin-Tak Leung 2006-11-15 03:24:36 UTC

Apologies - added my CC: from an old cached page and accidentially 
reverted Marcos's platform/OS update from windows/PC to all/all.

Comment 8 Marcos H. Woehrmann 2006-11-27 13:11:46 UTC

Created attachment 2635 [details]
proposed patch

I think I understand gdevpx.c enough to propose the following patch to fix this
bug (patch also attached):

*** gdevpx.c	2006-11-27 12:36:53.000000000 -0800
--- gdevpx.c	2006-11-27 12:57:39.000000000 -0800
***************
*** 1195,1200 ****
--- 1226,1236 ----
      code = gdev_vector_update_clip_path(vdev, NULL);
      if (code < 0)
	return code;
+ 
+     if (data_x !=0 )
+	    return gx_default_copy_mono(dev, data, data_x, raster, id, 
+					x, y, w, h, zero, one);  /* mhw */
+ 
      pclxl_set_cursor(xdev, x, y);
      if (id != gs_no_id && zero == gx_no_color_index &&
	one != gx_no_color_index && data_x == 0


However, I don't know how often (data_x != 0) will occur to be able to decide
if it would be worth the effort to modify pclxl_write_image_data() to handle
this case since the patch does have a performance/output file size issue.  

BTW, I'm guessing that data_x is used to indicate that the raster data start is
offset into the pixel buffer.  This is based on looking at the data and running
the code through a debugger, so I might be confused.  Also, I think that
pclxl_copy_color() is broken in that it checks for ((source_bit & 7) != 0),
which would imply that pclxl_write_image_data() can handle full byte offsets,
but it can't.

Finally, I believe there may be a problem in pclxl_write_image_data() since it 
appears to never compress the data, the s_RLE_template.process call fails and
the code reverts to writing uncompressed data.	I'm looking further into this.

Comment 9 Marcos H. Woehrmann 2008-03-02 17:18:04 UTC

Fixed in r8576:

http://ghostscript.com/pipermail/gs-cvs/2008-March/008161.html

Comment 10 Hin-Tak Leung 2009-11-10 17:48:17 UTC

The possible pclxl_copy_color() problem mentioned in comment 8 is (finally seen
as) bug 690862. Most of comment 8 is correct except the first paragraph -
gx_default_copy_mono() is more efficient than pclxl_copy_mono() for very small w
and h. See also http://bugs.ghostscript.com/show_bug.cgi?id=690862#c2 .