Ok, this all makes more sense to me now. The question of whether to put the rendering code in the layer or in separate classes is a classic OO conundrum. The problem is if you add another kind of rendering format (say MDVG... 8^) you then have to add yet another set of interfaces and methods on the various kinds of layers. Better to make the rendering class a sort of Decorator or Visitor or Strategy, I think (I'm sure there's GOF pattern for this somewhere...)
Like I say, you're going to want to put all that custom rendering code in a class inside each Layer method anyway - so might as well move it outside where it's more flexible. Sunburned Surveyor wrote: > Martin, > > Please see my comments below. > > Martin wrote: "Yeah... this is one way to approach it. But JUMP > Layers and Features > contains a lot of structured data and metadata which probably isn't > available to you once you've crunched everything into Inkscape (they are > totally different data models, aren't they?) So that means that in > order to drive your rendering from this information, you need to do it > where you have access to this information - ie. inside JUMP. (For > example, think about rendering based on attribute...)" > > I understand this point. Thank you for bringing it out. > > Martin wrote: "I can see using Inkscape to *add to* an image generated > from JUMP." > > This is exactly what I was talking about! I imagine that a person > would do 95% of their work in OpenJUMP, and when they are ready to > produce a map for printing they would export their data into SVG, open > it is Inkscape, and add the finishing artistic touches there. > (Actually I's use Inkscape and Scribus to produce the final map.) > > Martin wrote: " would modularize the SVG "conversion" (really > rendering) code out into a separate class. You're going to end up > doing that anyway inside your > Layer class (to prevent the code from getting totally bloated). So > split it out and give it a nice API, and you have much better > modularity. Think separation of concerns." > > Are you saying I should make the SVGConverter a class and not an > interface? This would work, but I would imagine each implementation of > Layerable would need a SVGConverter class with custom conversion code. > For example: You'd need one set of conversion logic for image layers, > another for regular vector layers, and another for my label layers. > > I suppose we could do this by creating an abstract SVGConverter class. > Is this what you had in mind? > > Martin wrote: "Anyway, isn't there a bigger use case involving > combining several layers into one SVG drawing? The usual way to do > this is to simply take all > the visible Layers in a Task and render them, driving the rendering off > the symbology already on the Layers. If there is special rendering that > can be performed (say something like your labels), this can be driven > off "special" attributes that the renderer recognizes." > > Sometimes I don't do a very good job of explaining myself. This is the > process I was trying to describe. > > I imagine things would work like this: > > The user would select a set of layers that they wanted to export to a > single SVG file and would select the "Export to SVG" command. OpenJUMP > would pass each of the selected layers to the SVGConverterTool object. > This object would call the "convertToSVG" method on each of the > selected layers that implemented the SVGConvertable interface. It > would take the String returned by this method, which contains the SVG > representation of the layer's contents and would add or append it to a > text file containing all of the svg content. > > The end result would be a single text file with the SVG content for > all of the selected layers that supported conversion to SVG. The > conversion logic would be left to the developers implementing the > Layerable interface. > > We could even use the "<group>" elements in SVG to create layers in > Inkscape that corresponded to the layers in OpenJUMP. > > The Sunburned Surveyor > > On 5/15/07, Martin Davis <[EMAIL PROTECTED]> wrote: > >> Sunburned Surveyor wrote: >> >>> I wanted to share some quick thoughts about SVG support in OpenJUMP. >>> I'm a big fan of Inkscape and I think it has the potential to be a >>> great tool for cartographic map design. >>> >>> Why develop a lot of cartographic design or art tools for OpenJUMP >>> when Inkscape already has a great deal of momentum? (This isn't meant >>> to detract from the great printing plug-ins that have developed in the >>> last few months.) >>> >>> >> Yeah... this is one way to approach it. But JUMP Layers and Features >> contains a lot of structured data and metadata which probably isn't >> available to you once you've crunched everything into Inkscape (they are >> totally different data models, aren't they?) So that means that in >> order to drive your rendering from this information, you need to do it >> where you have access to this information - ie. inside JUMP. (For >> example, think about rendering based on attribute...) >> >> I can see using Inkscape to *add to* an image generated from JUMP. >> >>> I want to post about this on my blog, but haven't had time yet. >>> >>> At any rate I started helping with the lib2geom effort a little bit, >>> in an effort to contribute to Inkscape's development. (lib2geopm will >>> be the new geometry library for Inkscape.) Working with C++ has made >>> me realize the true beauty of Java! >>> >>> I thought one good way to add support for SVG export in OpenJUMP would >>> be to create a SVGConvertable interface with at least one method. The >>> method signature would look something like: >>> >>> public String convertToSVG(Layerable argToConvert) >>> >>> The method would accept a Layerable object and would return a String >>> object with the SVG representation of the Layerable. >>> >>> I could then implement this interface in my class that extends the >>> Layer class and stores text labels. >>> >>> This interface would allow a SVGExporter utility to determine which >>> layers support conversion to SVG and would allow this conversion >>> without the messy details of dealing with custom Layerable objects. >>> >>> What do you guys think? >>> >>> >> I would modularize the SVG "conversion" (really rendering) code out into >> a separate class. You're going to end up doing that anyway inside your >> Layer class (to prevent the code from getting totally bloated). So >> split it out and give it a nice API, and you have much better >> modularity. Think separation of concerns. >> >> Anyway, isn't there a bigger use case involving combining several layers >> into one SVG drawing? The usual way to do this is to simply take all >> the visible Layers in a Task and render them, driving the rendering off >> the symbology already on the Layers. If there is special rendering that >> can be performed (say something like your labels), this can be driven >> off "special" attributes that the renderer recognizes. >> >> My 2c worth >> >>> The Sunburned Surveyor >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
