Bug 689469 - Incorrect clipping operation in vector output
Summary: Incorrect clipping operation in vector output
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 8.60
Hardware: PC Linux
: P4 major
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-19 16:21 UTC by Osamu Mihara
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
test case (7.72 KB, application/postscript)
2007-09-19 16:22 UTC, Osamu Mihara
Details
Patch proposal for the bug (1.59 KB, patch)
2007-09-19 16:23 UTC, Osamu Mihara
Details | Diff
output by a monochrome printer using opvp (before patch - incorrect output) (5.99 KB, application/pdf)
2007-09-19 16:30 UTC, Osamu Mihara
Details
output by a monochrome printer using opvp (after patch - correct output) (20.63 KB, application/pdf)
2007-09-19 16:31 UTC, Osamu Mihara
Details

Note You need to log in before you can comment on or make changes to this bug.
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.