You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Danny Ayers <da...@virgilio.it> on 2001/11/02 19:44:49 UTC
getting/setting transforms
Hi,
The app that I'm working on needs me to be able to change the values in a
transform,
i.e. in
<g transform="translate(200, 200)">
stuff
</g>
change the x & y values.
I'm not certain if I was reading the Javadoc correctly, but it looked like I
should have been able to use getTransformToElement(SVGElement element) in
SVGLocatable. However, when I tried this I got the (not entirely helpful!)
exception below. I'm currently hacking a utility to allow me to do what I
want by pulling out the transform attribute as a whole string and messing
with it, but I have a feeling that this kind of operation must have been
covered elsewhere. Has it? Or is there a way of doing what I'm after that
I've not noticed?
java.lang.RuntimeException: !!! TODO:
SVGTransformableSupport.getTransformToElement()
at
org.apache.batik.dom.svg.SVGTransformableSupport.getTransformToElement(SVGTr
ansformableSupport.java:85)
at
org.apache.batik.dom.svg.SVGGraphicsElement.getTransformToElement(SVGGraphic
sElement.java:140)
at com.isacat.orgn.svg.SvgChart.setId(SvgChart.java:43)
at
com.isacat.orgn.base.GraphObserverImpl.setId(GraphObserverImpl.java:138)
at com.isacat.orgn.persist.XMLChart.createTitle(XMLChart.java:159)
at
com.isacat.orgn.persist.XMLChart.createGraphElement(XMLChart.java:142)
at com.isacat.orgn.persist.XMLChart.walk(XMLChart.java:99)
at com.isacat.orgn.persist.XMLChart.load(XMLChart.java:70)
at com.isacat.orgn.view.SwingView.loadGraph(SwingView.java:79)
at com.isacat.orgn.view.SwingView.<init>(SwingView.java:63)
at com.isacat.orgn.view.SwingView.main(SwingView.java:46)
Exception in thread "main"
BTW, I'm mailing this to the dev list directly as even if I've missed
something really obvious from the doc for my particular task (i.e. something
for the user's list), there still remains the question of this exception -
surely the Javadoc should reflect what the method does, rather than what it
would be nice for it to do?
Cheers,
Danny.
---
Danny Ayers
http://www.isacat.net
Alternate email (2001) :
danny666@virgilio.it
danny_ayers@yahoo.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
RE: getting/setting transforms
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "DA" == Danny Ayers <da...@virgilio.it> writes:
>> On Monday 05 November 2001 21:32, Danny Ayers wrote:
>>> >The SVG DOM is not implemented yet, which is why you are getting
>>> >the "TODO" exception.
>>>
>>> It's ok to put unimplemented features in the javadoc then? "TODO"
>>> came to me like a "road closed" sign 10 miles after
>>> turning onto the road...
>> The SVG DOM comes from the W3C and not the batik team. You could
>> not implement w3c SVG DOM API without having all the methods in our
>> implementation (even partial).
DA> I was working from "Batik API Specification" (as the Javadoc is
DA> titled) and used a method documented there, but not, as noted,
DA> implemented. It seems I misunderstood the purpose of this
DA> documentation. Is there a list anywhere of what parts of the API
DA> specified has/has not been implemented?
We have to provide all the methods in our implementation hence
they will all appear in the JavaDoc. Perhaps it would be useful to
add 'Unimplemented' to the standard W3C method description (I think it
is good to keep the W3C description of the method).
Patch anyone? :)
DA> Cheers, Danny.
DA> PS. Don't get me wrong - I think Batik is marvellous!
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
RE: getting/setting transforms
Posted by Danny Ayers <da...@virgilio.it>.
>On Monday 05 November 2001 21:32, Danny Ayers wrote:
>> >The SVG DOM is not implemented yet, which is why you are getting
>> >the "TODO" exception.
>>
>> It's ok to put unimplemented features in the javadoc then?
>> "TODO" came to me like a "road closed" sign 10 miles after
>turning onto the
>> road...
>
>The SVG DOM comes from the W3C and not the batik team. You could not
>implement w3c SVG DOM API without having all the methods in our
>implementation (even partial).
I was working from "Batik API Specification" (as the Javadoc is titled) and
used a method documented there, but not, as noted, implemented. It seems I
misunderstood the purpose of this documentation. Is there a list anywhere of
what parts of the API specified has/has not been implemented?
Cheers,
Danny.
PS. Don't get me wrong - I think Batik is marvellous!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: getting/setting transforms
Posted by Thierry Kormann <tk...@ilog.fr>.
On Monday 05 November 2001 21:32, Danny Ayers wrote:
> >The SVG DOM is not implemented yet, which is why you are getting
> >the "TODO" exception.
>
> It's ok to put unimplemented features in the javadoc then?
> "TODO" came to me like a "road closed" sign 10 miles after turning onto the
> road...
The SVG DOM comes from the W3C and not the batik team. You could not
implement w3c SVG DOM API without having all the methods in our
implementation (even partial).
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
RE: getting/setting transforms
Posted by Danny Ayers <da...@virgilio.it>.
>The SVG DOM is not implemented yet, which is why you are getting
>the "TODO" exception.
It's ok to put unimplemented features in the javadoc then?
"TODO" came to me like a "road closed" sign 10 miles after turning onto the
road...
Cheers,
Danny.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: getting/setting transforms
Posted by Vincent Hardy <vi...@sun.com>.
Danny,
The SVG DOM is not implemented yet, which is why you are getting
the "TODO" exception.
Vincent.
Danny Ayers wrote:
>
> Hi,
> The app that I'm working on needs me to be able to change the values in a
> transform,
> i.e. in
>
> <g transform="translate(200, 200)">
> stuff
> </g>
>
> change the x & y values.
>
> I'm not certain if I was reading the Javadoc correctly, but it looked like I
> should have been able to use getTransformToElement(SVGElement element) in
> SVGLocatable. However, when I tried this I got the (not entirely helpful!)
> exception below. I'm currently hacking a utility to allow me to do what I
> want by pulling out the transform attribute as a whole string and messing
> with it, but I have a feeling that this kind of operation must have been
> covered elsewhere. Has it? Or is there a way of doing what I'm after that
> I've not noticed?
>
> java.lang.RuntimeException: !!! TODO:
> SVGTransformableSupport.getTransformToElement()
> at
> org.apache.batik.dom.svg.SVGTransformableSupport.getTransformToElement(SVGTr
> ansformableSupport.java:85)
> at
> org.apache.batik.dom.svg.SVGGraphicsElement.getTransformToElement(SVGGraphic
> sElement.java:140)
> at com.isacat.orgn.svg.SvgChart.setId(SvgChart.java:43)
> at
> com.isacat.orgn.base.GraphObserverImpl.setId(GraphObserverImpl.java:138)
> at com.isacat.orgn.persist.XMLChart.createTitle(XMLChart.java:159)
> at
> com.isacat.orgn.persist.XMLChart.createGraphElement(XMLChart.java:142)
> at com.isacat.orgn.persist.XMLChart.walk(XMLChart.java:99)
> at com.isacat.orgn.persist.XMLChart.load(XMLChart.java:70)
> at com.isacat.orgn.view.SwingView.loadGraph(SwingView.java:79)
> at com.isacat.orgn.view.SwingView.<init>(SwingView.java:63)
> at com.isacat.orgn.view.SwingView.main(SwingView.java:46)
> Exception in thread "main"
>
> BTW, I'm mailing this to the dev list directly as even if I've missed
> something really obvious from the doc for my particular task (i.e. something
> for the user's list), there still remains the question of this exception -
> surely the Javadoc should reflect what the method does, rather than what it
> would be nice for it to do?
>
> Cheers,
> Danny.
>
> ---
> Danny Ayers
> http://www.isacat.net
>
> Alternate email (2001) :
> danny666@virgilio.it
> danny_ayers@yahoo.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org