Re: Intersection Points

Hey, Antoine-

<backPedal mode='embarrased'>
No, of course you're right, it's apparently not in the API, it's in the
authoring tool. It was late, and I misspoke. I'm not a Flash user... I've
barely seen a Flash authoring tool and can't even recall the name of
MacroMedia's main app, so I was speaking from a position of ignorance. What
I meant to say was that finding intersection points is something that I've
seen and discussed with people who have used Flash (and other vector
graphics) tools, and is is something that content creators have come to
expect in an authoring tool; my larger point was that if it were easier for
the writers of authoring tools (like my little SVG-Whiz application) to
provide these features, it would be easier for authors to create contenet,
and would help increase the adoption of SVG. </backPedal>

That being said, I stand by my assertion that something like this has broad
applications and should not be too onerous to implement in a viewer. SVG+JS
authoring tools are such a niche that I wouldn't even consider them as a use
case, but the use cases I did mention are substantial targets of SVG
adoption.

I also think it would add semantic value to the already semantically-rich
SVG, aiding accessibity by addressing how screen readers might interpret the
relations between elements (barely touching, connected on the top or the
side, etc.) in a more robust way than is available now with only BBox and
the current intersection/enclosure methods. (Think of the children!;) A
combination of this and Cameron's constraints would yeild a fantastically
rich semantic addition in describing relationships.

If this is non-trivial, as many smart people seem to suggest, I can see that
it should probably be put off until the next Spec. I was predicating my
request on a (mis)conception of the mechanisms behind vector effects; I
thought that it would merely be exposing in an API something that goes on
behind the scenes with VectorEffects. If this isn't the case, then I stand
corrected.

Nonetheless, I ask that this be seriously considered for inclusion into SVG.
As Kevin said, his code is not ready for prime time, and if he can't do it
well in JS, I doubt anyone could; I think this should be moved into the
viewer. If you need more use cases or specing out implications and
implementation details, let me know.

Regards-
-Doug

Antoine Quint wrote:
|
| Hey Doug,
|
| On 15 mars 04, at 08:23, Doug Schepers wrote:
|
| > I feel strongly that having some degree of this functionality is
| > better than
| > having none at all, and I think that this is something that would be
| > easy to
| > do in a simple form. These are things that Flash has in its toolkit,
| > and I'd
| > like to see them in SVG.
|
| What do you mean by "Flash has it in its toolkit"? Do you mean it's
| part of the ActionScript API [0]? If so, I couldn't find the method for
| it. Are you sure it's in there, or rather on a commercial component or
| in the authoring tool itself.
|
| The fact that Kevin has done it with reasonably good performance
| pre-SVG 1.2 makes me think that there's no true urge for having this in
| SVG 1.2.
|
| Antoine
|
| [0]
| http://www.macromedia.com/support/flash/action_scripts/
| actionscript_dictionary/
| -- 
| Antoine Quint <aq@fuchsia-design.com>
| W3C SVG Working Group Invited Expert
| SVG Consulting, Teaching and Outsourcing
|

Received on Monday, 15 March 2004 13:53:14 UTC