Hi Eric, "Frederich, Eric P21322" <[EMAIL PROTECTED]> 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.
