Pierrick Brihaye wrote:
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.
The thing is that all these calculations are done in the local user coordinate system. So it doesn't matter that eventually they will be drawn at a few pixels.
Were my math teachers wrong when they were saying "resolve only when all you calculations are done" ?
This is a little different this would be essentially a maths system. So rather than having a float you would have a number abstraction that would 'store' a whole set of calculations that result in the final value. This allows for simplifications like (cos^2(theta)+sin^2(theta)) = 1, of course to make use of that sort of thing you need a whole algebra solving system.
I really don't think this would be appropriate for Batik.
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).
Unfortunately often calculating what is/isn't visible takes longer than rendering it.
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.
This is normally done by just tweaking the location of the ends and control points of the cubic beziers. While a more sophisticated system might be nice you need to balance the need to render everything a 20-30fps. ;)
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 :-)
The point is what you are doing so far divorced from the focus of SVG that trying to reuse SVG (with problems like percentage units) just get's in the way of what you are trying to do.
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 ?
There is a chance that they could be useful to each other. One thing that is likely to happen shortly (after this batik release) is that FOP and Batik will pull some of the low level graphics support code out into external packages. This might be a good place for your work to happen. Especially since you are targeting XSLT (which fits nicely with the concept of the 'xml-graphics' subproject).
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 ?
http://www.w3.org/Graphics/SVG/
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 ?
You can look at the sample extensions in 'o.a.batik.ext.svg'. They don't add much to the DOM but they do create subclasses that are used in the DOM. Note that they live in a separate namespace. There are also tutorials on extending Batik on the website.
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 ?
Well, you are the one who is interested, since these are outside of any spec I am aware of you can mostly do what you want. I would have to see something a bit more complete before I could see where/if Batik would be using them.
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.
You can't know if you can ignore it without evaluating it at some level...
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 ?
It always has a float/double X, and float/double Y. It doesn't have a 'Equation X' that can be evaluated to give an X. I think this is the distinction you are making.
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.
Well my suggestion would be to play with extension elements a bit and see what can be accomplished that way as I think most of what you want can be done that way. I am not particularly interested in replacing all concrete values with 'equations' at least not right now. That said I must admit I'm not sure I really understand your intent.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
