Re: [JPP-Devel] SVGConvertable Inteface...
Martin wrote: "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." I understand this point now Martin. I will give some thought to what design pattern might help me externalize the conversion code. Jan wrote; "not sure whether you tried it yet. With PrintLayoutPlugin you can export to SVG and directly load it in InkScape (you need a current version). Worked pretty well over here. At least the code might provide some insights?" Thanks Jan. I've been meaning to work some more with your printing plug-in. I'm interested to see how it plays with Inkscape! Sascha wrote: "I've a lot of ideas how to do it right and I'm willing to assist you if you _really_ work on this topic. Don't get me wrong, but I'm under the impression that you 'spread' out your work focus to some extend. ;-)" I'm afraid that is a reputation I've earned. :[ I don't want to make any commitments to you right now, as I'd like to change this and earn a reputation as someone who gets things done. :] If I am able to proceed with my work on the free form labels I'll let the list now. If you are still willing we could work together at that time. This won't be for a couple of months yet, as I only have a couple of hours a week to code and I'm trying to track down a bug in my pluggable rendering system code. I was really just bouncing some ideas off of the mailing list. All of the feedback has been great. The Sunburned Surveyor On 5/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi together, > > The Print/Layout Plug-in is based on SVG exactly > for the reason of being used in a tool chain. > > It would be of great to have an API that eases the > SVG conversion process. > I've a lot of ideas how to do it right and I'm > willing to assist you if you _really_ work on this topic. > Don't get me wrong, but I'm under the impression > that you 'spread' out your work focus to some extend. ;-) > > Greets, Sascha > > Sunburned Surveyor schrieb: > > 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
Re: [JPP-Devel] SVGConvertable Inteface...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi together, The Print/Layout Plug-in is based on SVG exactly for the reason of being used in a tool chain. It would be of great to have an API that eases the SVG conversion process. I've a lot of ideas how to do it right and I'm willing to assist you if you _really_ work on this topic. Don't get me wrong, but I'm under the impression that you 'spread' out your work focus to some extend. ;-) Greets, Sascha Sunburned Surveyor schrieb: > 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 "" 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 th
Re: [JPP-Devel] SVGConvertable Inteface...
On Tuesday 15 May 2007 20:45, 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. not sure whether you tried it yet. With PrintLayoutPlugin you can export to SVG and directly load it in InkScape (you need a current version). Worked pretty well over here. At least the code might provide some insights? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner - 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
Re: [JPP-Devel] SVGConvertable Inteface...
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 "" 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
Re: [JPP-Devel] SVGConvertable Inteface...
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 "" 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 >
Re: [JPP-Devel] SVGConvertable Inteface...
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
[JPP-Devel] SVGConvertable Inteface...
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.) 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? 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
