gEDA-dev: Fix for bug #1612660

Peter Clifton pcjc2 at cam.ac.uk
Fri Apr 13 21:18:00 EDT 2007


I've uploaded a patch to the SF trakcer fixing bug:

[ 1612660 ] gschem: issues with circles with dashdotted lines

http://sourceforge.net/tracker/index.php?func=detail&aid=1612660&group_id=161080&atid=818426

The patch:

[ 1700428 ] Fix for dotted circle and arc drawing, bug#1612660

http://sourceforge.net/tracker/index.php?func=detail&aid=1700428&group_id=161080&atid=818428

The "bug" itself was:

     gdk_draw_arc(w, gc, FALSE,
-                 x + radius, y + radius, 2 * radius, 2 * radius,
+                 x - radius, y - radius, 2 * radius, 2 * radius,

This is in a code-path which drew the arc when the dot-angular spacing
is less than 1 degree. (Hence it not being noticed before).


The patch also removes some superfluous (double) and (int) casts.

Things like:

-  da = (int) ((length * 180) / (M_PI * ((double) radius)));
+  da = length * 180 / (M_PI * radius);

I was attracted to them, as they weren't consistent throughout the file.

Can I get some feeling for whether this is portable (it must be - C is a
standard, right?), but will compilers other than gcc complain about the
implicit conversions?

This works as is, because M_PI is a double, and (M_PI * radius) will
thus also be a double - in-spite radius being an integer. The division
is performed with doubles, and the result is a double, then cast to int
implicitly by storing it in da (an integer). --- I think

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



More information about the geda-dev mailing list