>>>>> "sh" == shawn hwang <[EMAIL PROTECTED]> writes:
sh> Now the question is, will the "feature" described in the link
sh> above be turned into a user-configurable property with the final
sh> release of batik 1.5? Anyone care to take a stab at this
sh> question? Thanks!
As you quoted below I've already stated an intent to make this
more easily user-configurable. Also as I pointed out and as has been
demonstraighted it already is configurable by subclassing (which in an
OO language is a reasonble solution).
The only reason easier configurability hasn't gone into CVS is (I
don't consider it critical as there is a decent work-around) and I've
been mulling over the various options:
1) Make it a get/set feature
2) Make it a boolean paramter to one or more of the
consturctors
3) Make a 'size setter' interface.
Obviously 1&2 can be used togeather. I'v also been considering
what the default behaviour should be.
sh> -----Original Message----- From: [EMAIL PROTECTED]
sh> [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 7:02
sh> PM To: [EMAIL PROTECTED] Subject: RE: JSVGCanvas.setURI()
sh> vs. JSVGCanvas.setSVGDocument()?
sh> Hi Vincent, While you are looking, I think I have identified
sh> another problem with setSVGDocument() and one without it. First
sh> when I test my application with 1.5b5 I got a problem where the
sh> browser window would get bigger everytime I loaded a new document.
sh> Now with setSVGDocument() removed this does not happen.
sh> Second with setSVGDocument() remove scripts don't work properly.
sh> A code snippet is below
sh> Element svgDocRoot = mainSvgDoc.getDocumentElement(); Element
sh> anotherRoot = anotherSVGDoc.getDocumentElement(); AbstractNode
sh> abstractNode = null; int ctr = 0; for( Node
sh> n=anotherRoot.getFirstChild(); n!=null; n = n.getNextSibling){ if(
sh> n.getNodeType() == 1 ){ abstractNode =
sh> (AbstractNode)svgDoc.importNode((AbstractNode)n, true);
sh> abstractNode.setOwnerDocument(svgDoc); Element e =
sh> (Element)abstractNode; svgDocRoot.appendChild(e); } }
sh> All our other documents essentially consist of <svg> <script> ....
sh> </script> <g> .... </g> </svg>
sh> So the above code should place both the <script> node and the <g>
sh> node into the main dom tree. However without setSVGDocument() the
sh> functions in the <script> section cannot be found by calls withing
sh> the <g> section.
sh> I suspect the functions of the script node are not being
sh> registered in the "mainSvgDoc" when the node is transfered. The
sh> above behaviour is both in b5 & b4.
sh> Gavin Walker CSIRO, Canberra Australia
sh> ---------------------------------------------------------------------
sh> To unsubscribe, e-mail: [EMAIL PROTECTED] For
sh> additional commands, e-mail: [EMAIL PROTECTED]
sh> ---------------------------------------------------------------------
sh> To unsubscribe, e-mail: [EMAIL PROTECTED] For
sh> additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
