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