After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331372 - Arc object disappears
Arc object disappears
Status: RESOLVED FIXED
Product: dia
Classification: Other
Component: win32
0.95-preX
Other Windows
: Normal normal
: 0.95
Assigned To: Steffen Macke
Dia maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-16 05:42 UTC by Steffen Macke
Modified: 2006-07-15 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the why we should not recalculate (5.20 KB, image/png)
2006-02-26 11:48 UTC, Hans Breuer
Details

Description Steffen Macke 2006-02-16 05:42:40 UTC
The arc object disappears in approximately half of the cases.
Reported by Rob McDonald, confirmed by Steffen

1. Make a new diagram
2. Draw an arc between two adjacent grid points
3. Move the arc midpoint back and forth -- on one side it disappears, on
the other it's there.
Comment 1 Hans Breuer 2006-02-17 21:57:27 UTC
Confirmed - but *only* if drawn with endpoints. Apparently
I was not able to fix it as I thought. So someone should
try but also keep in mind the bug that was fixed.

2006-01-06  Hans Breuer  <hans@breuer.org>

	* lib/diarenderer.c : the righthand calculation accidentially broke
	some arcs direction. Should be fixed again.

2006-01-02  Hans Breuer  <hans@breuer.org>

	* lib/diarenderer.c(draw_arc_with_arrows) : don't recalculate center
	point and width from the (arrow-)corrected new points. Otherwise a 
	whole new wrong arc may emerge. Fixes bug #312641.
Comment 2 Lars Clausen 2006-02-20 07:02:32 UTC
Looks like the if statement in diarenderer.c line 1279 makes it go away.  Removing the if makes it appear, though it is broken in some rarer cases.  Why no drawing should take place if the start and end points are close together I don't understand -- that doesn't imply that the circle itself is small.
Comment 3 Lars Clausen 2006-02-20 21:14:43 UTC
Committed a fix for non-degenerate arcs.  Arcs with same start & endpoint are currently broken, special handling required.
Comment 4 Hans Breuer 2006-02-26 11:48:29 UTC
Created attachment 60148 [details]
the why we should not recalculate

Your 'fix' does revert the fix for bug #312641. It not only breaks for identical start- and endpoint but also for small arcs where the 'gap adjustment' on the tagentials causes the creation of a whole new arc (see attachement).

I thought I explained the issue in the source - but apparently not good enough:

   righthand = is_right_hand (startpoint, midpoint, endpoint);
@@ -1255,6 +1268,10 @@
   /* Now we possibly have new start- and endpoint. We must not
    * recalculate the center cause the new points lie on the tangential
    * approximation of the original arc arrow lines not on the arc itself. 
    * The one thing we need to deal with is calculating the (new) angles 
    * and get rid of the arc drawing altogether if got degenerated.
+   *
+   * Why shouldn't we recalculate the whole thing from the new start/endpoints?
+   * Done this way the arc does not come out the back of the arrows.
+   *  -LC, 20/2/2006
    */
   angle1 = -atan2(startpoint->y - center.y, startpoint->x - center.x)*180.0/G_PI;
   while (angle1 < 0.0) angle1 += 360.0;

If the arcs length is short enough - i.e. smaller than the sum of gaps -
the new points are moving on the 'other side' of the original center point.
Constructing an arc from the three points results in the arc changing 
direction.
Comment 5 Lars Clausen 2006-03-05 20:52:09 UTC
Can't reproduce 312641 in 0.95-pre3.  
Comment 6 Hans Breuer 2006-07-15 16:06:36 UTC
I can easily reproduce bug #312641 with the most recent version. 
No surprise with that ;) Closing this one and reopening the other.
Thanks for your cooperation!
Comment 7 Hans Breuer 2006-07-15 17:23:15 UTC
moving away form 0.95-pre1 to delete that label afterwards. Sorry for the noise.