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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
