W3C home > Mailing lists > Public > www-svg@w3.org > March 2004

Re: Intersection Points

From: Peter Sorotokin <psorotok@adobe.com>
Date: Sun, 14 Mar 2004 18:40:17 -0800
To: Doug Schepers <doug@schepers.cc>, www-svg@w3.org
Message-id: <>

At 03:19 PM 3/14/2004 -0500, Doug Schepers wrote:

>In reading the newest draft of the 1.2 Spec, I noticed that intersections
>are required in several sections, such as "10.1.2 Alpha compositing" and
>various Vector Effects, such as veJoin, veUnion, veIntersect, and veExclude.
>These look really great.
>Since the math is being done in the viewer anyway,

It is done for paths, not arbitrary element

>  I think that the results
>of this functionality should be exposed in the interface. It would be great
>to have access to the vector math functions, since it could help with some
>of the heavy-duty math that's hard to do in JavaScript, but that's probably
>a bit much to ask.
>In addition to getIntersectionList and getEnclosureList, which only return
>the intersecting elements, I would very much like to get the points of
>intersection as a list of SVGPoints. Something like:
>getIntersectionPoints(element, referenceElement)
>This method returns a dom::SVGPointList.

But intersection is a shape, not a list of points. Vector effects work with 
shapes described by contours, not contours themselves as you seem to 
propose. Try to spec out such a method fully (take into account things like 
transforms, visibility, text elements, use element, clipping, masking, 
filter effects, etc)  and you'll see that it is a fairly non-trivial thing 
to do.


>  The element parameter is of type
>SVGElement.  The referenceElement parameter is of type SVGElement.
>Use cases:
>     Math apps - this would help with many visual tutorials and similar
>math-related apps.
>     CAD - precision intersections of machinery and walls.
>     GIS - intersections of street, rivers, and other map features.
>Again, since a conformant viewer already needs to have this functionality, I
>think that there would be very little additional cost in exposing the
>results in the interface. I think that this is something that could easily
>be done in SVG1.2.
Received on Sunday, 14 March 2004 21:39:03 UTC

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