xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <Michael.Bis...@je.jfcom.mil>
Subject RE: Basic SVG management in Batik with white-boarding.
Date Mon, 12 Sep 2005 16:33:36 GMT

-----Original Message-----
From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
Sent: Friday, September 09, 2005 6:38 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Basic SVG management in Batik with white-boarding.

Hi Michael,

Bishop, Michael W. CONTR J9C880 wrote:

>      I'm trying to develop a simple white-boarding style program with 
> Batik and have run into a couple fundamental problems.  Here is a
> outline of the steps used:
> -           User draws a shape or line on the application's glass
> -           X and Y coordinates are saved and then drawn to an 
> SVGDocument via SVGGraphics2D object.
> -           SVGCanvas "sets" the SVGDocument and the resulting changes

> are shown on the screen.

>>     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
>> update the display.

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

>      Now this works fine until I try to "save" the results to an SVG 
> file.  The interaction with the document doesn't work as expected for
> I have to do the following to get anything to render on the screen:
> Element root = svgDocument.getDocumentElement();
> svgGraphics2D.getRoot(root);
> Only when I make these calls, will anything show when I call 
> svgCanvas.setDocument(svgDocument).

>>    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.  I create a
document like so:

String svgNamespaceURI = SVGDOMImplementation.SVG_NAMESPACE_URI;
DOMImplementation domImpl = SVGDOMImplementation.getDOMImplementation();
svgDocument = (SVGDocument) domImpl.createDocument(svgNamespaceURI,
"svg", null);

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 fill="rgb(255,102,102)" stroke="rgb(255,102,102)">
      <ellipse rx="69" fill="none" ry="47.5" cx="174" cy="196.5" />

- 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

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

> After doing that, displaying the resultant XML doesn't look correct.  
> Here is output from a line, a box, and an oval:
>   <!--Generated by the Batik Graphics2D SVG Generator-->
>   <!--Generated by the Batik Graphics2D SVG Generator-->
>   <!--Generated by the Batik Graphics2D SVG Generator-->
>   <!--Generated by the Batik Graphics2D SVG Generator-->

> Again, I have to make the call to SVGGraphics2D.getRoot(...) to
> anything at all.  I don't understand why I have separate definitions
> doubly-nested <g> elements for each shape.  It also looks like the SVG

> generator is generating a different document fragment for every paint 
> operation which may be what it's supposed to do.

>>     This is exactly what it does.  The real purpose of the
>> is to turn 'complex' drawing operations into SVG.  For simple
>> you can do a much better job of creating the elements and making a
>> 'pretty' document.

So SVGGraphics2D on every draw/render operation will do:

<!--Generated by the Batik Graphics2D SVG Generator-->
  <defs id="genericDefs" />
    <g ...>

> A related question is, how can I identify each object I draw?  I've
> in the SVG specs, an "id" can be given to a <g> element.  In a later 
> iteration, I may want to identify and "move" or "delete" a shape I've 
> already drawn.  Does the Batik toolkit allow me to give an ID to a
> operation and manipulate it later, or will I have to dig through the
> document myself to gain that functionality?

>>      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");


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.

Michael Bishop

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message