You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Pierrick Brihaye <pi...@free.fr> on 2005/04/02 09:38:03 UTC
Parsing out of a document scope
Hi,
Given the following Java string :
String mypath = "<path d='M 100 100 L 300 100 L 200 300 z'/>";
What would be the shortest and most elegant way to have an
org.apache.batik.dom.svg.SVGOMPathElement instance where I could take
benefit from, say, getTotalLength() ?
Of course, any other shape may also be concerned.
Cheers,
p.b.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Thomas DeWeese <Th...@Kodak.com>.
Pierrick Brihaye wrote:
> Sorry, didn't have time to compute the line attributes. All that I can
> say is that line should have a length of 200 units :-)
>
> This should however draw (if embedded in a higher level document) a
> segment wich is a tangent to the initial path at an offset of 43%.
Well very little of the example has much to do with the SVG
DOM. You could definitely use parts of Batik to make the work
simpler.
>> 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.
>
> What if a black suface is rendered in the same pixel as a white one ? Do
> we have a sequential treatment where the last erases the previous ones
> or do we get what should IMHO the right thing, i.e. a gray suface ?
The mapping to pixels happens during the rendering step not before.
So during rendering they will be mapped to partially transparent pixels
so you will get gray. Up until then they are held in a local coordinate
system with floating point precision.
> Exactly. That's why I could even ignore rendering concerns with concrete
> coordinates.
SVG/Batik does not use "concrete coordinates" meaning pixels until
you render until then they are held as floats in an arbitrary
user defined coordinate system.
> This would be useful, but this is definitely not what I'm looking for. I
> may cope with a division by an N factor immediately followed by a
> multiplication by the same factor.
Well with SVG/Batik this sort of thing usually shows up in the
affine transforms of the parent elements which are all cascaded
together before rendering occurs.
> I thought I would have been given a password to the secret W3C lists :-)
> More seriously, what are the plans regarding the future of SVG ?
Read up on www-svg mailing lists you can find the link from the
page I gave.
>> 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.
>
> They provide additional shapes but standard SVG shapes are sufficient to
> me. What I just need are... methods :-)
Yes, but they provide elements for the DOM which is where you would
provide methods.
>> 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 think so. So, back to my initial quesiotn : does anybody have a code
> snippet that would show me the shortest path between a parser and a Java
> 2D Shape ?
The major classes are AWTPathProducer and PathParser.
Take a look at SVGPathElementBridge.buildShape for an example.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Pierrick Brihaye <pi...@free.fr>.
Hi,
Thomas DeWeese a écrit :
Let's begin by the end and drop the hinting/filtering considerationsfor now.
> 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.
Given the following XML :
<path d="M250 150 L150 350 L350 350 Z" />
I would like to write an XSLT like this :
<xsl:template name="drawTangent">
<xsl:param name="path">
<xsl:param name="at">O%</xsl:param >
<xsl:param name="SegmentLength">200</xsl:variable>
<xsl:variable name="XPointAt"
select="svg:MySVGDOM.GetXAtPoint($path,$at)"/>
<xsl:variable name="YPointAt"
select="svg:MySVGDOM.GetYAtPoint($path,$at)"/>
<xsl:variable name="SlopeAt"
select="svg:MySVGDOM.GetSlopeAtPoint($path,$at)"/>
<xsl:value-of
select="svg:MySVGDOM.MakeLineCenteredAt($XPointAt,$YPointAt,$SegmentLength,
$SlopeAt)"/>
</xsl:template>
<xsl:template match="/path">
<xsl:copy-of select=".">
<xsl:call-template name="drawTangent">
<xsl:with-param name="path" select="."/>
<xsl:with-param name="at">43%</xsl:with-param>
</xsl:call-template>
</xsl:template>
This transformation will give the following XML :
<path d="M250 150 L150 350 L350 350 Z" />
<line x1="aaa" x2="bbb" y1="ccc" y2="ddd"/>
Sorry, didn't have time to compute the line attributes. All that I can
say is that line should have a length of 200 units :-)
This should however draw (if embedded in a higher level document) a
segment wich is a tangent to the initial path at an offset of 43%.
> 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.
What if a black suface is rendered in the same pixel as a white one ? Do
we have a sequential treatment where the last erases the previous ones
or do we get what should IMHO the right thing, i.e. a gray suface ?
> 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.
Exactly. That's why I could even ignore rendering concerns with concrete
coordinates.
> 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.
This would be useful, but this is definitely not what I'm looking for. I
may cope with a division by an N factor immediately followed by a
multiplication by the same factor.
>> 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.
Sure, but we may also sacrify time for "beautiful" rendering.
>> 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.
I'm afraid it's more complicated than this because the curves may
(slightly) change when they are hinted ; I mean, not all of the control
points are transformed in the same way. Better a "m" with 3 stems than a
missing central stem (see a very quick intro at :
http://pfaedit.sourceforge.net/overview.html#Hints)
> While a more sophisticated
> system might be nice you need to balance the need to render everything
> a 20-30fps. ;)
Font rendering engines are much faster than this :-)
> 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).
Yeah ! Please keep us informed.
>>> 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/
I thought I would have been given a password to the secret W3C lists :-)
More seriously, what are the plans regarding the future of SVG ?
>> 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.
They provide additional shapes but standard SVG shapes are sufficient to
me. What I just need are... methods :-)
>> 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.
Any other advice on this ?
>> 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.
You've got it :-) Call this "parametric coordinates system" if you prefer.
> 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 think so. So, back to my initial quesiotn : does anybody have a code
snippet that would show me the shortest path between a parser and a Java
2D Shape ?
Of course, I welcome any other advice about this discussion.
Cheers,
p.b.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Thomas DeWeese <Th...@Kodak.com>.
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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Pierrick Brihaye <pi...@free.fr>.
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
Re: Parsing out of a document scope
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Pierrick,
Pierrick Brihaye wrote:
> Thomas DeWeese a écrit :
>> For the case of a shape you could bypass the whole DOM thing and just
>> parse the path data with o.a.b.parser.PathParser with AWTPathProducer
>> to turn it into a Java2D Shape. Then use
>> o.a.b.ext.awt.geom.PathLength to get the sort of information
>> that you are interested in.
>
> 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.
>> 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%"'?
> Well... let me give some more explanations.
>
> 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. But
as you note below you wouldn't really be using the SVG DOM for this.
> I'm beginning to wonder if the SVG object model is strong enough to
> achieve such "basic" operations because it looks like there is a
> dyssymetry between the API : no GetTotalLength for an ellipse, a circle,
> a rectangle... no GetArea, GetCentroid...
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). 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.
> 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. 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.
> 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.
> 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'.
> 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).
Now in SVG an element only ever lives in one of these coordinate
systems so it has methods like getScreenCTM that allow you to
map it to the screen coordinate system. But an SVGPoint which
has no DOM representation can be transformed by an SVG Matrix.
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.
> I must admit that my considerations are far enough from the everyday use
> of SVG but I'd really like to draw the figures of
This is my biggest concern you seem to really be interested in a
geometry engine that might eventually generate some SVG but I'm not
really sure that you really want to work with SVG as your primary
representation. From a code perspective there the potential to
share code like the code I referenced for PathLength etc.
> http://mathworld.wolfram.com/CircleTangentLine.html with just a few
> lines of XSLT.
>
> Does all this make sense ? I think that we have a good discussion matter
> here, haven't we ?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Pierrick Brihaye <pi...@free.fr>.
Hi,
Thomas DeWeese a écrit :
>> What would be the shortest and most elegant way to have an
>> org.apache.batik.dom.svg.SVGOMPathElement instance where I could take
>> benefit from, say, getTotalLength() ?
>
> The easiest thing to do would be to wrap it with a 'dummy' svg
> element so you can can parse it as a regular document.
What I want to avoid...
> For the case of a shape you could bypass the whole DOM thing and just
> parse the path data with o.a.b.parser.PathParser with AWTPathProducer
> to turn it into a Java2D Shape. Then use
> o.a.b.ext.awt.geom.PathLength to get the sort of information
> that you are interested in.
What I absolutely want to avoid. Aren't those computations pure
mathematics ? What if I don't have a working graphical toolkit ?
> 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.
Well... let me give some more explanations.
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.
I'm beginning to wonder if the SVG object model is strong enough to
achieve such "basic" operations because it looks like there is a
dyssymetry between the API : no GetTotalLength for an ellipse, a circle,
a rectangle... no GetArea, GetCentroid...
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 ?
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...
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.
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.
I must admit that my considerations are far enough from the everyday use
of SVG but I'd really like to draw the figures of
http://mathworld.wolfram.com/CircleTangentLine.html with just a few
lines of XSLT.
Does all this make sense ? I think that we have a good discussion matter
here, haven't we ?
Cheers,
p.b.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Parsing out of a document scope
Posted by Thomas DeWeese <Th...@Kodak.com>.
hi Pierrick,
Pierrick Brihaye wrote:
> Given the following Java string :
>
> String mypath = "<path d='M 100 100 L 300 100 L 200 300 z'/>";
>
> What would be the shortest and most elegant way to have an
> org.apache.batik.dom.svg.SVGOMPathElement instance where I could take
> benefit from, say, getTotalLength() ?
The easiest thing to do would be to wrap it with a 'dummy' svg
element so you can can parse it as a regular document. This would
be fairly efficient if you could 'gang' several such elements together.
For the case of a shape you could bypass the whole DOM thing and just
parse the path data with o.a.b.parser.PathParser with AWTPathProducer
to turn it into a Java2D Shape. Then use
o.a.b.ext.awt.geom.PathLength to get the sort of information
that you are interested in.
> Of course, any other shape may also be concerned.
Some shapes can't be parsed outside of the scope of an
SVG element because they can use relative units (percentages).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org