You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Ryan Marsh <me...@ryanmarsh.com> on 2001/02/09 12:05:07 UTC
documentation is a terrible thing to waste :-)
I was trying to get my head around the Batik code tonight and was
attempting a simple excercise, I need a little direction. Basically I
just want to use Batik to draw a rectangle, set the color of it to red,
and either spit out the SVG or spit out a JPEG (or even better.. display
it dynamically).
It seemed to me (at first) that GVT is (the controller) what you guys
used to modify the "model" (SVG or Graphics2D?). So I wanted to find out
how to draw a rectangle using GVT so I started digging through the
source for the rasterizer app. It seemed a good starting point because
it reads in an SVG document and then builds graphics using GVT... but
not so fast. Now something called the bridge comes into play. I started
digging deeper and found that the magic occurs in ConcreteGVTBuilder
which takes an svg doc and, node by node, generates a GVT tree? Which is
directly translateable to Graphics2D? What does the translating, the
bridge again? This is where I'm starting to get lost. I supposed there
was some code somwhere that would look something like this:
if rectangle
draw graphics2D rectangle
else if circle
draw graphics2D circle
etc...
or something along those lines, and maybe something that works in
reverse.
So I guess my real question is:
Which is the model, which is the controller, which is the view? Or am I
even applying the right pattern? Please, set me straight or point me to
some documentation I have yet to discover.
Once again, congrats. The code looks really nice.
> That sounds like a cool app. Keep us posted!
>
Sure will.
> > - Would you suggest I wait around for JSVGCanvas or would I be better off
> > rolling my own to start with?
>
> My suggestion is, wait for JSVGCanvas. The threading stuff is time
I don't want anyone commiting to dates but do you have anyidea how far
off in the future that is? Any ways I can help you get there faster?
FYI: (though you may already know) The Java2D list has pretty good
discussions. If you guys ever have Java2D problems there are some pretty
talented people that respond on the list.
JAVA2D-INTEREST@JAVA.SUN.COM
Thanks,
-ryan
Re: documentation is a terrible thing to waste :-)
Posted by Thierry Kormann <tk...@sophia.inria.fr>.
> If you want to help with the documentation effort, that would be very
> helpful.
And a good way to learn and improve the Batik's APIs :)
Thierry.
Re: documentation is a terrible thing to waste :-)
Posted by Stephane Hillion <St...@sophia.inria.fr>.
On Monday 12 February 2001 05:15, Ryan Marsh wrote:
> Stephane are you currently working on the DOM API? If so, how can I help
> you? If not, I need to start working on it yesterday (unless anyone
> objects).
I am working on it in background. The DOM core API implementation is
completed, the Event module too. The majority of the SVG classes are here,
they implement what is needed for CSS, but not more: there are too much
pending issues to move forward. The main reason for this is that most of the
SVG DOM utility methods require a knowledge of what is actually displayed on
the screen and for the moment nothing has been designed to directly link DOM
and the graphics layer.
> Thierry, If I'm understanding you correctly, you believe we need an
> interstitiary layer between the DOM API and SMIL. Will that get in the
> way of pursuing the DOM API? It sounded as though you were suggesting
> that the interstitiary layer would need to be completed first. Please
> advise.
The implementation of the SVG DOM SVGAnimated* interfaces and the
getAnimated*() methods depends on the requirements and the choices we will
take for the SMIL module.
In conclusion I can't make any choice now, and I don't want to start in a
possibly wrong direction with a set of ~150 classes to maintain ;)
--
Stephane.
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
Certainly.
Regards,
-ryan
"First, they ignore you. Then they laugh at you. Then they fight you. Then
you win."
-- Mahatma Ghandi:
----- Original Message -----
From: Vincent Hardy <vh...@eng.sun.com>
To: <ba...@xml.apache.org>
Sent: Monday, February 12, 2001 10:57 AM
Subject: Re: documentation is a terrible thing to waste :-)
> Ryan,
>
> Thanks for all the help you are offering. I am already working on
> a document on Batik's architecture with UML diagrams and I think we
> should avoid duplicating efforts. Would you be willing to review the
> stuff I am working on?
>
> Thanks.
> V.
>
> Ryan Marsh wrote:
> >
> > > > I'd like to go ahead and implement these interfaces.
> > >
> > > Well, if stephane (the one who is responsible on that part) has not
yet
> > > implemented the SVG DOM API is simply because we would like to have
fast
> > > performance for the dynamic part.
> > >
> > > Honestly, we can not implement that part now. We need first an
intermediate
> > > API that be based on the DOM API and what the SMIL animation module
needs to
> >
> > Now that I've discovered that the DOM API is what I was looking for, I
> > want to make it work. That's why I was interested in Batik in the first
> > place. I need what the DOM API will have to offer. I will record what I
> > learn as I go along. I believe this will generate good documentation.
> > I'd also like to document the overall design of Batik.
> >
> > So those are the gifts I have to offer. I really can't do much else. My
> > use of Batik is such a small part of is becomming a very large system
> > (referring to my project). I have a tendency to over subscribe myself,
> > but here I have to stay focused otherwise I will never finish the
> > project at hand.
> >
> > Stephane are you currently working on the DOM API? If so, how can I help
> > you? If not, I need to start working on it yesterday (unless anyone
> > objects).
> >
> > Thierry, If I'm understanding you correctly, you believe we need an
> > interstitiary layer between the DOM API and SMIL. Will that get in the
> > way of pursuing the DOM API? It sounded as though you were suggesting
> > that the interstitiary layer would need to be completed first. Please
> > advise.
> >
> > > and sometimes hard to use. If you are really motivated, a first
challenge
> > > could be to build a tool (and its documentation :) over the transcoder
API.
> >
> > I'm really sorry but I just can't help with the Trasncoders right now.
> > You can bet I'll document what I learn if I run across them though.
> > Thanks for the suggestion though.
> >
> > --
> > Regards,
> > -ryan
> >
> > The three great virtues of programming are laziness, impatience,
> > and hubris, but bigotry makes the open-source world go round.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: documentation is a terrible thing to waste :-)
Posted by Vincent Hardy <vh...@eng.sun.com>.
Ryan,
Thanks for all the help you are offering. I am already working on
a document on Batik's architecture with UML diagrams and I think we
should avoid duplicating efforts. Would you be willing to review the
stuff I am working on?
Thanks.
V.
Ryan Marsh wrote:
>
> > > I'd like to go ahead and implement these interfaces.
> >
> > Well, if stephane (the one who is responsible on that part) has not yet
> > implemented the SVG DOM API is simply because we would like to have fast
> > performance for the dynamic part.
> >
> > Honestly, we can not implement that part now. We need first an intermediate
> > API that be based on the DOM API and what the SMIL animation module needs to
>
> Now that I've discovered that the DOM API is what I was looking for, I
> want to make it work. That's why I was interested in Batik in the first
> place. I need what the DOM API will have to offer. I will record what I
> learn as I go along. I believe this will generate good documentation.
> I'd also like to document the overall design of Batik.
>
> So those are the gifts I have to offer. I really can't do much else. My
> use of Batik is such a small part of is becomming a very large system
> (referring to my project). I have a tendency to over subscribe myself,
> but here I have to stay focused otherwise I will never finish the
> project at hand.
>
> Stephane are you currently working on the DOM API? If so, how can I help
> you? If not, I need to start working on it yesterday (unless anyone
> objects).
>
> Thierry, If I'm understanding you correctly, you believe we need an
> interstitiary layer between the DOM API and SMIL. Will that get in the
> way of pursuing the DOM API? It sounded as though you were suggesting
> that the interstitiary layer would need to be completed first. Please
> advise.
>
> > and sometimes hard to use. If you are really motivated, a first challenge
> > could be to build a tool (and its documentation :) over the transcoder API.
>
> I'm really sorry but I just can't help with the Trasncoders right now.
> You can bet I'll document what I learn if I run across them though.
> Thanks for the suggestion though.
>
> --
> Regards,
> -ryan
>
> The three great virtues of programming are laziness, impatience,
> and hubris, but bigotry makes the open-source world go round.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
> > I'd like to go ahead and implement these interfaces.
>
> Well, if stephane (the one who is responsible on that part) has not yet
> implemented the SVG DOM API is simply because we would like to have fast
> performance for the dynamic part.
>
> Honestly, we can not implement that part now. We need first an intermediate
> API that be based on the DOM API and what the SMIL animation module needs to
Now that I've discovered that the DOM API is what I was looking for, I
want to make it work. That's why I was interested in Batik in the first
place. I need what the DOM API will have to offer. I will record what I
learn as I go along. I believe this will generate good documentation.
I'd also like to document the overall design of Batik.
So those are the gifts I have to offer. I really can't do much else. My
use of Batik is such a small part of is becomming a very large system
(referring to my project). I have a tendency to over subscribe myself,
but here I have to stay focused otherwise I will never finish the
project at hand.
Stephane are you currently working on the DOM API? If so, how can I help
you? If not, I need to start working on it yesterday (unless anyone
objects).
Thierry, If I'm understanding you correctly, you believe we need an
interstitiary layer between the DOM API and SMIL. Will that get in the
way of pursuing the DOM API? It sounded as though you were suggesting
that the interstitiary layer would need to be completed first. Please
advise.
> and sometimes hard to use. If you are really motivated, a first challenge
> could be to build a tool (and its documentation :) over the transcoder API.
I'm really sorry but I just can't help with the Trasncoders right now.
You can bet I'll document what I learn if I run across them though.
Thanks for the suggestion though.
--
Regards,
-ryan
The three great virtues of programming are laziness, impatience,
and hubris, but bigotry makes the open-source world go round.
Re: documentation is a terrible thing to waste :-)
Posted by Thierry Kormann <tk...@sophia.inria.fr>.
On Sunday 11 February 2001 15:58, you wrote:
> Ok, so it looks like what I'm looking for is in the org.w3c.dom.svg
> package. The problem is that they are all interfaces which have not yet
> been implemented (in Batik for that matter). If it's ok with you guys,
> I'd like to go ahead and implement these interfaces.
Well, if stephane (the one who is responsible on that part) has not yet
implemented the SVG DOM API is simply because we would like to have fast
performance for the dynamic part.
Honestly, we can not implement that part now. We need first an intermediate
API that be based on the DOM API and what the SMIL animation module needs to
work (ie. getting the animated value, changing those values...). So, at this
time, it's no need to implement the SVG DOM as the implementation must rely
on this intermediate API. And at last, it's not an easy first contribution to
batik :)
Otherwise, we need (to improve the Batik's API and documentation) so work
around the transcoders. Many people complained that the API is not documented
and sometimes hard to use. If you are really motivated, a first challenge
could be to build a tool (and its documentation :) over the transcoder API.
There is tons of ides here, but I am sure you will find yours...
Regards,
Thierry.
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
Ok, so it looks like what I'm looking for is in the org.w3c.dom.svg
package. The problem is that they are all interfaces which have not yet
been implemented (in Batik for that matter). If it's ok with you guys,
I'd like to go ahead and implement these interfaces.
-ryan
On 11 Feb 2001 01:36:22 -0800, Ryan Marsh wrote:
> > tree. So, for example, if you'd like
> > to update an attribute in a rectangle (e.g., its fill color),
> > you would use the DOM API directly.
>
>
> If I'm going to be manipulating the DOM directly is there a (relatively)
> mature object model I can use? If I shouldn't use SVGGraphics2D (which
> seems a nice API) and I shouldn't use the bridge or GVT to directly
> manipulate the DOM what should I use? I don't like the idea of creating
> elements and setting their arguments without any kind of typing of those
> objects (instead they are text strings). Here is what I am talking
> about:
>
> Element e;
> e = document.createElementNS(svgNS, "rect");
> e.setAttributeNS(null, "x", "10");
> e.setAttributeNS(null, "y", "10");
> e.setAttributeNS(null, "width", "200");
> e.setAttributeNS(null, "height", "300");
> e.setAttributeNS(null, "style",
> "fill:red;stroke:black;stroke-width:4");
> root.appendChild(e);
>
> Instead, it would be nice to modify theDOM somthing like this:
>
> SVGRect rect = new SVGRect();
> rect..setX(10);
> rect.setY(10);
> rect.setWidth(200);
> rect.setHeight(300);
> rect.getStyle().setFill(new Color("red"));
> etc...
> doc.appendElement(rect);
>
> Does this exist? If not, should I create it?
>
> -ryan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
--
Regards,
-ryan
The three great virtues of programming are laziness, impatience,
and hubris, but bigotry makes the open-source world go round.
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
> tree. So, for example, if you'd like
> to update an attribute in a rectangle (e.g., its fill color),
> you would use the DOM API directly.
If I'm going to be manipulating the DOM directly is there a (relatively)
mature object model I can use? If I shouldn't use SVGGraphics2D (which
seems a nice API) and I shouldn't use the bridge or GVT to directly
manipulate the DOM what should I use? I don't like the idea of creating
elements and setting their arguments without any kind of typing of those
objects (instead they are text strings). Here is what I am talking
about:
Element e;
e = document.createElementNS(svgNS, "rect");
e.setAttributeNS(null, "x", "10");
e.setAttributeNS(null, "y", "10");
e.setAttributeNS(null, "width", "200");
e.setAttributeNS(null, "height", "300");
e.setAttributeNS(null, "style",
"fill:red;stroke:black;stroke-width:4");
root.appendChild(e);
Instead, it would be nice to modify theDOM somthing like this:
SVGRect rect = new SVGRect();
rect..setX(10);
rect.setY(10);
rect.setWidth(200);
rect.setHeight(300);
rect.getStyle().setFill(new Color("red"));
etc...
doc.appendElement(rect);
Does this exist? If not, should I create it?
-ryan
Re: documentation is a terrible thing to waste :-)
Posted by Mariano Kamp <mk...@codamax.com>.
On Sunday 11 February 2001 00:14 Mariano Kamp wrote:
> > > A small price to pay though for
> > > documentation. Is there any specific need that you see for the
> > > documentation to address?
> >
> > I think that a developer's Q&A would be good, i.e., questions like,
> > "How do I create a JPEG or PNG image from an SVG Document" with
> > an answer showing a code snippet, or "What is the bridge?" with a
> > short answer on the module's high level responsibility.
> > Any other suggestions?
>
> I guess meanwhile I should be qualified to provide the base for the answer
> of the first question. The information is on the list already.
> I'll do that on next weeks sunday and post it back to the list. Ryan,
> maybe you can incorporate it?!
Well, my initial guess was wrong. I am not qualified to build the base for
the first question. There are too many black holes for me.
I attached the starting point of my "question" to this mail, but it's
rubbish. I have to go into it much deeper to understand what all the classes
are doing and right now I can't do that. I am currently working on Sundays
for my regular job. I probably resume this later on.
Sorry,
Mariano
--
mariano kamp
codamax ag
hessenring 89
61348 bad homburg v.d.h.
germany
phone +49 6172 182 473
fax +49 6172 182 475
mobile +49 173 300 8564 (changed!)
Re: documentation is a terrible thing to waste :-)
Posted by Vincent Hardy <vh...@eng.sun.com>.
Thanks Mariano! This will be very helpful.
V.
Mariano Kamp wrote:
>
> > > A small price to pay though for
> > > documentation. Is there any specific need that you see for the
> > > documentation to address?
> >
> > I think that a developer's Q&A would be good, i.e., questions like,
> > "How do I create a JPEG or PNG image from an SVG Document" with
> > an answer showing a code snippet, or "What is the bridge?" with a
> > short answer on the module's high level responsibility.
> > Any other suggestions?
> I guess meanwhile I should be qualified to provide the base for the answer
> of the first question. The information is on the list already.
> I'll do that on next weeks sunday and post it back to the list. Ryan,
> maybe you can incorporate it?!
>
> Mariano
>
> --
> mariano kamp
> codamax ag
> hessenring 89
>
> 61348 bad homburg v.d.h.
> germany
>
> phone +49 6172 182 473
> fax +49 6172 182 475
> mobile +49 173 300 8564 (changed!)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
> of the first question. The information is on the list already.
> I'll do that on next weeks sunday and post it back to the list. Ryan,
> maybe you can incorporate it?!
Sure just point me in the right direction and I'll add it to the
documentation. Feel free to repost any important threads.
-ryan
Re: documentation is a terrible thing to waste :-)
Posted by Mariano Kamp <mk...@codamax.com>.
> > A small price to pay though for
> > documentation. Is there any specific need that you see for the
> > documentation to address?
>
> I think that a developer's Q&A would be good, i.e., questions like,
> "How do I create a JPEG or PNG image from an SVG Document" with
> an answer showing a code snippet, or "What is the bridge?" with a
> short answer on the module's high level responsibility.
> Any other suggestions?
I guess meanwhile I should be qualified to provide the base for the answer
of the first question. The information is on the list already.
I'll do that on next weeks sunday and post it back to the list. Ryan,
maybe you can incorporate it?!
Mariano
--
mariano kamp
codamax ag
hessenring 89
61348 bad homburg v.d.h.
germany
phone +49 6172 182 473
fax +49 6172 182 475
mobile +49 173 300 8564 (changed!)
Re: documentation is a terrible thing to waste :-)
Posted by Vincent Hardy <vh...@eng.sun.com>.
Ryan Marsh wrote:
>
>
> > Any other suggestions?
>
> UML diagrams of Batik. But that won't come for a while. Having not
> designed this myself I'll have to have a very good understanding of
> Batik before I can attempt this. Were there any bar napkin drawings or
> any models created before you embarked upon this project?
>
Yes. There were and there still are diagrams. I need to package them
(in SVG) and clean them up. This is in the works: bear with me :-)
V.
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
> I think that a developer's Q&A would be good, i.e., questions like,
> "How do I create a JPEG or PNG image from an SVG Document" with
Good idea. I'd be happy to do that. What are some other questions you
think I should cover.
> Any other suggestions?
UML diagrams of Batik. But that won't come for a while. Having not
designed this myself I'll have to have a very good understanding of
Batik before I can attempt this. Were there any bar napkin drawings or
any models created before you embarked upon this project?
> There is some documentation we are working on that would be useful
> to you when/if you start working on this. It gives a high level
Just shoot it on over to me. I'll get started, I can clean it up and ask
questions as I go along.
-ryan
Re: documentation is a terrible thing to waste :-)
Posted by Vincent Hardy <vh...@eng.sun.com>.
Ryan,
Actually, SVGGraphics2D is independant of the DOM/Bridge/GVT.
SVGGraphics2D is a way to create a DOM, but it is usually a one-time
operation. You would typically manipulate the DOM directly rather
than going through SVGGraphics2D. SVGGraphics2D grows a DOM
tree, but you typically do not use SVGGraphics2D to update that
tree. So, for example, if you'd like
to update an attribute in a rectangle (e.g., its fill color),
you would use the DOM API directly.
> As an outsider coming in to the project I'm sure that there will be many
> others to follow in these same footsteps. I'd be happy to document what
> I learn about Batik, but that won't happen without alot of bugging you
> guys... I hope you don't mind.
Not at all! We would all be glad to help!
> A small price to pay though for
> documentation. Is there any specific need that you see for the
> documentation to address?
I think that a developer's Q&A would be good, i.e., questions like,
"How do I create a JPEG or PNG image from an SVG Document" with
an answer showing a code snippet, or "What is the bridge?" with a
short answer on the module's high level responsibility.
Any other suggestions?
There is some documentation we are working on that would be useful
to you when/if you start working on this. It gives a high level
description of Batik and the various modules. It needs clean up (which
is why it is not yet available, as it might create more confusion
than it would help in its current state), but I could clean it
up and post it when you are ready.
V.
Ryan Marsh wrote:
>
> > To output you graphic to SVG, the SVGGraphics2D class will do what you
> > want. You can build it, then draw into it and then output your
> > graphics as SVG easily.
> > ...
> > You could also use SVGGraphics2D to generate SVG and then use
> > the transcoder to convert that to JPEG. I have attached an example that
> > does that.
> > ...
> > We are working on documenting things more. I am not going to attempt
> > describing the whole thing, but in a nutshell, the DOM is our model
> > and the API through which the SVG graphics is manipulated. GVT is
> > a view of the model. Renderers can paint a GVT tree and the bridge
> > can build a GVT tree and 'hook it' to the DOM model.
> >
>
> So what I am gathering is I should use SVGGraphics to modify the model
> (DOM). GVT is a view of the DOM, and the controller is the bridge. Myabe
> MVC isn't the right pattern here. Either way I need to find the right
> metaphor for understanding the system.
> So we have:
>
> Renderer (view?)
> |
> GVT (api)
> |
> Bridge (controller?)
> |
> SVGGraphics2D (api)
> |
> DOM (model?)
>
> > If you want to help with the documentation effort, that would be very
> > helpful.
>
> As an outsider coming in to the project I'm sure that there will be many
> others to follow in these same footsteps. I'd be happy to document what
> I learn about Batik, but that won't happen without alot of bugging you
> guys... I hope you don't mind. A small price to pay though for
> documentation. Is there any specific need that you see for the
> documentation to address?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: documentation is a terrible thing to waste :-)
Posted by Ryan Marsh <me...@ryanmarsh.com>.
> To output you graphic to SVG, the SVGGraphics2D class will do what you
> want. You can build it, then draw into it and then output your
> graphics as SVG easily.
> ...
> You could also use SVGGraphics2D to generate SVG and then use
> the transcoder to convert that to JPEG. I have attached an example that
> does that.
> ...
> We are working on documenting things more. I am not going to attempt
> describing the whole thing, but in a nutshell, the DOM is our model
> and the API through which the SVG graphics is manipulated. GVT is
> a view of the model. Renderers can paint a GVT tree and the bridge
> can build a GVT tree and 'hook it' to the DOM model.
>
So what I am gathering is I should use SVGGraphics to modify the model
(DOM). GVT is a view of the DOM, and the controller is the bridge. Myabe
MVC isn't the right pattern here. Either way I need to find the right
metaphor for understanding the system.
So we have:
Renderer (view?)
|
GVT (api)
|
Bridge (controller?)
|
SVGGraphics2D (api)
|
DOM (model?)
> If you want to help with the documentation effort, that would be very
> helpful.
As an outsider coming in to the project I'm sure that there will be many
others to follow in these same footsteps. I'd be happy to document what
I learn about Batik, but that won't happen without alot of bugging you
guys... I hope you don't mind. A small price to pay though for
documentation. Is there any specific need that you see for the
documentation to address?
Re: documentation is a terrible thing to waste :-)
Posted by Vincent Hardy <vh...@eng.sun.com>.
Ryan,
You have multiple questions, and I am going to answer a few.
a. Drawing a rectangle to SVG and or JPEG.
To output you graphic to SVG, the SVGGraphics2D class will do what you
want. You can build it, then draw into it and then output your
graphics as SVG easily.
To output as JPEG, you could build a java.awt.image.BufferedImage,
create a Graphics2D from it, draw into it and then encode the
BufferedImage using the JPEG encoder in the com.sun.image.codec.jpeg
package.
You could also use SVGGraphics2D to generate SVG and then use
the transcoder to convert that to JPEG. I have attached an example that
does that.
There is documentation on the SVGGraphics2D:
http://xml.apache.org/batik/svggen.html
just be aware that the package has changed to org.apache.batik.svggen
since the documentation was done.
b. Our model.
We are working on documenting things more. I am not going to attempt
describing the whole thing, but in a nutshell, the DOM is our model
and the API through which the SVG graphics is manipulated. GVT is
a view of the model. Renderers can paint a GVT tree and the bridge
can build a GVT tree and 'hook it' to the DOM model.
If you want to help with the documentation effort, that would be very
helpful.
Cheers.
Vincent Hardy.
Ryan Marsh wrote:
>
> I was trying to get my head around the Batik code tonight and was
> attempting a simple excercise, I need a little direction. Basically I
> just want to use Batik to draw a rectangle, set the color of it to red,
> and either spit out the SVG or spit out a JPEG (or even better.. display
> it dynamically).
>
> It seemed to me (at first) that GVT is (the controller) what you guys
> used to modify the "model" (SVG or Graphics2D?). So I wanted to find out
> how to draw a rectangle using GVT so I started digging through the
> source for the rasterizer app. It seemed a good starting point because
> it reads in an SVG document and then builds graphics using GVT... but
> not so fast. Now something called the bridge comes into play. I started
> digging deeper and found that the magic occurs in ConcreteGVTBuilder
> which takes an svg doc and, node by node, generates a GVT tree? Which is
> directly translateable to Graphics2D? What does the translating, the
> bridge again? This is where I'm starting to get lost. I supposed there
> was some code somwhere that would look something like this:
>
> if rectangle
> draw graphics2D rectangle
> else if circle
> draw graphics2D circle
> etc...
>
> or something along those lines, and maybe something that works in
> reverse.
>
> So I guess my real question is:
> Which is the model, which is the controller, which is the view? Or am I
> even applying the right pattern? Please, set me straight or point me to
> some documentation I have yet to discover.
>
> Once again, congrats. The code looks really nice.
>
> > That sounds like a cool app. Keep us posted!
> >
>
> Sure will.
>
> > > - Would you suggest I wait around for JSVGCanvas or would I be better off
> > > rolling my own to start with?
> >
> > My suggestion is, wait for JSVGCanvas. The threading stuff is time
>
> I don't want anyone commiting to dates but do you have anyidea how far
> off in the future that is? Any ways I can help you get there faster?
>
> FYI: (though you may already know) The Java2D list has pretty good
> discussions. If you guys ever have Java2D problems there are some pretty
> talented people that respond on the list.
> JAVA2D-INTEREST@JAVA.SUN.COM
>
> Thanks,
> -ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org