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 halflines 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/viewportdependant 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 contextdependant 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, email: batikusersunsubscribe@xmlgraphics.apache.org
For additional commands, email: batikusershelp@xmlgraphics.apache.org
