From: Rick <graham.rick@gmail.com>

Date: Sat, 14 Nov 2009 00:33:12 -0500

Message-ID: <18569e000911132133t60152ea8o16674be8e7913d4f@mail.gmail.com>

To: www-svg <www-svg@w3.org>

Date: Sat, 14 Nov 2009 00:33:12 -0500

Message-ID: <18569e000911132133t60152ea8o16674be8e7913d4f@mail.gmail.com>

To: www-svg <www-svg@w3.org>

Boris The scenario you describe below is useful for finite integer math, in rendering engines for example, where you are dealing with pixel sets. In floating point Cartesian math, they all all intersect. Euclid said so. ---------- Forwarded message ---------- From: Boris Zbarsky <bzbarsky@mit.edu> Date: Fri, Nov 13, 2009 at 11:26 AM Subject: Re: Again with the getIntersectionList() To: Doug Schepers <schepers@w3.org> Cc: www-svg <www-svg@w3.org>, Jeff Schiller <codedread@gmail.com> On 11/13/09 3:49 AM, Doug Schepers wrote: > > A) SVGRect1 {x:20, y:20, width:0, height:0} > getIntersectionList( SVGRect1 ); > > This is essentially a point that will return everything that intersects > that point, regardless of document order I would have actually expected this to return nothing, since all intersections are empty (zero area)... If that's not what's intended, the spec needs to be _very_ clear on this, and then all sorts of interesting issues are raised. For example, does a rectangle with x=0,y=0,width=5,height=5 intersect a rectangle with x=5,y=5,width=5,height=5? I posit the intuitive answer that most people would want is "no". How is this different from the case above? For what it's worth, in Gecko rectangles in the css renderer are effectively considered closed on top and left and open on bottom and right; so a rectangle with x=0,y=0,width=5,height=5 is described by the inequalities: 0 <= x < 5, 0 <= y < 5. Hence the two rectangles I describe above do not in fact intersect, and any rectangle with width=0 or height=0 is the empty set. I'm not sure what Gecko's svg implementation does in this regard, though I suspect it's similar. -Boris -- Cheers! RickReceived on Saturday, 14 November 2009 05:33:45 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 22:54:24 UTC
*