Hi Pierrick,
Pierrick Brihaye wrote:
Thomas DeWeese a �crit :
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 ?
Well, a Java2D Shape is just a container for a bunch of geometric descriptions. AFAIK it doesn't require the awt toolkit to be booted when you create one. I'm not talking about rendering the shape just creating one to hold geometry.
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.
No it wouldn't, is that 200% of width or height? and what if the use: 'width="50000" height="25%"'?
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.
You could do this on top of the API's I referenced above. But as you note below you wouldn't really be using the SVG DOM for this.
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...
Right, SVG is a graphics lang, not a geometry engine (it might require one under the covers but the details of such things can vary widely for SVG renderers). Also you have issues like where do you start for getPointAtLength for an ellipse (obviously you can make arbitrary decisions about this), but a Path has a clearly defined start point.
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 ?
Well, we are implementing a Specification we are supposed to be very close, ideally identical. If you want to implement them as extensions there isn't a problem but there needs to be a clear delineation between what is specified in SVG and what is extension. You can't just start adding methods to the SVGPathElement.
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...
Batik is fairly extensible so you may be able to create these abstractions yourself.
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.
Well all geometry in SVG and Batik is held in a local 'user coordinate system'.
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.
Well it is always defined in a user coordinate system. That user coordinate system is 'defined' by the surrounding context (the coordinate systems defined by it's parent elements).
Now in SVG an element only ever lives in one of these coordinate systems so it has methods like getScreenCTM that allow you to map it to the screen coordinate system. But an SVGPoint which has no DOM representation can be transformed by an SVG Matrix.
If you aren't up on Affine Transforms I would suggest you read up on them as they offer a nice framework for this sort of thing.
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
This is my biggest concern you seem to really be interested in a geometry engine that might eventually generate some SVG but I'm not really sure that you really want to work with SVG as your primary representation. From a code perspective there the potential to share code like the code I referenced for PathLength etc.
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 ?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
