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 Jim Ley <ji...@jibbering.com> on 2003/01/27 16:19:41 UTC
foafnaut in Batik
Hi,
I've recently been working on an svg application - foafnaut -
http://foafnaut.org/ (based on work by Dean Jackson, and with considerable
help from Liz Turner) It's a complicated SVG application, relying on a lot
of javascript, whilst I've managed to get it not to error, and be basically
usable in Batik 1.5b4, there are a number of things I am not able to do,
most are not using core SVG or ECMAScript, but are using Adobe extensions,
or similar, and I was wondering if the elements I was using are likely to be
supported in 1.5 release, of it there's a likely alternative strategy
The things I need are:
Access to the query string client-side, done in ASV via the getSrc() method.
Whilst for the online version I could use serverside scripting to
duplicate it into the client, my aim is to have a clientside version as the
data being loaded from the server makes the user experience generally
unacceptable.
Addition of javascript properties to SVG objects.
Normally in javascript, you can add properties/methods dynamically to
objects with
foo.bar="jim" and this includes Document Objects in all other
implementations I know of, so I can go:
cEl=document.createElement('circle')
cEl.chicken="jim"
and attach the chicken property to my cElement, this is very useful, for
simple objects I could use DOM methods and set an attribute or child,
however for javascript objects I'd need to serialise the object, which is
hardly desirable, any chance of coming into line with other implementations
(I realise this probably isn't simple unfortunately, however making it not a
java error, but a script error that could be try/catch'd away would help.)
Lastly my problem is the with zoom and pan, I want to have certain elements
immune to zooming and panning (despite not liking it, the application is not
considered to be acceptable, alternative HTML views of the data are
available for that), which means that I need to access the current scale and
zoom of the elements - this may be simply my syntax at fault here.
Another things I've noticed but not diagnosed as being an error, is that
parseXML never works in the context of a document other than the svg
document.
Cheers,
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "JL" == Jim Ley <ji...@jibbering.com> writes:
JL> "Thomas E Deweese" <th...@kodak.com>
>> "Jim" == Jim Ley <ji...@jibbering.com> writes:
>>> The things I need are:
>>
>>> Access to the query string client-side, done in ASV via the
>>> getSrc() method.
>> On what? this might be easy to fix...
JL> window.getSrc() it returns the current url.
Ahh, in SVG the SVGDocument object has a URL property which should
return the source URL. I would suggest using this rather than the
relatively undefined methods on the 'Window' object.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Jim Ley <ji...@jibbering.com>.
"Thomas E Deweese" <th...@kodak.com>
>"Jim" == Jim Ley <ji...@jibbering.com> writes:
>>The things I need are:
>
>>Access to the query string client-side, done in ASV via the
>>getSrc() method.
>
> On what? this might be easy to fix...
window.getSrc() it returns the current url.
> Hmm... We more or less just use the Rhino engine which proxies
>the Java DOM objects in ECMAScript. Unless this is some sort of
>configuration option for Rhino I doubt we can help you here.
>
> Sounds generally useful, any idea if this is part of ECMAScript
>or just a common extension?
It's part of the spec for ECMAScript objects, DOM objects aren't necessarily
the same though. I believe IceStorm which also uses Rhino allows it, so it
may be a simple configuration option for Rhino, it's not simple I agree if
not.
>>Another things I've noticed but not diagnosed as being an error,
>>is that parseXML never works in the context of a document other
>>than the svg document.
>
> This is fixed at least in CVS.
That's good, looking forward to the next beta (release?)
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Jim Ley <ji...@jibbering.com>.
"Thierry Kormann" <tk...@ilog.fr>
> > http://lxr.mozilla.org/mozilla/source/js/rhino/examples/Foo.java
> >
> > it suggests you get the javascript behaviour for free, if you extend
> > ScriptableObject, see the foo.a in line 64 - that's what I'm attempting
to
> > do.
>
> You are right. None of our native objects can be extended with properties
or
> methods. Though it might be easy to make our DOM extensible, this feature
> forces our DOM implementation to depend on Rhino classes (basically our
> implementation of dom::Node should extend ScriptableObject rather than
> java.lang.Object).
Could you not expose the DOM to Rhino via another class which extends
ScriptableObject, and has your java objects as as default properties?
> I think we have to think more about it and I suggest you add a RFE in
> bugzilla.
Will do.
Cheers,
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: foafnaut in Batik
Posted by Thierry Kormann <tk...@ilog.fr>.
> http://lxr.mozilla.org/mozilla/source/js/rhino/examples/Foo.java
>
> it suggests you get the javascript behaviour for free, if you extend
> ScriptableObject, see the foo.a in line 64 - that's what I'm attempting to
> do.
You are right. None of our native objects can be extended with properties or
methods. Though it might be easy to make our DOM extensible, this feature
forces our DOM implementation to depend on Rhino classes (basically our
implementation of dom::Node should extend ScriptableObject rather than
java.lang.Object).
I think we have to think more about it and I suggest you add a RFE in
bugzilla.
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Jim Ley <ji...@jibbering.com>.
"Thomas E Deweese" <th...@kodak.com>
> Hmm... We more or less just use the Rhino engine which proxies
> the Java DOM objects in ECMAScript. Unless this is some sort of
> configuration option for Rhino I doubt we can help you here.
In
http://lxr.mozilla.org/mozilla/source/js/rhino/examples/Foo.java
it suggests you get the javascript behaviour for free, if you extend
ScriptableObject, see the foo.a in line 64 - that's what I'm attempting to
do.
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: foafnaut in Batik
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "Jim" == Jim Ley <ji...@jibbering.com> writes:
Jim> I've recently been working on an svg application - foafnaut -
Jim> http://foafnaut.org/ (based on work by Dean Jackson, and with
Jim> considerable help from Liz Turner)
Cool!
Jim> It's a complicated SVG application, relying on a lot of
Jim> javascript, whilst I've managed to get it not to error, and be
Jim> basically usable in Batik 1.5b4, there are a number of things I
Jim> am not able to do, most are not using core SVG or ECMAScript, but
Jim> are using Adobe extensions, or similar, and I was wondering if
Jim> the elements I was using are likely to be supported in 1.5
Jim> release, of it there's a likely alternative strategy
Jim> The things I need are:
Jim> Access to the query string client-side, done in ASV via the
Jim> getSrc() method.
On what? this might be easy to fix...
Jim> Whilst for the online version I could use serverside scripting to
Jim> duplicate it into the client, my aim is to have a clientside
Jim> version as the data being loaded from the server makes the user
Jim> experience generally unacceptable.
---
Jim> Addition of javascript properties to SVG objects. Normally in
Jim> javascript, you can add properties/methods dynamically to objects
Jim> with foo.bar="jim" and this includes Document Objects in all
Jim> other implementations I know of, so I can go:
Jim> cEl=document.createElement('circle')
Jim> cEl.chicken="jim"
Hmm... We more or less just use the Rhino engine which proxies
the Java DOM objects in ECMAScript. Unless this is some sort of
configuration option for Rhino I doubt we can help you here.
Jim> and attach the chicken property to my cElement, this is very
Jim> useful, for simple objects I could use DOM methods and set an
Jim> attribute or child, however for javascript objects I'd need to
Jim> serialise the object, which is hardly desirable, any chance of
Jim> coming into line with other implementations (I realise this
Jim> probably isn't simple unfortunately, however making it not a java
Jim> error, but a script error that could be try/catch'd away would
Jim> help.)
Sounds generally useful, any idea if this is part of ECMAScript
or just a common extension?
Jim> Lastly my problem is the with zoom and pan, I want to have
Jim> certain elements immune to zooming and panning (despite not
Jim> liking it, the application is not considered to be acceptable,
Jim> alternative HTML views of the data are available for that), which
Jim> means that I need to access the current scale and zoom of the
Jim> elements - this may be simply my syntax at fault here.
Nope, this has not been implemented... It should be :) I don't
even think it's incredibly hard but I don't know enough about the
script binding to fix it.
Jim> Another things I've noticed but not diagnosed as being an error,
Jim> is that parseXML never works in the context of a document other
Jim> than the svg document.
This is fixed at least in CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
showing dynamic documents ?
Posted by Kurt Dequick <ku...@tiscalinet.be>.
hello,
I'm new to this list (and also new to Java and SVG :-)
I'm using XSLT to create SVG. If I write the output to a file, I'm able
to show the resulting SVG on screen.
[with svgCanvas.loadSVGDocument(svgFile.toURL().toString());]
But without an intermediate file I'm not able to show the SVG.
I found this code below doing a search on the internet, but although
it doesn't fail, it also doesn't show the SVG drawing...
DOMImplementation impl =
SVGDOMImplementation.getDOMImplementation();
String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI;
SVGOMDocument outDoc =
(SVGOMDocument)impl.createDocument(svgNS, "svg", null);
trans.transform
(xmlSource,
new
javax.xml.transform.dom.DOMResult(outDoc.getDocumentElement(
)));
svgCanvas.setSVGDocument(outDoc);
what am I doing wrong ?
bye,
Kurt
--
http://www27.brinkster.com/kurtsmaze
I'll never forget the afternoon I read Professor [Thomas
Henry] Huxley's essay on 'The Gaderene Swine'.
(Robert A Heinlein , from "To Sail Beyond the Sunset" , page 25)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Vincent Hardy <vi...@sun.com>.
Just to confirm: SVGScroll and SVGZoom are not implemented.
Vincent.
Jim Ley wrote:
>>Jim Ley wrote:
>>
>>>Lastly my problem is the with zoom and pan, I want to have certain
>>
> elements
>
>>>immune to zooming and panning (despite not liking it, the application is
>>
> not
>
>>>considered to be acceptable,
>>
>
> I meant to write _accessible_ not acceptable...
>
>
>>>alternative HTML views of the data are
>>>available for that), which means that I need to access the current scale
>>
> and
>
>>>zoom of the elements - this may be simply my syntax at fault here.
>>
>>I don't know for the other ones, but if you rely on SVGScroll and SVGZoom
>>events to do that one, it looks unfortunately like they are not
>
> implemented
>
>>yet, see the following RFE:
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10447
>
>
> Yep, but it seems that:
>
> var trans=gdocDE.currentTranslate;
> var scale=gdocDE.currentScale;
>
> doesn't work when called at all, both result in an error.
> (gdocDE is the documentElement )
>
> Jim.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Jim Ley <ji...@jibbering.com>.
> Jim Ley wrote:
> > Lastly my problem is the with zoom and pan, I want to have certain
elements
> > immune to zooming and panning (despite not liking it, the application is
not
> > considered to be acceptable,
I meant to write _accessible_ not acceptable...
> > alternative HTML views of the data are
> > available for that), which means that I need to access the current scale
and
> > zoom of the elements - this may be simply my syntax at fault here.
>
> I don't know for the other ones, but if you rely on SVGScroll and SVGZoom
> events to do that one, it looks unfortunately like they are not
implemented
> yet, see the following RFE:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10447
Yep, but it seems that:
var trans=gdocDE.currentTranslate;
var scale=gdocDE.currentScale;
doesn't work when called at all, both result in an error.
(gdocDE is the documentElement )
Jim.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: foafnaut in Batik
Posted by Christophe Jolif <cj...@ilog.fr>.
Jim,
Jim Ley wrote:
> Lastly my problem is the with zoom and pan, I want to have certain elements
> immune to zooming and panning (despite not liking it, the application is not
> considered to be acceptable, alternative HTML views of the data are
> available for that), which means that I need to access the current scale and
> zoom of the elements - this may be simply my syntax at fault here.
I don't know for the other ones, but if you rely on SVGScroll and SVGZoom
events to do that one, it looks unfortunately like they are not implemented
yet, see the following RFE:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10447
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org