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
