Bishop, Michael W. CONTR J9C880 wrote:
You say the document is never touched by SVGGraphics2D. Why does this
work at all?
graphics.getRoot(root);
This tells the graphics to append it's generated tree under
'root'. In this case 'root' happens to be the root element of
'svgDocument' but it could be any 'svg' element.
SVGDocumentManager is my singleton class that creates the document and
creates the SVGGraphics2D from that document. Since I append nothing to
the document, the call to canvas.setSVGDocument(...) shouldn't reflect
my drawing updates, but it does. I don't want to inadvertently add
everything twice.
I was talking about the no-args version of 'getRoot()'
'getRoot(Element)' returns the element passed in.
You also state that the calls to getRoot() returns a tree of everything
I did since I last called getRoot(). In order to tag elements with IDs
and potentially other attributes, I need to call getRoot() after every
draw operation to identify each object uniquely. Otherwise, they get
grouped together.
Correct if you insist on using the SVGGraphics2D for this you
must call getRoot after every drawing operation.
So strictly speaking in the SVGGraphics2D/SVGDocument sense I'd do
something like this:
- Do a render operation. In basic terms, a line, an oval, a shape, etc.
- Call getRoot() which gives me the root of the tree. Given the oval
example again, what would it return exactly? The "defs" element, the
first "g" element, or the "ellipse" object?:
IIRC it would return an SVG element that wraps all of them:
<svg>
<defs id="genericDefs" />
<g>
<g fill="rgb(255,102,102)" stroke="rgb(255,102,102)">
<ellipse rx="69" fill="none" ry="47.5" cx="174" cy="196.5" />
</g>
</g>
</svg>
- Set an ID on this element. Again, I'm not sure which level we're
talking about. I would assume one of the "g" elements.
This is up to you , for simple paint's the 'defs' serves no purpose.
The outer 'g' is also mostly useless in the 'one draw operation at a
time' case, so you are left with just the inner 'g' that needs to be
kept.
- Append the element to the SVGDocument. At this point, I should be
able to walk through the entire document and "see" the element I added.
This is something I was unable to do before.
If the document displayed your content, then there was something
wrong with your 'walking' routine as the Canvas simply uses the standard
DOM calls to walk your tree building the graphics tree.
I did previously write a test and play with the SVGShape class and used
the toSVG() method to get what I wanted. Again, I didn't understand
that the document remained untouched and had the same problem with an
empty document when I tried to walk through it.
Yes, so you would want to do something like:
Element e = svgShape.toSVG(java2dShape);
e.setAttributeNS(null, "fill", "red");
root.appendChild(e).
I know these must be basic questions overall. If there is a resource
that helps explain that'd be great. In the mean time, I'm kind of
keeping up with a two-pronged attack; understanding both SVG and how
Batik works with it...:)
Michael Bishop
-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Sent: Monday, September 12, 2005 1:24 PM
To: [email protected]
Subject: Re: Basic SVG management in Batik with white-boarding.
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
You should probably just append the new SVG object to the current
document. If you tell Batik to treat the document as ALWAYS_DYNAMIC
and do the append in the UpdateManager's RunnableQueue (just search
the list for these things for examples) Batik will much more
efficiently update the display.
Bishop, Michael W. CONTR J9C880 wrote:
OK, I understand the thought process. Telling the JSVGCanvas to
treat the document as ALWAYS_DYNAMIC registers a bunch of listeners.
The UpdateManager can register threads that I should write to append
to
the document. Unfortunately, there seems to be no way to "search"
this
list; the link to "EyeSearch" on the main page is advertised as being
broken and well, it is...:) Am I missing something? It looks like I
need to do the following:
- Register a GVTTreeListener to know when the first rendering of the
canvas has occurred. This is necessary because the canvas'
UpdateManager is null.
Yes, or you can register an 'onload' DOM event handler.
- Create a new SVG element (perhaps with SVGGraphics2D?) based on the
user's drawing operation.
- Write a thread that appends data to the SVGDocument and invoke this
thread with the UpdateManager.
Technically it is not a thread, it is a class that
implements 'java.lang.Runnable' (thread also happens to implement
the Runnable interface).
Yes, it's important to know that the SVGGraphics2D only
uses the document you give it as a 'factory' for elements.
It does not insert it's elements into the document.
Ok, the relationship between SVGGraphics2D and the document is
what
I don't think I understand. I was under the impression that calls to
SVGGraphics2D updated the document it was created with.
No it does not touch the document you created it with. That
document is used as a factory to create Elements
(Document.createElementNS).
Then I do rendering using the SVGGraphics2D. How can I use the
SVGGraphics2D object to:
- Create a single "piece" that identifies a drawing operation complete
with pen color, shape type, size, etc. For example, here is a pinkish
oval I drew on my canvas:
<defs id="genericDefs" />
<g>
<g fill="rgb(255,102,102)" stroke="rgb(255,102,102)">
<ellipse rx="69" fill="none" ry="47.5" cx="174" cy="196.5" />
</g>
</g>
- Assign an "ID" to this piece so I can reference it later.
- Append it to the document that is used to maintain the state of the
canvas.
So as I said before the SVGGraphics2D is really intended to handle
the conversion of individual elements. This is really more complex
as there is a need to potentially create Gradient elements for fill,
create image elements when drawing images etc. The SVGGraphics2D
is also oriented towards generating fairly high-quality SVG for complex
drawings, so it tries to group property settings at an appropriate
level if a number of elements are drawn with the same attributes,
etc. This is why it doesn't do what you are looking to do real well.
I know I could probably do basic shapes in SVG myself, but more
advanced
functionality will need to come later and I'd like to do it in a
consistent manner. If I can use the SVGGraphics2D, I have a uniform
way
of doing pretty much everything that Graphics2D can do with SVG
transformation.
But if you are constantly intermixing 'special' calls to tweak
everything I don't know that you are really using a Graphics2D,
and as I said above if you start doing complex things with the
Graphics2D it may be that you won't be able to use a simple minded
'I draw one thing I get one element' view.
You might look at the SVGShape class in that package which will
take any Java 2D 'shape' and convert it to an SVG Element. Similarly
there is a SVGPaint/SVGColor class that convert's paint's/Color's to
SVG compatible defns.
Well you can call getRoot without an SVG Element in which case
it will construct an SVG Element for you which you can add your
'id' to - which isn't much mucking with the document.
Right, this seems like what I want to do as described above, but
again, I'm missing the relationship between the SVGDocument and the
SVGGraphics2D. Would I do something like this?
Element element = svgGraphics2D.getRoot();
// This line is pseudocode, so excuse syntax errors.
Element.setAttribute("id", "someId");
svgGraphics2D.drawLine(...);
Close but order of operations is wrong:
svgGraphics2D.drawLine(...);
Element element = svgGraphics2D.getRoot();
element.setAttribute("id", "someId");
doc.getElementById("groupForDrawing").appendChild(element);
and have the result be an SVG snippet with a line drawn and an ID set?
In short, when I draw, how do I know which element I'm working with?
The "getRoot()" call is what confuses me.
You don't know what element your working with until after you
draw (after all you could be working with a text element, a path,
a rect, ....). getRoot returns a tree of elements that represents
everything you drew since the last call to 'getRoot' (or the
Graphics was created). In fact it doesn't even build the tree until
you request it since it is trying to share attribute/property defns
across as many elements as possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
