Menu
▾
▴
lib2geom-devel — development discussion
You can subscribe to this list here.
| 2007 |
Jan
(2) |
Feb
(3) |
Mar
(4) |
Apr
(27) |
May
(5) |
Jun
|
Jul
(14) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(19) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(4) |
Apr
(28) |
May
(77) |
Jun
(79) |
Jul
(112) |
Aug
(36) |
Sep
(33) |
Oct
(19) |
Nov
(9) |
Dec
(11) |
| 2009 |
Jan
|
Feb
|
Mar
(12) |
Apr
(11) |
May
(13) |
Jun
(23) |
Jul
(5) |
Aug
(25) |
Sep
(9) |
Oct
(22) |
Nov
(16) |
Dec
(5) |
| 2010 |
Jan
(23) |
Feb
(12) |
Mar
(5) |
Apr
(29) |
May
(4) |
Jun
(9) |
Jul
(22) |
Aug
(2) |
Sep
(10) |
Oct
(6) |
Nov
(8) |
Dec
|
| 2011 |
Jan
(2) |
Feb
(44) |
Mar
|
Apr
(4) |
May
|
Jun
(9) |
Jul
(5) |
Aug
(4) |
Sep
(7) |
Oct
|
Nov
|
Dec
(10) |
| 2012 |
Jan
(16) |
Feb
(8) |
Mar
(9) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(6) |
Aug
(10) |
Sep
(48) |
Oct
(6) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
(3) |
Oct
(5) |
Nov
(35) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(4) |
Apr
(12) |
May
(6) |
Jun
(16) |
Jul
(25) |
Aug
(16) |
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
| 2015 |
Jan
(3) |
Feb
(1) |
Mar
(21) |
Apr
(10) |
May
(6) |
Jun
(3) |
Jul
(2) |
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(2) |
Dec
|
| 2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Krzysztof K. <twe...@gm...> - 2015-01-19 13:28:28
|
Is there any clever algorithm that I can use to compute intersections between Beziers and arcs? Or should I just convert the arc to a high degree Bezier or a Bezier spline and use the standard Bezier clipping algorithm? Regards, Krzysztof |
|
From: Johan E. <jbc...@sw...> - 2014-11-23 23:28:12
|
Thanks Nathan, I have added the path to the test. Could you have a look at the chain-test and make it pass? Thanks, Johan On 23-11-2014 22:25, Nathan Hurst wrote: > On Sun, Nov 23, 2014 at 06:39:17PM +0100, Johan Engelen wrote: >> Hi all, >> The chain-test is missing the file "sweep1.svgds". Perhaps someone >> has forgotten to commit that file? >> The test now just fails because it cannot find the file... > I can't be stuffed fighting with launchpad to get it let me commit, > here's the file: > > njh@:~/lib2geom$ bzr diff > === added file 'src/2geom/tests/sweep1.svgds' > --- src/2geom/tests/sweep1.svgds 1970-01-01 00:00:00 +0000 > +++ src/2geom/tests/sweep1.svgds 2014-11-23 21:23:54 +0000 > @@ -0,0 +1,3 @@ > +m 307,259 c 0,0 8,8 -3,11 -5,1 -5,9 -5,9 m 4,-17 1,3 m -6,-8 3,12 m > -9,-11 1,4 2,3 -1,4 3,3 -2,5 m -9,-19 4,14 > +m 296,280 5,-11 > +m 309,283 -5,-18 > |
|
From: Johan E. <jbc...@sw...> - 2014-11-23 23:04:35
|
I don't know. I didn't write any of it, so I am not attached to it. I can see that it would be useful to someone, also within Inkscape. But the current code is broken, so someone has to fix it (soon) or we move it to the orphan folder together with the tests. - Johan On 23-11-2014 22:26, Nathan Hurst wrote: > I don't think we use convex cover in inkscape, is it worth spending > time on? > > njh > > On Sun, Nov 23, 2014 at 08:12:40PM +0100, Johan Engelen wrote: >> Hi all, >> convex-test flags a bunch of errors in the convex cover code. There >> are apparently some errors in basic functionality. For example, the >> current code is not able to correctly calculate the convex cover of a >> square. (it does not sort the points correctly it appears) >> I looked at the code for a while, but want to stop here. Before spending >> the time to reimplement some of the algorithms, I hope someone who has >> worked on this before can have a look and perhaps find the bug more easily. >> >> Thanks, >> Johan >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >> _______________________________________________ >> Lib2geom-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel |
|
From: Nathan H. <nj...@nj...> - 2014-11-23 21:53:25
|
On Sun, Nov 23, 2014 at 06:39:17PM +0100, Johan Engelen wrote: > Hi all, > The chain-test is missing the file "sweep1.svgds". Perhaps someone > has forgotten to commit that file? > The test now just fails because it cannot find the file... I can't be stuffed fighting with launchpad to get it let me commit, here's the file: njh@:~/lib2geom$ bzr diff === added file 'src/2geom/tests/sweep1.svgds' --- src/2geom/tests/sweep1.svgds 1970-01-01 00:00:00 +0000 +++ src/2geom/tests/sweep1.svgds 2014-11-23 21:23:54 +0000 @@ -0,0 +1,3 @@ +m 307,259 c 0,0 8,8 -3,11 -5,1 -5,9 -5,9 m 4,-17 1,3 m -6,-8 3,12 m -9,-11 1,4 2,3 -1,4 3,3 -2,5 m -9,-19 4,14 +m 296,280 5,-11 +m 309,283 -5,-18 |
|
From: Nathan H. <nj...@nj...> - 2014-11-23 21:53:18
|
I don't think we use convex cover in inkscape, is it worth spending time on? njh On Sun, Nov 23, 2014 at 08:12:40PM +0100, Johan Engelen wrote: > Hi all, > convex-test flags a bunch of errors in the convex cover code. There > are apparently some errors in basic functionality. For example, the > current code is not able to correctly calculate the convex cover of a > square. (it does not sort the points correctly it appears) > I looked at the code for a while, but want to stop here. Before spending > the time to reimplement some of the algorithms, I hope someone who has > worked on this before can have a look and perhaps find the bug more easily. > > Thanks, > Johan > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Lib2geom-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel |
|
From: Johan E. <jbc...@sw...> - 2014-11-23 19:12:59
|
Hi all, convex-test flags a bunch of errors in the convex cover code. There are apparently some errors in basic functionality. For example, the current code is not able to correctly calculate the convex cover of a square. (it does not sort the points correctly it appears) I looked at the code for a while, but want to stop here. Before spending the time to reimplement some of the algorithms, I hope someone who has worked on this before can have a look and perhaps find the bug more easily. Thanks, Johan |
|
From: Johan E. <jbc...@sw...> - 2014-11-23 17:39:35
|
Hi all, The chain-test is missing the file "sweep1.svgds". Perhaps someone has forgotten to commit that file? The test now just fails because it cannot find the file... Thanks for checking, Johan |
|
From: Johan E. <jbc...@sw...> - 2014-11-16 22:20:44
|
Hi all, I've set up 2Geom automated builds, testing, and doxygen on Inkscape's Jenkins server. http://jenkins.inkscape.org:8080/ What I find pretty cool is that we now also have a trunk up-to-date version of our documentation: http://jenkins.inkscape.org:8080/job/2Geom_trunk_doxygen/doxygen/index.html This should make us more aware of the fact that we actually have a number of tests failing........!!! cheers, Johan |
|
From: Stuart A. <st...@ya...> - 2014-09-05 10:26:35
|
Cheers - I wasn't expecting a reply by now, and actually built these just the other day ... I fixed a couple of small bugs in one of the python examples, I should work out how to submit the fixes. S++ On Friday, September 5, 2014 12:16 AM, Krzysztof Kosiński <twe...@gm...> wrote: > > >2014-09-05 0:11 GMT+02:00 Johan Engelen <jbc...@sw...>: > >> We had python bindings working a while ago, but it was never fully finished >> and the most important functionality was lacking (as far as I remember). >> I think for now, it is no use for you to try and work with the py2geom >> bindings. I think the important path operations are not supported for >> example (like adding a piece to the path!). >> The cython bindings look further developed, but I have never succeeded in >> using them myself. >> >> I hope you can give the cython part a try and see if it works / does >> something useful for you. > >The cython bindings are a little bitrotted after my GSoC changes - >they need some work to be usable again. > >Regards, Krzysztof > > > > |
|
From: Krzysztof K. <twe...@gm...> - 2014-09-04 23:16:28
|
2014-09-05 0:11 GMT+02:00 Johan Engelen <jbc...@sw...>: > We had python bindings working a while ago, but it was never fully finished > and the most important functionality was lacking (as far as I remember). > I think for now, it is no use for you to try and work with the py2geom > bindings. I think the important path operations are not supported for > example (like adding a piece to the path!). > The cython bindings look further developed, but I have never succeeded in > using them myself. > > I hope you can give the cython part a try and see if it works / does > something useful for you. The cython bindings are a little bitrotted after my GSoC changes - they need some work to be usable again. Regards, Krzysztof |
|
From: Johan E. <jbc...@sw...> - 2014-09-04 22:12:11
|
On 20-8-2014 18:47, Stuart Axon wrote: > Hello lib2geom, > Where is the canonical place to download current lib2geom + python > bindings - (is it still the inkscape source for 2geom) ? > > Also - are there some examples for things like creating paths, > rendering in cairo and boolean ops ? Hi Stuart, Sorry for the long wait. This list is pretty quiet, and personally I am at the moment more focussed on working on Inkscape than lib2geom. The best place is probably our bzr repository: https://code.launchpad.net/~lib2geom-hackers/lib2geom/trunk (trunk is what you want) We had python bindings working a while ago, but it was never fully finished and the most important functionality was lacking (as far as I remember). I think for now, it is no use for you to try and work with the py2geom bindings. I think the important path operations are not supported for example (like adding a piece to the path!). The cython bindings look further developed, but I have never succeeded in using them myself. I hope you can give the cython part a try and see if it works / does something useful for you. kind regards, Johan |
|
From: Nathan H. <nj...@nj...> - 2014-08-21 10:36:42
|
On Thu, Aug 21, 2014 at 01:24:55AM +0200, Krzysztof Kosiński wrote: > 2014-08-20 22:10 GMT+02:00 Nathan Hurst <nj...@nj...>: > > > > The best algorithm for curve-curve intersection is inherently best > > done in bezier form (because it is optimal in a convex hull sense). > > Conversion is far cheaper than the alternatives (and we tried a > > bunch). Indeed one of my long term projects was to replace all the > > sbasis code with the bezier form and simplify the code base. > > "All the sbasis code" in the sense that sbasis-math.h would be > reimplemented for Bezier? Or does it mean only the intersection part? I mean all the sbasis code - the benefits of sbasis over bernstein basis are not sufficient to warrant the two code paths. > Is SBasis on its way out? I think so. njh |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-20 23:25:06
|
2014-08-20 22:10 GMT+02:00 Nathan Hurst <nj...@nj...>: > > The best algorithm for curve-curve intersection is inherently best > done in bezier form (because it is optimal in a convex hull sense). > Conversion is far cheaper than the alternatives (and we tried a > bunch). Indeed one of my long term projects was to replace all the > sbasis code with the bezier form and simplify the code base. "All the sbasis code" in the sense that sbasis-math.h would be reimplemented for Bezier? Or does it mean only the intersection part? Is SBasis on its way out? Regards, Krzysztof |
|
From: Nathan H. <nj...@nj...> - 2014-08-20 20:10:23
|
The best algorithm for curve-curve intersection is inherently best done in bezier form (because it is optimal in a convex hull sense). Conversion is far cheaper than the alternatives (and we tried a bunch). Indeed one of my long term projects was to replace all the sbasis code with the bezier form and simplify the code base. njh On Wed, Aug 20, 2014 at 06:43:34PM +0200, Krzysztof Kosiński wrote: > Is there a published algorithm for finding the intersections between > two 2D polynomials expressed in SBasis? > > Currently 2Geom seems only to contain intersection algorithms for > Bezier, and SBasis are just converted to Bezier to perform the > intersection. > > Regards, Krzysztof > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Lib2geom-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel |
|
From: Stuart A. <st...@ya...> - 2014-08-20 16:47:11
|
Hello lib2geom, Where is the canonical place to download current lib2geom + python bindings - (is it still the inkscape source for 2geom) ? Also - are there some examples for things like creating paths, rendering in cairo and boolean ops ? Cheers Stuart S++ |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-20 16:43:42
|
Is there a published algorithm for finding the intersections between two 2D polynomials expressed in SBasis? Currently 2Geom seems only to contain intersection algorithms for Bezier, and SBasis are just converted to Bezier to perform the intersection. Regards, Krzysztof |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-20 16:38:19
|
If "Remove Overlap" means adjusting kerning so that the letters are separated by a specific margin, then there is some support for this, but it requires exposing the routines in a way that is more usable. For instance, the intersection finding routines right now work only on Bezier. The methods for SBasis, EllipticalArc, Path and PathVector still need to be written. Regards, Krzysztof |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-18 13:32:35
|
2014-08-14 23:24 GMT+02:00 Nathan Hurst <nj...@nj...>: > On Thu, Aug 14, 2014 at 05:12:48PM +0200, Krzysztof Kosiński wrote: > ... >> Regarding the second issue, I added some unit tests that indicate that >> subdivision of one fragment (be it Bezier or SBasis) is actually >> exact, in the sense that A.at1() == B.at0(). The actual problem is the >> simultaneous subdivision of two fragments. If we have fragments A and >> B and we determine that they intersect at time values (a, b), we need >> an API that produces four Beziers A1, A2, B1, B2 such that A1.at1() == >> A2.at0() == B1.at1() == B2.at0() exactly. This is required because >> A.valueAt(a) will almost always be slightly different from >> B.valueAt(b). More generally, given a vector of time value pairs, we >> need to create a vector of result Beziers adhering to the above >> condition. > > That makes sense, nice analysis. I suspect averaging the results of > A1(a), A2(a) for x, B for y, and setting the end points appropriately > will be good enough. > > njh I implemented this procedure for Bezier. It is in basic-intersection.h. I discovered that SBasis subdivision is actually not exact, though very rarely. The problem manifested only for subdivision values very close to 0 or 1. Some example values for which subdivision generated incorrect results are: 9.236844517377745e-7 0.000002178347805105465 0.9999939507854229 0.9999942671178794 0.999997049626076 0.9999978101666039 This was probably caused by the implementation of portion() by means of compose(), where the calculation of endpoints involves a subtraction. This is now fixed by forcibly setting the endpoints to the result of valueAt at the specified times. Regards, Krzysztof |
|
From: Nathan H. <nj...@nj...> - 2014-08-14 21:25:06
|
On Thu, Aug 14, 2014 at 05:12:48PM +0200, Krzysztof Kosiński wrote: ... > Regarding the second issue, I added some unit tests that indicate that > subdivision of one fragment (be it Bezier or SBasis) is actually > exact, in the sense that A.at1() == B.at0(). The actual problem is the > simultaneous subdivision of two fragments. If we have fragments A and > B and we determine that they intersect at time values (a, b), we need > an API that produces four Beziers A1, A2, B1, B2 such that A1.at1() == > A2.at0() == B1.at1() == B2.at0() exactly. This is required because > A.valueAt(a) will almost always be slightly different from > B.valueAt(b). More generally, given a vector of time value pairs, we > need to create a vector of result Beziers adhering to the above > condition. That makes sense, nice analysis. I suspect averaging the results of A1(a), A2(a) for x, B for y, and setting the end points appropriately will be good enough. njh |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-14 15:12:56
|
Hello I found some old e-mails that indicate that the big problems that caused the topo-boolops failures are: 1. imprecision in root finding 2. imprecision in subdivision. The first issue is demonstrated by bezier-test and sbasis-test. This is a little puzzling to me, because the algorithm used for finding Bezier roots (convex hull marching) should in principle find roots up to the full precision of the representation. I saw some magic precision constants being used in the code, so that might be the culprit. If anyone has an idea of why roots are currently imprecise, let me know. Regarding the second issue, I added some unit tests that indicate that subdivision of one fragment (be it Bezier or SBasis) is actually exact, in the sense that A.at1() == B.at0(). The actual problem is the simultaneous subdivision of two fragments. If we have fragments A and B and we determine that they intersect at time values (a, b), we need an API that produces four Beziers A1, A2, B1, B2 such that A1.at1() == A2.at0() == B1.at1() == B2.at0() exactly. This is required because A.valueAt(a) will almost always be slightly different from B.valueAt(b). More generally, given a vector of time value pairs, we need to create a vector of result Beziers adhering to the above condition. Regards, Krzysztof |
|
From: Tavmjong B. <tav...@fr...> - 2014-08-11 09:30:21
|
Hi, I just noticed that Fontforge is investigating overlap removal and one option they are looking at is to use lib2geom (see thread "Release Objectives" at the end of June). I am wondering how well lib2geom handles overlap removal and if this is a possible area where we can collaborate with them. Tav |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-10 03:47:39
|
Hello I made an initial patch for using auto_ptr instead of raw pointers, but I have some problems with the py2geom binding. (I gave up trying to keep the cython binding working already a few revisions ago.) Can anyone advise what should be done to fix it? Regards, Krzysztof |
|
From: Krzysztof K. <twe...@gm...> - 2014-08-06 19:35:33
|
2014-08-05 21:29 GMT+02:00 Johan Engelen <jbc...@sw...>: > Ok, I see you're saying that "a 20 30 45 1 0 0,0" is ambiguous, hence > invalid and the parser can skip it. (degenerate line segments are not > ambiguous) > This would vote in favor of floating point comparison, but I think in > the interest of (human) predictability, the equals-check should be made > are_near. Do you agree? The epsilon of this comparison should not be hardcoded. For the case of Inkscape, I think it should depend on the numeric precision of output. (PS I somehow missed this thread and spammed the Inkscape mailing list about this.) Regards, Krzysztof |
|
From: Tavmjong B. <tav...@fr...> - 2014-08-05 19:55:35
|
On Tue, 2014-08-05 at 21:29 +0200, Johan Engelen wrote:
> On 5-8-2014 21:15, Tavmjong Bah wrote:
> > On Tue, 2014-08-05 at 20:46 +0200, Johan Engelen wrote:
> >> Hi all,
> >> Liam just committed a bug fix to Inkscape trunk, regarding our SVG
> >> parser.
> >>
> >> SVG spec says:
> >> "If the endpoints (x1, y1) and (x2, y2) are identical, then this is
> >> equivalent to omitting the elliptical arc segment entirely." [1]
> >>
> >> Liam changed the parser so that it will simply drop such segments:
> >>
> >> void _arcTo(double rx, double ry, double angle,
> >> bool large_arc, bool sweep, Point p)
> >> {
> >> + if (_current == p) { // sic, probably should be
> >> are_near(_current, p)
> >>
> >> + return;
> >> + }
> >> _quad_tangent = _cubic_tangent = _current = p;
> >> _sink.arcTo(rx, ry, angle, large_arc, sweep, p);
> >> }
> >
> >> I am not sure about this change. We are not dropping any degenerate
> >> bezier segments in our parser.
> > I think this is not the same as a degenerate bezier. This describes an
> > ellipse with given major and minor axis but there is no way to figure
> > out where along the ellipse one should start drawing. The following path
> > consists of four very different (almost complete) ellipses where the
> > final points are just a little bit different from the starting points:
> >
> > <path d="m 50,50
> > a 20 30 45 1 0 1,1
> > 20 30 45 1 0 -1,-1
> > 20 30 45 1 0 -1,1
> > 20 30 45 1 0 1,-1"
> > style="fill:none;stroke:black"/>
>
> Ok, I see you're saying that "a 20 30 45 1 0 0,0" is ambiguous, hence
> invalid and the parser can skip it. (degenerate line segments are not
> ambiguous)
> This would vote in favor of floating point comparison, but I think in
> the interest of (human) predictability, the equals-check should be made
> are_near. Do you agree?
Yes, otherwise small rounding errors would cause large visual
differences.
Tav
|
|
From: Johan E. <jbc...@sw...> - 2014-08-05 19:29:38
|
On 5-8-2014 21:15, Tavmjong Bah wrote:
> On Tue, 2014-08-05 at 20:46 +0200, Johan Engelen wrote:
>> Hi all,
>> Liam just committed a bug fix to Inkscape trunk, regarding our SVG
>> parser.
>>
>> SVG spec says:
>> "If the endpoints (x1, y1) and (x2, y2) are identical, then this is
>> equivalent to omitting the elliptical arc segment entirely." [1]
>>
>> Liam changed the parser so that it will simply drop such segments:
>>
>> void _arcTo(double rx, double ry, double angle,
>> bool large_arc, bool sweep, Point p)
>> {
>> + if (_current == p) { // sic, probably should be
>> are_near(_current, p)
>>
>> + return;
>> + }
>> _quad_tangent = _cubic_tangent = _current = p;
>> _sink.arcTo(rx, ry, angle, large_arc, sweep, p);
>> }
>
>> I am not sure about this change. We are not dropping any degenerate
>> bezier segments in our parser.
> I think this is not the same as a degenerate bezier. This describes an
> ellipse with given major and minor axis but there is no way to figure
> out where along the ellipse one should start drawing. The following path
> consists of four very different (almost complete) ellipses where the
> final points are just a little bit different from the starting points:
>
> <path d="m 50,50
> a 20 30 45 1 0 1,1
> 20 30 45 1 0 -1,-1
> 20 30 45 1 0 -1,1
> 20 30 45 1 0 1,-1"
> style="fill:none;stroke:black"/>
Ok, I see you're saying that "a 20 30 45 1 0 0,0" is ambiguous, hence
invalid and the parser can skip it. (degenerate line segments are not
ambiguous)
This would vote in favor of floating point comparison, but I think in
the interest of (human) predictability, the equals-check should be made
are_near. Do you agree?
regards,
Johan
|
1 message has been excluded from this view by a project administrator.
