xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Parsing out of a document scope
Date Wed, 06 Apr 2005 01:24:35 GMT
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

>>    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

View raw message