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 pat
-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 yo
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
yo
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 o
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, ar
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 al
