diff options
| author | mjwybrow <mjwybrow@users.sourceforge.net> | 2007-08-09 04:10:02 +0000 |
|---|---|---|
| committer | mjwybrow <mjwybrow@users.sourceforge.net> | 2007-08-09 04:10:02 +0000 |
| commit | c0f3faf0dfcb0f4cdb257324b118fa5a121773b3 (patch) | |
| tree | a11d4b4197e094a41458aec891a5bbc006181927 /src/conn-avoid-ref.cpp | |
| parent | copyedit, warning suppression (diff) | |
| download | inkscape-c0f3faf0dfcb0f4cdb257324b118fa5a121773b3.tar.gz inkscape-c0f3faf0dfcb0f4cdb257324b118fa5a121773b3.zip | |
2006-08-09 Michael Wybrow <mjwybrow@users.sourceforge.net>
* src/libavoid/shape.cpp, src/libavoid/router.cpp, src/libavoid/README,
src/libavoid/router.h, src/libavoid/geometry.cpp:
Some minor upstream changes to the libavoid library.
It now matches Inkscape and uses the correct winding direction.
* src/conn-avoid-ref.cpp:
Remove a 'TODO' and hack adjusting winding directions before
passing object convex hulls to libavoid.
(bzr r3431)
Diffstat (limited to '')
| -rw-r--r-- | src/conn-avoid-ref.cpp | 22 |
1 files changed, 1 insertions, 21 deletions
diff --git a/src/conn-avoid-ref.cpp b/src/conn-avoid-ref.cpp index 864eadbba..67538fb77 100644 --- a/src/conn-avoid-ref.cpp +++ b/src/conn-avoid-ref.cpp @@ -203,27 +203,7 @@ static Avoid::Polygn avoid_item_poly(SPItem const *item) poly = Avoid::newPoly(4); for (unsigned n = 0; n < 4; ++n) { - // TODO: I think the winding order in libavoid or inkscape might - // be backwards, probably due to the inverse y co-ordinates - // used for the screen. The '3 - n' reverses the order. - /* On "correct" winding order: Winding order of NR::Rect::corner is in a positive - * direction, like libart. "Positive direction" means the same as in most of Inkscape and - * SVG: if you visualize y as increasing upwards, as is the convention in mathematics, then - * positive angle is visualized as anticlockwise, as in mathematics; so if you visualize y - * as increasing downwards, as is common outside of mathematics, then positive angle - * direction is visualized as clockwise, as is common outside of mathematics. This - * convention makes it easier mix pure mathematics code with graphics code: the important - * thing when mixing code is that the number values stored in variables (representing y - * coordinate, angle) match up; variables store numbers, not visualized positions, and the - * programmer is free to switch between visualizations when thinking about a given piece of - * code. - * - * MathWorld, libart and NR::Rect::corner all seem to take positive winding (i.e. winding - * that yields +1 winding number inside a simple closed shape) to mean winding in a - * positive angle. This, together with the observation that variables store numbers rather - * than positions, suggests that NR::Rect::corner uses the right direction. - */ - NR::Point hullPoint = rExpandedHull.corner(3 - n); + NR::Point hullPoint = rExpandedHull.corner(n); poly.ps[n].x = hullPoint[NR::X]; poly.ps[n].y = hullPoint[NR::Y]; } |
