Hi Thomas,
First, thanks for your quick answer and your attention.
Thomas DeWeese a �crit :
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.
You're right. After a glance at GNU Classpath implementation, it looks like the computations are done by the JVM. I hope it is the same for every JVM.
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%"'?
When I say "I don't care", I mean... at the beginning, not at the end. That's why I was talking about inversion of control.
I fully understand that an efficient rendering engine would like to have concrete coordinates as soon as possible but I fear about approximation drawbacks when large user coordinates spaces are drawn within just a few pixels. Were my math teachers wrong when they were saying "resolve only when all you calculations are done" ?
Say I have a very precise SVG drawing of a fly with all its eyes facets. I would definitely like to ignore these very little shapes when they are rendered within a 100 x 100 pixels matrix ; I mean that everything wich is less than 1% of the final dimension should be "filtered" (the filtering strategy is another yet interesting matter).
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.
For sure. My question is rather about Batik's interest for such methods.
Imagine for example a rasterizer that would try to render nicely some SVG fonts. It would obviously require font hinting.
Say I could define some "anchors" points in the glyphes (the point at 43% of a path, 20em units above the top of a circle, the intersection of a tangent to a path and the geometric extension of the Nth segment of a polyline, whatever).
I could then move these "control" points relatively to each other in order to have the best possible rendering.
Well... I know, there's nothing about such mechanisms in the SVG specs :-(
> But
as you note below you wouldn't really be using the SVG DOM for this.
I wish I could use an "extended" one :-)
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).
Would Batik be interested ? How to mutualize the efforts ?
> 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.
Sure, it was a bad example but it doesn't prevent to have API to access the properties of every kind of shape. See above : I could put an "anchor" on this ellipse and then go along it (modulus 100%).
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.
Good news ! Do you have a pointer ?
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.
I fully agree on these design principles and not only because *you* are the project's leader :-) So... how to start ?
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.
Would Batik be interested ? How to implement this ? 2 points (cartesian) ? A point and an angle (polar) ? A "slope" ? All of these ?
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'.
Of course. My problem is that I would like to make this system concrete as late as possible and - why not - ignore the (concrete) "bottom of the stack" if I don't need it.
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).
That's very clear... and problematic in regard of the above arguments.
But an SVGPoint which has no DOM representation can be transformed by an SVG Matrix.
It's becoming interesting :-) But this SVGPoint is in absolute (resolved) coordinates, isn't it ?
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.
Of course ! Affine transforms are exactly what I need since the matrix products are less prone to approximation errors. What I've called a "context stack" would definitely look like a stack of affine transforms.
This is my biggest concern you seem to really be interested in a geometry engine that might eventually generate some SVG
Rather than this, I want to make some computations :
1) from an SVG (or SVG-like, i.e. out of a document scope) syntax
2) that will finally generate SVG documents (with their own concrete user space ;-)
You may see my wish as a hopefully convenient way to put some "hooks" (filtering, hinting...) in the processing of an SVG tree that would lead in a better optimized rendering.
Cheers,
p.b.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
