xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Parsing out of a document scope
Date Sun, 03 Apr 2005 13:57:18 GMT
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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message