xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierrick Brihaye <pierrick.brih...@free.fr>
Subject Re: Parsing out of a document scope
Date Sun, 03 Apr 2005 16:07:45 GMT
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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message