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 Jorg Heymans <jh...@domek.be> on 2005/03/16 11:50:42 UTC
namespace woes
Hi,
I am having a problem getting my canvas updates to appear. I know the
common pitfalls and i think i avoided them, hence my post.
Here is what i am doing
- a servlet creates a stream of xml data, parts of this xml data is used
to build the SVG document, other parts not. I made sure that the servlet
declares the namespace prefixes at the begining of the doc, and that all
elements (not the attributes) used for the SVG doc have the svg
namespace prefix.
- a client canvas retrieves this stream and does the following
1)create a reader using crimson's o.a.crimson.parser.XMLReaderImpl,
making sure it has namespace and namespaceprefix support
2)setup a content handler that uses a SAX to DOM transformer
3)parse the stream using the content handler, resulting in a DOM tree
of the SAX stream.
The content handler appends the parsed nodes to an element that is
created from the current active SVGDocument (thus avoiding having to
import and clone them afterwards).
I then move the newly created elements from this element to the relevant
nodes in the SVGDocument (in the canvasmgr update thread). The updates
aren't showing for some reason. But if i dump the updated svg doc to a
file and load it into squiggle it shows up fine :(
I believe there are namespace issues involved here, either i don't set
it correctly or batik does not see it. What can i do to debug this?
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes - simplification
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
> Say i create an element "A" using getSVGDocument.createElementNS() and
> then append a bunch of other nodes "B" (from a different document) to
> this element.
You shouldn't be allowed to do this. If "A" and "B" have
different ownerDocuments then an exception should be raised
when you append nodes from "B". I don't think this is the
real issue in your other post as I suspect that when you
give the element from "A" to the DOMResult it uses the
ownerDocument of A as a factor to create the new nodes.
> Now i want to append some parts of "B" to the main
> document, is it necessary to import the parts into the main document
> first or are they considered imported already because they hang off an
> element that was created from the main document.
Any time nodes move from one document to another (in DOM 2)
they must be imported and cloned.
> I am trying to avoid having to import (and thus clone) the nodes for
> performance reasons, hence this setup.
I suspect that you are going through a lot of work for nothing.
In my experience the clone time is a very small % of the total time
so eliminating it saves you almost nothing.
> sorry for continuously replying to my own posts, i am just trying to a
> deeper understanding of something obviously not so trivial.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes - simplification
Posted by Jorg Heymans <jh...@domek.be>.
Say i create an element "A" using getSVGDocument.createElementNS() and
then append a bunch of other nodes "B" (from a different document) to
this element. Now i want to append some parts of "B" to the main
document, is it necessary to import the parts into the main document
first or are they considered imported already because they hang off an
element that was created from the main document.
I am trying to avoid having to import (and thus clone) the nodes for
performance reasons, hence this setup.
sorry for continuously replying to my own posts, i am just trying to a
deeper understanding of something obviously not so trivial.
Any pointers?
Jorg
Jorg Heymans wrote:
> i just switched to xerces 2.6.2, it didn't help so my suspicion about
> namespaces seem to be correct.
>
> Batik is rightfully ignoring any element that is not created with the
> SVG namespace. But i do create a text document with correct prefixes
> everywhere, and i made sure the client parser sees them (debugging the
> contenthandler i can see that every startelement() has the correct URI
> with it).
>
> Could the transformerfactory maybe drop them ? I create it as following:
>
> SAXTransformerFactory factory = TransformerFactory.newInstance();
> TransformerHandler handler = factory.newTransformerHandler();
> handler.setResult(new DOMResult(parentnode)) -> parent node is the
> element i created from the SVGDoc
>
> I hope these snippets make sense.
>
> Regards
> Jorg
>
>
> Jorg Heymans wrote:
>
>> Hi,
>>
>> I am having a problem getting my canvas updates to appear. I know the
>> common pitfalls and i think i avoided them, hence my post.
>>
>> Here is what i am doing
>> - a servlet creates a stream of xml data, parts of this xml data is
>> used to build the SVG document, other parts not. I made sure that the
>> servlet declares the namespace prefixes at the begining of the doc,
>> and that all elements (not the attributes) used for the SVG doc have
>> the svg namespace prefix.
>> - a client canvas retrieves this stream and does the following
>> 1)create a reader using crimson's o.a.crimson.parser.XMLReaderImpl,
>> making sure it has namespace and namespaceprefix support
>> 2)setup a content handler that uses a SAX to DOM transformer
>> 3)parse the stream using the content handler, resulting in a DOM tree
>> of the SAX stream.
>>
>> The content handler appends the parsed nodes to an element that is
>> created from the current active SVGDocument (thus avoiding having to
>> import and clone them afterwards).
>>
>> I then move the newly created elements from this element to the
>> relevant nodes in the SVGDocument (in the canvasmgr update thread).
>> The updates aren't showing for some reason. But if i dump the updated
>> svg doc to a file and load it into squiggle it shows up fine :(
>>
>>
>> I believe there are namespace issues involved here, either i don't set
>> it correctly or batik does not see it. What can i do to debug this?
>>
>> Regards
>> Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Archie Cobbs <ar...@dellroad.org>.
Jorg Heymans wrote:
> The factory doesn't have this method. It's SAXTransformerFactory mind
> you, not a SAXParserFactory.
>
> Archie Cobbs wrote:
>> Do you need to setNamespaceAware(true) ?
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParserFactory.html#setNamespaceAware(boolean)
Oops, nevermind :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
The factory doesn't have this method. It's SAXTransformerFactory mind
you, not a SAXParserFactory.
Archie Cobbs wrote:
> Jorg Heymans wrote:
>
>> Could the transformerfactory maybe drop them ? I create it as following:
>>
>> SAXTransformerFactory factory = TransformerFactory.newInstance();
>> TransformerHandler handler = factory.newTransformerHandler();
>> handler.setResult(new DOMResult(parentnode)) -> parent node is the
>> element i created from the SVGDoc
>
>
> Do you need to setNamespaceAware(true) ?
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParserFactory.html#setNamespaceAware(boolean)
>
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Archie Cobbs <ar...@dellroad.org>.
Jorg Heymans wrote:
> Could the transformerfactory maybe drop them ? I create it as following:
>
> SAXTransformerFactory factory = TransformerFactory.newInstance();
> TransformerHandler handler = factory.newTransformerHandler();
> handler.setResult(new DOMResult(parentnode)) -> parent node is the
> element i created from the SVGDoc
Do you need to setNamespaceAware(true) ?
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParserFactory.html#setNamespaceAware(boolean)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
> Thomas DeWeese wrote:
>> The GVT tree building is done by the bridge.GVTBuilder class.
>> It's pretty simple, it basically checks if it has a bridge
>> registered for the element that was added. If so it will
>> build it's node and then check it's children, otherwise it stops.
Jorg Heymans wrote:
> ok. stepping through for a <path> element
[...]
> it seems to do this for pretty much every shape i add. Should i look for
> something more specific ?
No, this means it's building them.
> If there was a namespace problem, would it not find the registered
> bridge for this element?
Correct, the bridges are registered on Namespace and tag
name. So if it didn't know that they were SVG paths or what ever
it would not have found a bridge. You can give up the whole
namespacea are the problem thing ;)
> I can track the namespaces and prefixes down to getBridge(Element)
> in BridgeContext.
The problem is now a question of why aren't your shape nodes
being drawn, or if they are being drawn why aren't they showing
up? I generally find the best way to address this is to
add print statements to the 'paint' and 'primitivePaint'
methods on some of the key GraphicsNode subclasses,
in this case I would look at CompositeGraphicsNode and
ShapeNode. I would do things like print the Bounds of the
GraphicsNodes to see if they are someplace odd. You might
want to map the bounds to the 'global' coordinate system
(using getGlobalTransform) in case a odd scale/translate
snuck in.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Hi Jorg,
>
> One other 'high level' thought occured to me. Are you telling
> the canvas to always be dynamic? If not you can change the document
> all you want and nothing will happen.
>
yup, i'm even adding a static rect element "dynamically" to see if it
works, no problem.
>
> The GVT tree building is done by the bridge.GVTBuilder class.
> It's pretty simple, it basically checks if it has a bridge
> registered for the element that was added. If so it will
> build it's node and then check it's children, otherwise it stops.
ok. stepping through for a <path> element
in GVTBuilder, buildGraphicsNode(BridgeContext ctx,
Element e,CompositeGraphicsNode parentNode)
- an SVGPathElementBridge is built
- from this a graphicsnode is created , a ShapeNode more specifically
- this graphicsnode is added to the parentnode
- handleGenericBridges is called
- buildGraphicsnode is called again recursively
it seems to do this for pretty much every shape i add. Should i look for
something more specific ? If there was a namespace problem, would it not
find the registered bridge for this element? I can track the namespaces
and prefixes down to getBridge(Element) in BridgeContext.
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>
> Well, you will have a lot more problems than just this.
> Everywhere in Batik we fetch attributes with getAttributeNS(null, ...).
> Similarly for setting. To be honest I don't know if 'null' or "" is
> the proper value to use for attributes with 'no namespace'. I trust
> the folks who did all the initial DOM work to know so I suspect that
> 'null' is correct.
>
Well I trust your judgement equally so if you trust them ... :)
The problem only occurs when you don't parse the svg element using the
SAXSVGDocumentFactory, i suspect that one makes sure all the attribute
namespaces are null.
I put a filter on my contenthandler to null out the namespace for
attributes and know it works without changing batik. (I can still make
batik stackoverflow though by appending newlines to each element in my
document generator, but i'll switch that off for now)
Thanks for your help! (both Thomas and Tonny)
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> Jorg Heymans wrote:
> > to quickly prove my point, i changed
> > String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
> > in SVGPathElementBridge.buildShape() to
> > String s = e.getAttributeNS("",SVG_D_ATTRIBUTE); and it works!
>
> > is getAttributeNS("",...) valid
>
> Well, you will have a lot more problems than just this.
> Everywhere in Batik we fetch attributes with getAttributeNS(null, ...).
> Similarly for setting. To be honest I don't know if 'null' or "" is
> the proper value to use for attributes with 'no namespace'. I trust
> the folks who did all the initial DOM work to know so I suspect that
> 'null' is correct.
This is pretty weird. I thought null is the correct one instead of empty
string for batik.
All our application code that use batik always use null for namespace
instead of empty string and works. But in you case null does not works
but empty string works, very strange.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
> to quickly prove my point, i changed
> String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
> in SVGPathElementBridge.buildShape() to
> String s = e.getAttributeNS("",SVG_D_ATTRIBUTE); and it works!
> is getAttributeNS("",...) valid
Well, you will have a lot more problems than just this.
Everywhere in Batik we fetch attributes with getAttributeNS(null, ...).
Similarly for setting. To be honest I don't know if 'null' or "" is
the proper value to use for attributes with 'no namespace'. I trust
the folks who did all the initial DOM work to know so I suspect that
'null' is correct.
> or do i try and track down how i can prevent from parsing an empty
> string instead of null when the attribute namespace is not defined.
I would try and track down how to change this.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
to quickly prove my point, i changed
String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
in SVGPathElementBridge.buildShape() to
String s = e.getAttributeNS("",SVG_D_ATTRIBUTE); and it works!
Looking at
http://java.sun.com/j2se/1.4.2/docs/api/org/xml/sax/Attributes.html ,
getURI() i read
Return: the Namespace URI, or the empty string if none is available, or
null if the index is out of range.
is getAttributeNS("",...) valid or do i try and track down how i can
prevent from parsing an empty string instead of null when the attribute
namespace is not defined.
This explains why switching to xerces did not help :
http://xml.apache.org/xerces-j/apiDocs/org/xml/sax/Attributes.html#getURI(int)
THoughts?
Jorg
Jorg Heymans wrote:
> well i did this, the namespace is "" instead of null. Attributes don't
> inherit the namespace from their parents so i'm wondering where it is
> mangled.
>
> Could the plot finally be thickening?
> Was i right in choosing the thread's subject?
>
> We'll know in a minute!!
>
> :=)
> Jorg
>
> Thomas DeWeese wrote:
>
>> Jorg Heymans wrote:
>>
>>>
>>>
>>> Jorg Heymans wrote:
>>>
>>>> getPrimitiveBounds() fails because the shape is null. I've noticed
>>>> this before, I am now digging to see exactly where it tries to
>>>> associate a shape to the graphicsnode.
>>
>>
>>
>>> so, in SVGPathElementBridge buildShape() it does
>>> String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
>>>
>>> this returns "", effectively disabling shapecreation a bit later in
>>> the finally block -> shapeNode.setShape(app.getShape());
>>
>>
>>
>> This is your problem. You need to figure out where your
>> 'd' attribute went. My first guess is into another namespace.
>> You can get the list of all attributes on a node and iterate
>> through them (Element.getAttributes()).
>>
>> This should tell you where your 'd' attribute ended up.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
well i did this, the namespace is "" instead of null. Attributes don't
inherit the namespace from their parents so i'm wondering where it is
mangled.
Could the plot finally be thickening?
Was i right in choosing the thread's subject?
We'll know in a minute!!
:=)
Jorg
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>>
>>
>> Jorg Heymans wrote:
>>
>>> getPrimitiveBounds() fails because the shape is null. I've noticed
>>> this before, I am now digging to see exactly where it tries to
>>> associate a shape to the graphicsnode.
>
>
>> so, in SVGPathElementBridge buildShape() it does
>> String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
>>
>> this returns "", effectively disabling shapecreation a bit later in
>> the finally block -> shapeNode.setShape(app.getShape());
>
>
> This is your problem. You need to figure out where your
> 'd' attribute went. My first guess is into another namespace.
> You can get the list of all attributes on a node and iterate
> through them (Element.getAttributes()).
>
> This should tell you where your 'd' attribute ended up.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>
>
> Jorg Heymans wrote:
>
>> getPrimitiveBounds() fails because the shape is null. I've noticed
>> this before, I am now digging to see exactly where it tries to
>> associate a shape to the graphicsnode.
> so, in SVGPathElementBridge buildShape() it does
> String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
>
> this returns "", effectively disabling shapecreation a bit later in the
> finally block -> shapeNode.setShape(app.getShape());
This is your problem. You need to figure out where your
'd' attribute went. My first guess is into another namespace.
You can get the list of all attributes on a node and iterate
through them (Element.getAttributes()).
This should tell you where your 'd' attribute ended up.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Jorg Heymans wrote:
>
>
>
> getPrimitiveBounds() fails because the shape is null. I've noticed this
> before, I am now digging to see exactly where it tries to associate a
> shape to the graphicsnode.
so, in SVGPathElementBridge buildShape() it does
String s = e.getAttributeNS(null,SVG_D_ATTRIBUTE);
this returns "", effectively disabling shapecreation a bit later in the
finally block -> shapeNode.setShape(app.getShape());
Digging further into the getAttributeNS call, i see that it is failing
to get the attribute "d", which are effectively the path coordinates.
This returns null:
protected Node get(String ns, String nm) {
^^^^^^^^^^^^^^^^^^^^
ns is null here and nm is "d"
int hash = hashCode(ns, nm) & 0x7FFFFFFF;
int index = hash % table.length;
for (Entry e = table[index]; e != null; e = e.next) {
if ((e.hash == hash) && e.match(ns, nm)) {
return e.value;
}
}
return null;
}
It is somehow not able to find the d attribute as correct attribute to
the path node.
--- o0o ---
(in abstractelement now)
looking at
protected void attrAdded(Attr node, String newv) {
LiveAttributeValue lav = getLiveAttributeValue(node);
if (lav != null) {
lav.attrAdded(node, newv);
}
}
i can see in "newv" that my attributes are being parsed correctly.
However lav is always null (for both id and d attributes). Stepping in
the getLiveAttributeValue method :
String ns = node.getNamespaceURI(); --> ns is blank ""
return getLiveAttributeValue(ns, (ns == null)
? node.getNodeName()
: node.getLocalName());
effectively calling it with params ("", "d"), this leads to a call to
getLiveAttributeValue(ns,ln) that does nothing if the
liveAttributeValues (a softdoublyindexedtable) is null, which is the
case. The liveAttributeValues table is always null btw because it is
never initialized (getAttributeInitializer returns null and is not
overridden in SVGOMPathElement)
Does any of this help the problem analysis ?? All i can really do is
point to a logical sequence of elements. It might very well be that it's
ok to have a null shape, which effectively renders above useless.
Thoughts? I'm happy to keep stepping through code, i'm getting to know
my way around the internals a bit, can never harm :)
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>
>> FYI I've upgraded to the latest svn snapshot and was chasing a
>> stackoverflow error for a while. It seemed that batik didn't like the
>> fact that the <title> character data had one or more newlines at the
>> end of it. If you want more info let me know, i can easily reproduce it.
>
>
> Gahh, is it just a matter of having a title with multiple blank
> lines at the end?
ok probably not, it's most likely a knock-on effect of whatever i'm
doing that batik doesn't like. Fact is, when i removed the newline
generation on the server side the stack overflow went away.
>
>> But...it's still not displaying anything :(
>
>
> You need to get into the getPrimitiveBounds method and see
> why it's generating bad bounds... Is the shape empty, is the
> fill not set, etc...
getPrimitiveBounds() fails because the shape is null. I've noticed this
before, I am now digging to see exactly where it tries to associate a
shape to the graphicsnode.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>> <?xml version="1.0" encoding="ISO-8859-1"?><pon:pon
>> xmlns:pon="http://www.domek.be/pon">
> sorry i'm not following you, IMO the document is well formed. What do
> you mean by 2 root elements ?
I missed that your root element was on the same line
as the xml encoding decl.
> FYI I've upgraded to the latest svn snapshot and was chasing a
> stackoverflow error for a while. It seemed that batik didn't like the
> fact that the <title> character data had one or more newlines at the end
> of it. If you want more info let me know, i can easily reproduce it.
Gahh, is it just a matter of having a title with multiple blank
lines at the end?
> But...it's still not displaying anything :(
You need to get into the getPrimitiveBounds method and see
why it's generating bad bounds... Is the shape empty, is the
fill not set, etc...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> A couple of points. First this isn't a valid XML document:
>
> <?xml version="1.0" encoding="ISO-8859-1"?><pon:pon
> xmlns:pon="http://www.domek.be/pon">
> <pon:meta>
> </pon:meta>
> <pon:map xmlns:svg="http://www.w3.org/2000/svg" viewBox="423463.2
> -5470604.7 133015.10000000003 113988.29999999981">
>
> There can be only one root element you have two.
sorry i'm not following you, IMO the document is well formed. What do
you mean by 2 root elements ?
>
> Second: id="08111", Id's can't be just numbers IIRC they have to
> start with an Alpha (I don't think Batik actually cares but I believe
> other engines do).
i changed this but it had no effect.
FYI I've upgraded to the latest svn snapshot and was chasing a
stackoverflow error for a while. It seemed that batik didn't like the
fact that the <title> character data had one or more newlines at the end
of it. If you want more info let me know, i can easily reproduce it.
But...it's still not displaying anything :(
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
> Tonny Kohar wrote:
>
>> - if not null call gvtNode.getBounds() to check the resulting rectangle
>> geometry (x,y,w,h) is it really in the intended area space
Jorg Heymans wrote:
> Good tip it seems.
>
> getBounds() is null for all shapes i add that don't appear. Where does
> the bounds get set or what could be causing this ? In case it helps,
The bounds are calculated in a number of places probably you
care most about ShapeNode.getPrimitiveBounds, there are a few
outer getXXXBounds methods which might be of interest but this is
the one used by getBounds(). You might also check out the same
method in CompositeGraphicsNode.
> I've uploaded an example xml stream my servlet is generating to
> www.domek.be/map3.log.
A couple of points. First this isn't a valid XML document:
<?xml version="1.0" encoding="ISO-8859-1"?><pon:pon
xmlns:pon="http://www.domek.be/pon">
<pon:meta>
</pon:meta>
<pon:map xmlns:svg="http://www.w3.org/2000/svg" viewBox="423463.2
-5470604.7 133015.10000000003 113988.29999999981">
There can be only one root element you have two.
Second: id="08111", Id's can't be just numbers IIRC they have to
start with an Alpha (I don't think Batik actually cares but I believe
other engines do).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Tonny Kohar wrote:
> Hi,
>
>
>>What do you mean by importing? You mean physically node.importNode()? I
>>am not doing this, i create a node from the main SVGDocument and then
>>append my nodes to it with the correct namespace. Do you remember where
>>it casts the nodes into it's own implementation ?
>
>
> There is quite a lot of places. This is from cvs two/three days ago
> Under org.apache.batik.bridge
> - BridgeContext line 262,999,1366 ...
> - CSSUtilities line 72
> - SVGUtilties line 264 ..
> ...
>
The initial document i display is a static one from the filesystem, it
displays fine. Batik happily parses it into an SVGDocument and goes on
from there. So i'm assuming that the numerous casts of the document into
SVGDocument are ok. I thought you were talking about casting actual
nodes into some batik specific implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> What do you mean by importing? You mean physically node.importNode()? I
> am not doing this, i create a node from the main SVGDocument and then
> append my nodes to it with the correct namespace. Do you remember where
> it casts the nodes into it's own implementation ?
There is quite a lot of places. This is from cvs two/three days ago
Under org.apache.batik.bridge
- BridgeContext line 262,999,1366 ...
- CSSUtilities line 72
- SVGUtilties line 264 ..
...
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Tonny Kohar wrote:
> Hi,
>
> Some error in batik especially during runtime are not reported through
> Throw clause that we can catch using try..catch block, because some part
> of batik catch this error first and instead of re throw, it is pass the
> exception to the userAgent.displayError(Exception). So in your
> userAgent/inherited user agent, try to print the stack trace of the
> exception in method userAgent.displayError(Exception). The default
> userAgent.displayError() is just empty method.
I just added print statements to displayError, didn't get anything. I am
using a modified default JSVGCanvas implementation, this one had the
displayError methods set to display a popup.
>
> Secondly, how do you import the new created node. Are you using the
> batik SVG Implementation Document import? Ignoring the performance
> issues first (batik import is fast enough) try to use the Batik SVG
> Document import to make sure that the created node is using Batik class,
> because I saw some place in Batik code that cast some node into its own
> class eg: (SVGOMDocument)doc. This cast could throw exception if the
> node is not batik class.
What do you mean by importing? You mean physically node.importNode()? I
am not doing this, i create a node from the main SVGDocument and then
append my nodes to it with the correct namespace. Do you remember where
it casts the nodes into it's own implementation ?
I did however try this yesterday by replacing
oldlayer.getParentNode().replaceChild(newlayer,oldlayer);
with
oldlayer.getParentNode().replaceChild(getSVGDocument().importNode(newlayer,
true),oldlayer);
Does that cover your concern?
Thanks for your help
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> > Try to check the GVTNode exist or not by bridgeContext.getGraphicsNode
> > (Element) this method will return GVT node, if it succesfully create the
> > corresponding GVT node for new added element.
> > First check the returned GVT Node for
> > - null or not
> > - if not null call gvtNode.getBounds() to check the resulting rectangle
> > geometry (x,y,w,h) is it really in the intended area space
> >
>
> Good tip it seems.
>
> getBounds() is null for all shapes i add that don't appear. Where does
> the bounds get set or what could be causing this ? In case it helps,
> I've uploaded an example xml stream my servlet is generating to
> www.domek.be/map3.log.
Some error in batik especially during runtime are not reported through
Throw clause that we can catch using try..catch block, because some part
of batik catch this error first and instead of re throw, it is pass the
exception to the userAgent.displayError(Exception). So in your
userAgent/inherited user agent, try to print the stack trace of the
exception in method userAgent.displayError(Exception). The default
userAgent.displayError() is just empty method.
Secondly, how do you import the new created node. Are you using the
batik SVG Implementation Document import? Ignoring the performance
issues first (batik import is fast enough) try to use the Batik SVG
Document import to make sure that the created node is using Batik class,
because I saw some place in Batik code that cast some node into its own
class eg: (SVGOMDocument)doc. This cast could throw exception if the
node is not batik class.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
just FYI, I added debugging code just after line 210 in GVTBuilder.java,
(CVS build 18.11.2004)
Jorg Heymans wrote:
>
>
> Tonny Kohar wrote:
>
>>
>> Try to check the GVTNode exist or not by bridgeContext.getGraphicsNode
>> (Element) this method will return GVT node, if it succesfully create the
>> corresponding GVT node for new added element.
>> First check the returned GVT Node for
>> - null or not
>> - if not null call gvtNode.getBounds() to check the resulting rectangle
>> geometry (x,y,w,h) is it really in the intended area space
>>
>
> Good tip it seems.
>
> getBounds() is null for all shapes i add that don't appear. Where does
> the bounds get set or what could be causing this ? In case it helps,
> I've uploaded an example xml stream my servlet is generating to
> www.domek.be/map3.log.
>
> Thanks
> Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Tonny Kohar wrote:
>
> Try to check the GVTNode exist or not by bridgeContext.getGraphicsNode
> (Element) this method will return GVT node, if it succesfully create the
> corresponding GVT node for new added element.
> First check the returned GVT Node for
> - null or not
> - if not null call gvtNode.getBounds() to check the resulting rectangle
> geometry (x,y,w,h) is it really in the intended area space
>
Good tip it seems.
getBounds() is null for all shapes i add that don't appear. Where does
the bounds get set or what could be causing this ? In case it helps,
I've uploaded an example xml stream my servlet is generating to
www.domek.be/map3.log.
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> > Is it easy to pinpoint in batik where the decision is made if a node
> > gets drawn or not depending on its validity? Any debugging flags i can
> > set to get tons of internal debugging output?
>
> The GVT tree building is done by the bridge.GVTBuilder class.
> It's pretty simple, it basically checks if it has a bridge
> registered for the element that was added. If so it will
> build it's node and then check it's children, otherwise it stops.
Try to check the GVTNode exist or not by bridgeContext.getGraphicsNode
(Element) this method will return GVT node, if it succesfully create the
corresponding GVT node for new added element.
First check the returned GVT Node for
- null or not
- if not null call gvtNode.getBounds() to check the resulting rectangle
geometry (x,y,w,h) is it really in the intended area space
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
One other 'high level' thought occured to me. Are you telling
the canvas to always be dynamic? If not you can change the document
all you want and nothing will happen.
Jorg Heymans wrote:
> Is it easy to pinpoint in batik where the decision is made if a node
> gets drawn or not depending on its validity? Any debugging flags i can
> set to get tons of internal debugging output?
The GVT tree building is done by the bridge.GVTBuilder class.
It's pretty simple, it basically checks if it has a bridge
registered for the element that was added. If so it will
build it's node and then check it's children, otherwise it stops.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Jorg Heymans wrote:
>
>
>>
>> It is possible I would try having the code start with a correct
>> viewBox (note capital 'B') and see if this fixes things. I would also
>> try adding some 'marker' elements to the canvas (like a rect in
>> each 'corner') it's very difficult to tell the difference between an
>> empty document, and a clipped document ;)
>
>
I've set the marker elements at the top and bottom of my document. I
also set the viewbox statically. The marker elements appear in the same
place before and after i do the DOM update. The added elements are not
shown however.
This is driving me insane :)
Is it easy to pinpoint in batik where the decision is made if a node
gets drawn or not depending on its validity? Any debugging flags i can
set to get tons of internal debugging output?
thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> Good question, you aren't doing something daft like
> setting display/visibility on a parent are you?
nope doublechecked this. the path elements i am appending are in a <g>
element that has visibility="visible"
>> Again, dumping the svg to file and loading it in squiggle works fine.
>
>
> This is really not a very good test of 'did I get things right'
> because the reparse can fix a lot of subtle errors.
true, but it does eliminate viewBox and clipping mistakes IMO. Can you
give examples of these subtle errors ? Perhaps they enlighten me as to
what could be wrong.
>
> It is possible I would try having the code start with a correct
> viewBox (note capital 'B') and see if this fixes things. I would also
> try adding some 'marker' elements to the canvas (like a rect in
> each 'corner') it's very difficult to tell the difference between an
> empty document, and a clipped document ;)
I'll try adding a static border around the viewbox i set.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
> Thomas DeWeese wrote:
>> You could try printing 'getNamespaceURI' on the elements
>> that are finally added to the DOM.
Jorg Heymans wrote:
> it prints "http://www.w3.org/2000/svg" , the prefix is "svg".
> So this means that the node that is finally added to the dom has the
> correct namespace and a valid prefix right?
Yes, it would appear so.
> If this is the case and i don't get any other exceptions or warnings,
> why isn't the node shown?
Good question, you aren't doing something daft like
setting display/visibility on a parent are you?
> I am adding it using
> Node old = getSVGDocument().getElementById(oldID);
> oldNode.getParentNode().replaceChild(newNode, oldNode);
>
> Again, dumping the svg to file and loading it in squiggle works fine.
This is really not a very good test of 'did I get things right'
because the reparse can fix a lot of subtle errors.
> One more thing i just thought of : i set the viewbox coordinates also
> dynamically by replacing the attributes of the documentElement. I do
> this before i start swapping out nodes like above. Could this be
> problematic?
It is possible I would try having the code start with a correct
viewBox (note capital 'B') and see if this fixes things. I would also
try adding some 'marker' elements to the canvas (like a rect in
each 'corner') it's very difficult to tell the difference between an
empty document, and a clipped document ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Hi Jorg,
>
> Jorg Heymans wrote:
>
>> Could the transformerfactory maybe drop them ?
>
>
> It's possible, I've never used this. You could try printing
> 'getNamespaceURI' on the elements that are finally added to the DOM.
it prints "http://www.w3.org/2000/svg" , the prefix is "svg".
So this means that the node that is finally added to the dom has the
correct namespace and a valid prefix right?
If this is the case and i don't get any other exceptions or warnings,
why isn't the node shown? I am adding it using
Node old = getSVGDocument().getElementById(oldID);
oldNode.getParentNode().replaceChild(newNode, oldNode);
Again, dumping the svg to file and loading it in squiggle works fine.
One more thing i just thought of : i set the viewbox coordinates also
dynamically by replacing the attributes of the documentElement. I do
this before i start swapping out nodes like above. Could this be
problematic?
Thanks for your help
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Jorg Heymans wrote:
> Could the transformerfactory maybe drop them ?
It's possible, I've never used this. You could try printing
'getNamespaceURI' on the elements that are finally added to the DOM.
> I create it as following:
>
> SAXTransformerFactory factory = TransformerFactory.newInstance();
> TransformerHandler handler = factory.newTransformerHandler();
> handler.setResult(new DOMResult(parentnode)) -> parent node is the
> element i created from the SVGDoc
>
> I hope these snippets make sense.
>
> Regards
> Jorg
>
>
> Jorg Heymans wrote:
>
>> Hi,
>>
>> I am having a problem getting my canvas updates to appear. I know the
>> common pitfalls and i think i avoided them, hence my post.
>>
>> Here is what i am doing
>> - a servlet creates a stream of xml data, parts of this xml data is
>> used to build the SVG document, other parts not. I made sure that the
>> servlet declares the namespace prefixes at the begining of the doc,
>> and that all elements (not the attributes) used for the SVG doc have
>> the svg namespace prefix.
>> - a client canvas retrieves this stream and does the following
>> 1)create a reader using crimson's o.a.crimson.parser.XMLReaderImpl,
>> making sure it has namespace and namespaceprefix support
>> 2)setup a content handler that uses a SAX to DOM transformer
>> 3)parse the stream using the content handler, resulting in a DOM tree
>> of the SAX stream.
>>
>> The content handler appends the parsed nodes to an element that is
>> created from the current active SVGDocument (thus avoiding having to
>> import and clone them afterwards).
>>
>> I then move the newly created elements from this element to the
>> relevant nodes in the SVGDocument (in the canvasmgr update thread).
>> The updates aren't showing for some reason. But if i dump the updated
>> svg doc to a file and load it into squiggle it shows up fine :(
>>
>>
>> I believe there are namespace issues involved here, either i don't set
>> it correctly or batik does not see it. What can i do to debug this?
>>
>> Regards
>> Jorg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: namespace woes
Posted by Jorg Heymans <jh...@domek.be>.
i just switched to xerces 2.6.2, it didn't help so my suspicion about
namespaces seem to be correct.
Batik is rightfully ignoring any element that is not created with the
SVG namespace. But i do create a text document with correct prefixes
everywhere, and i made sure the client parser sees them (debugging the
contenthandler i can see that every startelement() has the correct URI
with it).
Could the transformerfactory maybe drop them ? I create it as following:
SAXTransformerFactory factory = TransformerFactory.newInstance();
TransformerHandler handler = factory.newTransformerHandler();
handler.setResult(new DOMResult(parentnode)) -> parent node is the
element i created from the SVGDoc
I hope these snippets make sense.
Regards
Jorg
Jorg Heymans wrote:
> Hi,
>
> I am having a problem getting my canvas updates to appear. I know the
> common pitfalls and i think i avoided them, hence my post.
>
> Here is what i am doing
> - a servlet creates a stream of xml data, parts of this xml data is used
> to build the SVG document, other parts not. I made sure that the servlet
> declares the namespace prefixes at the begining of the doc, and that all
> elements (not the attributes) used for the SVG doc have the svg
> namespace prefix.
> - a client canvas retrieves this stream and does the following
> 1)create a reader using crimson's o.a.crimson.parser.XMLReaderImpl,
> making sure it has namespace and namespaceprefix support
> 2)setup a content handler that uses a SAX to DOM transformer
> 3)parse the stream using the content handler, resulting in a DOM tree
> of the SAX stream.
>
> The content handler appends the parsed nodes to an element that is
> created from the current active SVGDocument (thus avoiding having to
> import and clone them afterwards).
>
> I then move the newly created elements from this element to the relevant
> nodes in the SVGDocument (in the canvasmgr update thread). The updates
> aren't showing for some reason. But if i dump the updated svg doc to a
> file and load it into squiggle it shows up fine :(
>
>
> I believe there are namespace issues involved here, either i don't set
> it correctly or batik does not see it. What can i do to debug this?
>
> Regards
> Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org