Wow, this is a lot to absorb.  I've put together what I have from
Internet searching, examples, and the API documentation.  Is there any
place out there that has good sample code for constant manipulation of
the root document?  To keep me sane, let's concentrate on the thought
process for basic SVGGraphics2D/SVGDocument maintenance:

You say the document is never touched by SVGGraphics2D.  Why does this
work at all?

JSVGCanvas canvas = (JSVGCanvas) mE.getSource();
PropertyManager propertyManager = PropertyManager.getInstance();

SVGDocument svgDocument =
SVGDocumentManager.getInstance().getDocument();
Element root = svgDocument.getDocumentElement();
SVGGraphics2D graphics = SVGDocumentManager.getInstance().getGraphics();
graphics.getRoot(root);
canvas.setSVGDocument(svgDocument);

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.

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.

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?:

<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>

- 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.

- 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.

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.

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]

Reply via email to