Bug 688434

patch is good, please commit and close.

Thanks.

Ignore the last comment it is for bug 688433

This looks like we are not aligning the ends of curves to the expected
angle (start and end of the eliipse should be horizontal). When we
flatten the curve the first and last segments are not vertical.

A small sequence which shows the problem is:

/m /moveto load def /c /curveto load def
5 5 scale 10 setlinewidth 10 10 translate
3 15.5038 m 3 23.2558 20.3488 28.0077 40.6976 28.0077 c
61.0464 28.0077 78.3952 23.2558 78.3952 15.5038 c
78.3952 7.7519 61.0464 3 40.6976 3 c
20.3488 3 3 7.7519 3 15.5038 c
stroke
showpage

Created attachment 2040 [details]
e.zip

For the supplied Postscript Adobe CPSI renders same as Ghostscropt - zee the
TIFF in the ZIP attached.

Patch to HEAD :
http://ghostscript.com/pipermail/gs-cvs/2006-March/006409.html

Please ignore copmment #5 - it was intended for another bug.

The PS interpreter appears compatible to CPSI.
The problem happens in the PDF interpreter only.
It must execute "true .setaccuratecurve

Passing to Ray, because don't know where toi insert "true .setaccuratecurves" 
into the PDF interpreter.

The location for setting 'accuratecurves' is in pdf_main.ps:

--- lib/pdf_main.ps     (revision 6650)
+++ lib/pdf_main.ps     (working copy)
@@ -155,11 +155,13 @@

 /dopdfpages {   % firstpage# lastpage# dopdfpages -
   << /PDFScanRules true >> setuserparams       % set scanning rules for PDF vs. PS
+  true .setaccuratecurves                      % unlike PS, PDF seems to need this
   1 exch
     { dup /Page# exch store
       QUIET not { (Page ) print dup == flush } if
       pdfgetpage pdfshowpage
     } for
+  false .setaccuratecurves                     % unlike PS, PDF seems to need this
   << /PDFScanRules null >> setuserparams       % restore scanning rules for PS
 } bind def


After running a regression test, I'll commit this. Hopefully 'leo' will
have cleaned up the regression report so that I will be able to
update for any differences. Differences are expected (annots.pdf at the
very least).

The patch for 'accuratecurves' has been committed as a rev. 6681 on 2006-3-23
but the bug report was not closed. Closing it now.

Are you sure it is fixed? I can still see the clipped eclipse in Ghostscript
8.60 under GSView.

Although the fixed code has been submitted to the source during 8.5x, as of
8.60, the gap on the left side of a ellipse is still visible in the annots.pdf
supplied with Ghostscript under high magnification (432 dpi), especially in
Ellipses Cyan, Magenta, Blue.

In addition, when resolution and zoom resolution are set to 746 and 300 dpi
respectively, The edge of Ellipse Magenta can be seen as a combination of
antialiased flat lines, rather than a smooth curve.  Strangely, the flat edge is
not visible when resolution is set to 895 dpi.

When increasing zoom ratio, the number of flat lines at the outer edge of
Ellipse Blue increases.

When annots.pdf is viewed in Acrobat Reader 5, there are no flat lines at the
edges of ellipses.

I am not sure if those two bugs are related, but I also noticed that the gap is
wider for flatter ellipses, and the gap is deeper for ellipses with wider lines.
 If they are related, then Ghostscript needs a different way to render ellipses.

In any case, both problems should be fixed at once.

Created attachment 3506 [details]
patch

Move "true .setaccuratecurves" to the PDF graphic state initialization
where it belongs. This fix enables accurate curve rendering by GSview
doesn't use some parts of Ghostscript startup code.

Previous patch worked for a stand-along Ghostscript but didn't work
for GSview.

Regression testing shows no differences.

The patch has been committed as a rev. 8331.