Issue 115096

Created attachment 72077 [details]
the proposed patch

Created attachment 72078 [details]
some pictures which contain some lines/frames

Created attachment 72079 [details]
a pict where the result is <<worse>> than previously ( because of the clipping )

Created attachment 72080 [details]
a pict to illustrate << my spline bug>> ( each corner is composed of an unique spline curve)

assign to owner

@sj: please have a look

sj->osnola: Your patch looks nice, but I have to note that we have a loot of
helper functions in basegfx which are working with the same principle as in your
patch. Please have a look at
ooo/basegfx/inc/basegfx/polygon/b2dpolygontools.hxx: createPolygonFromEllipse or
createPolygonFromEllipseSegment.

Is it possible that you change your patch to use the basegfx toolkit ? 

Using createPolygonFromEllipse, createPolygonFromEllipseSegment, createPolygonFromRect seem 
effectively a good idea and will probably simplify the code. 

I will try to give some news next week ( ie. because of the last java update 1.6.0_22, my sources of 
OpenOffice no longer compile ; so before doing any test, I will need first to get again a working version, 
which may take some time :-~ ).

So a new version which uses the functions of b2dpolygontools which indeed simplifies a lot the code.

The result between this version and the previous one seem quite similar except that in some case where b2dpolygontools seems to generate odd splines. Therefore I will also attach pict.bugs which 
contains two examples which seem to err a lot with the following extensions:
- .pict: the original picture,
- .pict.ascii: the picture parsing,
- .pict.tiff: the quickdraw result,
- .pict.old.png: my previous result when I generated by hand the splines,
- .pict.new.png: the new result obtained with b2dpolygontools functions with a red grid to show coordinates.

	I dig a little to understand what happens:
For Image280, the small arc around O does not look like a arc ; for the three arcs around O, the program constructs a B2DPolygon by calling
	<< tools::createPolygonFromEllipseSegment(Pt, dim[0], dim[1], angl[0], angl[1]);>> with
      		Arc: Pt=21x210, dim=62x62, angl=5.60251x1.74846e-07 // Ok, the intermediate arc
      		Arc: Pt=20x210, dim=89x89, angl=5.27089x5.61996       // Ok, the biggest arc
      		Arc: Pt=21x208, dim=56x56, angl=5.67232x0.0174534  //  the small arc which seems bugged
For Image7239, there must be two ellipses (*) around B and J ; in these case, 
          the program constructs the B2DPolygon by calling  <<tools::createPolygonFromRect(Rect, 1., 1.); >> with
		RoundRect: Rect=125x33<->143x56 // ellipse around B
	      	RoundRect: Rect=44x92<->61x113 // ellipse around J
so I guess that the problem was in b2dpolygontools, but I did not have time to dig further....

(*) in fact, the picture asks to clear two round rectangles with maximum round corners, which is a complicated way to define an ellipse....

Created attachment 75159 [details]
the new proposed patch

Created attachment 75160 [details]
the new problematic pictures

sj->osnola: Many thanks for your help and reworking your previous patch, it
looks really good now. Your patch has been applied to cws[impress204] for OOo 3.4

I think the remaining problems with the arc can be traced back to 
void OutputDevice::DrawPolyLine where a conversion from b2dpolygon with double
precision to a tools polygon with integer precision takes place.

This problem should be fixed automatically when activating the new
MetaB2DPolyLineAction (but I don't know when this happens).

Another fix could be to scale the b2dpolygon before drawing, so that the
conversion from double to int polygon isn't as lossy as it is now (the
corresponding MapMode needs to be set to the device then)

> Many thanks for your help and reworking your previous patch
No problem ; as these b2dpolygontools functions exist, it was quite natural to rewrite the patch to use them...

> I think the remaining problems with the arc can be traced back to 
> void OutputDevice::DrawPolyLine where a conversion from b2dpolygon with double
> precision to a tools polygon with integer precision takes place.

I dig a little more, and indeed the problem seems to come from OutputDevice::DrawPolyLine but I am not sure that the problem comes only from the double to 
int conversion:

Ie. For the  Arc: Pt=21x208, dim = 56x56, angl = 5.67232x0.0174534
 b2dpolygontools generates the Polygon (*): 
       Pt0:pos = 66.8725x175.88, prev = _, next = 67.858x177.287
       Pt1:pos = 69.4974x180, prev = 68.6383x178.512, next = 74.6521x188.928
       Pt2:pos = 77x208, prev = 77x197.691, next = 77x208.344
       Pt3:pos = 76.9915x208.977, prev = 76.9975x208.634, next = _
which seems correct ; I will attach a picture which zooms the problematic arc, where I have added:
   - in blue the segments from the previous control point to position
   - and in green the segments from position to the next control point 
with the basic coordinate grid alignment.

The picture made me think that OutputDevice::DrawPolyLine had used the next control point of Pt0 (instead of the previous control point of Pt1) to draw the 
second spline...

(*) where 
- pos is the point obtained by poly.getB2DPoint(i)
- prev is the point obtained by poly.getPrevControlPoint(i)
- next is the point obtained by poly.getNextControlPoint(i)

Created attachment 75177 [details]
a zoom of the small arc

Sorry, I was out of time last week. I added HDU as cc, he is more firm with our
polygons and he promised me to take care of your suspicion.

If this is a bug in our polygon conversion it needs to be fixed. 

osnola->sj : Ok, no problem.

In fact, I found the problematic function and I opened a new issue : http://www.openoffice.org/issues/show_bug.cgi?id=115917 .

sj->wg: to verify this issue, just compare the pictures of sample.zip with an
older version of OOo.

Verified in CWS.