xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierrick Brihaye <pierrick.brih...@free.fr>
Subject Re: Parsing out of a document scope
Date Sun, 03 Apr 2005 09:01:23 GMT

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, 

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 ?



To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message