Bug 689469

Summary:	Incorrect clipping operation in vector output
Product:	Ghostscript	Reporter:	Osamu Mihara <osamu.mihara>
Component:	General	Assignee:	Ken Sharp <ken.sharp>
Status:	NOTIFIED FIXED
Severity:	major
Priority:	P4
Version:	8.60
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---
Attachments:	test case Patch proposal for the bug output by a monochrome printer using opvp (before patch - incorrect output) output by a monochrome printer using opvp (after patch - correct output)

Description Osamu Mihara 2007-09-19 16:21:26 UTC

Using "opvp" (OpenPrinting Vector Printer) device and vector printer drivers,
such as NEC's NPDL driver or Canon's LIPS driver, printing the attached test
file resulted in incorrect output.  Output to the screen or raster devices have
no problem.

The cause of the problem is in gdevvec.c.  An error is detected in
gdev_vector_prepare_fill() function by some reason, and the clipping function
gdev_vector_update_clip_path() is skipped, resulted in clipping problem.  Same
procedure can be found in stroking procedure.

I have attached a patch to avoid this problem.  With the patch, order of calling
fill and clip_path are swapped and clipping is applied even when a fill function
detects an error.  I have done some regression test and cannot see any degrade
by this patch.

Comment 1 Osamu Mihara 2007-09-19 16:22:42 UTC

Created attachment 3397 [details]
test case

Comment 2 Osamu Mihara 2007-09-19 16:23:34 UTC

Created attachment 3398 [details]
Patch proposal for the bug

Comment 3 Osamu Mihara 2007-09-19 16:30:17 UTC

Created attachment 3399 [details]
output by a monochrome printer using opvp (before patch - incorrect output)

This is an output (before patch) by a monochrome printer using opvp.  The PS
data draws tree circles in yellow, blue and red.  Please do not care about
yellow circle, which is not printed because of the color is pale.  The rest two
circles are not printed correctly because the clipping is not processed
correctly.

Comment 4 Osamu Mihara 2007-09-19 16:31:04 UTC

Created attachment 3400 [details]
output by a monochrome printer using opvp (after patch - correct output)

This is the correct output.

Comment 5 leonardo 2008-01-31 04:01:41 UTC

Ken please check whether the supplied path doesn't break pdfwrite.

Comment 6 Ken Sharp 2008-03-18 06:16:10 UTC

pdfwrite is unaffected by the change to gdev_vector_fill_path, since it does not
call this method. pswrite (not ps2write) does use the method, but is not
apparently affected by the change.

Neither pdfwrite nor pswrite appear to use gdev_vector_stroke_path and hence are
unaffected by the proposed change.

In fact very few devices do use these methods, of the standard devices (that is
not in /gs/contrib or similar) there is pswrite (which is pretty much deprecated
?) and gdevpx.c, the "H-P PCL XL" device. Perhaps Henry should have a look at
this patch ?

For what its worth, it seems to be OK from my point of view.

Comment 7 Ken Sharp 2008-03-26 07:11:41 UTC

Having run regression tests using pswrite, with no detected errors, patch committed:

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

Thanks to Osamu Mihara for the diagnosis and patch.