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
