Hi,

Thomas DeWeese a �crit :

What would be the shortest and most elegant way to have an org.apache.batik.dom.svg.SVGOMPathElement instance where I could take benefit from, say, getTotalLength() ?

The easiest thing to do would be to wrap it with a 'dummy' svg element so you can can parse it as a regular document.

What I want to avoid...

   For the case of a shape you could bypass the whole DOM thing and just
parse the path data with o.a.b.parser.PathParser with AWTPathProducer
to turn it into a Java2D Shape.  Then use
o.a.b.ext.awt.geom.PathLength to get the sort of information
that you are interested in.

What I absolutely want to avoid. Aren't those computations pure mathematics ? What if I don't have a working graphical toolkit ?


  Some shapes can't be parsed outside of the scope of an
SVG element because they can use relative units (percentages).

I don't care. A totalLength of, say, "200%" would be meaningful to me.

Well... let me give some more explanations.

What I'd like to do is to write some svg extensions for an XSLT processor, get the required informations, and make some computations on my shape, say, draw a tangent at the point which is at 43% of a path.

I'm beginning to wonder if the SVG object model is strong enough to achieve such "basic" operations because it looks like there is a dyssymetry between the API : no GetTotalLength for an ellipse, a circle, a rectangle... no GetArea, GetCentroid...

First point :
In Batik, which is very close to this object model, we have the same lacunae. Would it make sense to have such "extensions" to the W3C object model ?


Second point :
I would also like to have some API to deal with lines. I mean mathematical infinite straight lines or half-lines which may eventually be oriented. We could thus calculate intersection, isParallel, closestPoint...


Third point :
This is probably the most problematic one. I wonder how Batik could manage an "inversion of control" that would defer as much as possible the device/viewport-dependant coordinates resolution.


Could SVGPoint be refactored in order to cope with "abstract" coordinates. Such an SVGPoint, associated with a "context stack" would then be able to return context-dependant concrete coordinates.

I must admit that my considerations are far enough from the everyday use of SVG but I'd really like to draw the figures of http://mathworld.wolfram.com/CircleTangentLine.html with just a few lines of XSLT.

Does all this make sense ? I think that we have a good discussion matter here, haven't we ?

Cheers,

p.b.










--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to