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 "Frederich, Eric P21322" <er...@siemens.com> on 2007/10/22 21:20:20 UTC

need some suggestions

I am writing a program in Java.

In the end I need a program which will generate vector graphics.  This
program will need to save the graphics in SVG format as well as a
rasterized version.

These graphics need to be viewed in a standalone viewer which can pan
and zoom.  This viewer will need to update automatically when the
program is re-ran.

I am hoping that Batik can help me out with a lot of this but I'm having
some trouble making decisions.
What would be the best way for my program to generate these graphics?
Should I use a StringBuilder and keep adding my <rect />'s or should I
use a Document class?

On the viewer side, is it possible to get panning and zooming working
with a JSVGCanvas?  I haven't seen any examples of this.
And as for the viewer updating...Should the program that is generating
the graphics notify the viewer that the file has been updated through
RMI?  Should the viewer periodically check the filesystem?
Having an RMI client/server setup seems like overkill and checking the
filesystem every second seems like a bad idea too.
I've seen text editors that know when a file has been modified
externally.  Any ideas how they work?

Thanks for the help,
~Eric

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


RE: need some suggestions

Posted by "Frederich, Eric P21322" <er...@siemens.com>.
Thanks Thomas and Frederik.
Since I'm replying to both of you rather than picking one I'll just
reply to myself.

Someone reminded me that one of the editors I use checks for a new file
when the window regains focus.
So I did a couple of tests and it seems that it checks the filesystem
every 5 seconds or so while it had focus but checks instantly when it
gains focus.  I think I may implement something like that.  Plus maybe
listening for pings on a port like Thomas suggested.  If I have all
three of those things going it should be pretty smooth.

As for the JSVGCanvas are those keys customizable?
I'd like a middle drag to pan, a right drag up/down to zoom in/out, and
a left drag to do a box zoom.
Maybe a middle click to reset.
I'd try to get the same behavior as some of our other viewers we use
here.

Thanks again,
~Eric

> -----Original Message-----
> From: Frederich, Eric P21322 
> Sent: Monday, October 22, 2007 3:20 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: need some suggestions
> 
> I am writing a program in Java.
> 
> In the end I need a program which will generate vector graphics.  This
> program will need to save the graphics in SVG format as well as a
> rasterized version.
> 
> These graphics need to be viewed in a standalone viewer which can pan
> and zoom.  This viewer will need to update automatically when the
> program is re-ran.
> 
> I am hoping that Batik can help me out with a lot of this but 
> I'm having
> some trouble making decisions.
> What would be the best way for my program to generate these graphics?
> Should I use a StringBuilder and keep adding my <rect />'s or should I
> use a Document class?
> 
> On the viewer side, is it possible to get panning and zooming working
> with a JSVGCanvas?  I haven't seen any examples of this.
> And as for the viewer updating...Should the program that is generating
> the graphics notify the viewer that the file has been updated through
> RMI?  Should the viewer periodically check the filesystem?
> Having an RMI client/server setup seems like overkill and checking the
> filesystem every second seems like a bad idea too.
> I've seen text editors that know when a file has been modified
> externally.  Any ideas how they work?
> 
> Thanks for the help,
> ~Eric
> 
> ---------------------------------------------------------------------
> 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: need some suggestions

Posted by Frederik Elwert <fe...@uni-bremen.de>.
Am Montag, den 22.10.2007, 15:20 -0400 schrieb Frederich, Eric P21322:
> And as for the viewer updating...Should the program that is generating
> the graphics notify the viewer that the file has been updated through
> RMI?  Should the viewer periodically check the filesystem?
> Having an RMI client/server setup seems like overkill and checking the
> filesystem every second seems like a bad idea too.
> I've seen text editors that know when a file has been modified
> externally.  Any ideas how they work?

If you are targeting a Linux platform, you can probably make use of
inotify. With this, the kernel can notify your application when the file
has changed on disk.

Cheers,
Frederik


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


Re: need some suggestions

Posted by th...@kodak.com.
Hi Eric,

"Frederich, Eric P21322" <er...@siemens.com> wrote on 10/22/2007 
03:20:20 PM:

> In the end I need a program which will generate vector graphics.  This
> program will need to save the graphics in SVG format as well as a
> rasterized version.
> 
> These graphics need to be viewed in a standalone viewer which can pan
> and zoom.  This viewer will need to update automatically when the
> program is re-ran.
> 
> I am hoping that Batik can help me out with a lot of this but I'm having
> some trouble making decisions.
> What would be the best way for my program to generate these graphics?
> Should I use a StringBuilder and keep adding my <rect />'s or should I
> use a Document class?

   It's really up to you.  If you build the document directly then 
rasterizing it can skip the parsing phase (not that the parsing is
a particularly time consuming phase).  Also if you reach a point
where you need information about the geometry you are constructing
(the most common example is the bounding box of text) then you will
need to build it as a Document with the SVG DOM active.

   All in all I would lean towards building the Document but
without other constraints it's pretty much a wash between the two.

> On the viewer side, is it possible to get panning and zooming working
> with a JSVGCanvas?  I haven't seen any examples of this.

   This works out of the box, pan = "<shift> mouse-drag", 
zoom = "<ctrl> mouse-drag".

> And as for the viewer updating...Should the program that is generating
> the graphics notify the viewer that the file has been updated through
> RMI?  Should the viewer periodically check the filesystem?

   If everything is local I would have the viewer listen on a port and
have the generator connect to that port and ping the server.  This is
sort of a 'poor mans' version of your RMI example, but it should be
_much_ simpler to code (it's like 10 lines of Java).

   BTW the update will be _much_ cleaner if you actually identify the
elements that change vs reloading the document from scratch (AJAX like
approach).  Since your 'generator' program generates the document from
scratch each time I don't know how easy/hard that might be.

> Having an RMI client/server setup seems like overkill and checking the
> filesystem every second seems like a bad idea too.

   I agree the RMI is likely overkill for this.  Pinging the 
filesystem every second is ugly but should actually work just 
fine.

> I've seen text editors that know when a file has been modified
> externally.  Any ideas how they work?

   As Fredrick mentioned some filesystems/OS enable applications 
to register to be notified when files change on disk.  I don't
know if there is a Java version of this.