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