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 2030fps. ;)
> 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 'xmlgraphics' 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 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 ?
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/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.
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 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 ?
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 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.
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, email: batikusersunsubscribe@xmlgraphics.apache.org
For additional commands, email: batikusershelp@xmlgraphics.apache.org
