Re: [GRASS-dev] numeric-numpy-scipy for graphs?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Michael Barton
Thanks Hamish,

In fact, we can do considerably more now with the wxPython (and TclTk)
drawing commands to than is available in d.graph or d.linegraph, even with
your nice enhancements.

In the case of histogramming and profiling, it seems a better display to
have them come up in a separate window (like is now the case with the TclTk
profiling module) than have them rendered like a map in the main display
(like we do now for d.histogram in the current TclTk GUI). Rendering maps is
complex and it doesn't seem efficient to have to go through the same complex
procedures to draw a histogram or profile that doesn't need to be drawn
georeferenced.

For this reason, it seems better to do these kinds of analyses with the gui
tools, using underlying GRASS modules like r.profile and r.stats.

Michael


On 4/22/07 2:54 AM, "Hamish" <[hidden email]> wrote:

> Michael Barton wrote:
>> We need to create a graph/plot for at least 2 functions in the wxgrass
>> GUIĀ‹profile plotting and histogramming. I did the TclTk profile module
>> with just standard graphic calls. However, wxPython has a very nice
>> plot control:PyPlot. It has lots of nice options, including ways to
>> save the plot easily.
>
> maybe you are looking for something more advanced, but can it be done
> with d.graph and/or d.linegraph? I've never actually used d.linegraph,
> but would be willing to help bring it up to speed if it is useful but
> for a few small rendering issues.
>
>
> Hamish
>
>

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Glynn Clements

Michael Barton wrote:

> In fact, we can do considerably more now with the wxPython (and TclTk)
> drawing commands to than is available in d.graph or d.linegraph, even with
> your nice enhancements.
>
> In the case of histogramming and profiling, it seems a better display to
> have them come up in a separate window (like is now the case with the TclTk
> profiling module) than have them rendered like a map in the main display
> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is
> complex and it doesn't seem efficient to have to go through the same complex
> procedures to draw a histogram or profile that doesn't need to be drawn
> georeferenced.
>
> For this reason, it seems better to do these kinds of analyses with the gui
> tools, using underlying GRASS modules like r.profile and r.stats.

Even if you decide not to use the existing graphics API, I would still
suggest that any functionality which could reasonably be used
non-interactively can be.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Michael Barton
I agree that these functions should be maintained and even enhanced,
especially for scripting.

Michael


On 4/22/07 11:41 AM, "Glynn Clements" <[hidden email]> wrote:

>
> Michael Barton wrote:
>
>> In fact, we can do considerably more now with the wxPython (and TclTk)
>> drawing commands to than is available in d.graph or d.linegraph, even with
>> your nice enhancements.
>>
>> In the case of histogramming and profiling, it seems a better display to
>> have them come up in a separate window (like is now the case with the TclTk
>> profiling module) than have them rendered like a map in the main display
>> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is
>> complex and it doesn't seem efficient to have to go through the same complex
>> procedures to draw a histogram or profile that doesn't need to be drawn
>> georeferenced.
>>
>> For this reason, it seems better to do these kinds of analyses with the gui
>> tools, using underlying GRASS modules like r.profile and r.stats.
>
> Even if you decide not to use the existing graphics API, I would still
> suggest that any functionality which could reasonably be used
> non-interactively can be.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Trevor Wiens
On Sun, 22 Apr 2007 11:44:34 -0700
Michael Barton wrote:

> I agree that these functions should be maintained and even enhanced,
> especially for scripting.
>

As discussed a long time ago on the list, there is no reason why a
wrapper function couldn't be created in python to make calls to the GUI
from the command line, to allow for scripted control of the GUI using
sockets (not Unix specific ones). One socket could be listened to by
the GUI and the command line wrapper would simply pass calls to that
socket thus allowing CLI access. I had planned to develop this myself,
but being up to my ass in alligators (figuratively speaking) I've not
had the time.

If there is good functionality available through wxGRASS, why maintain
another version of a similar function. It could be argued that some
users would prefer to avoid the overhead of a GUI, but for them, there
are older versions of GRASS. AFAIC duplication is a bad thing. In
the similar vein to Python, there should be one obvious way to do
things. GRASS is already so big, we don't need more duplication.

So I would vote for inclusion of scipy for graphing and planning the
obsolescence of the older means.

T
--
Trevor Wiens
[hidden email]

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Glynn Clements

Trevor Wiens wrote:

> > I agree that these functions should be maintained and even enhanced,
> > especially for scripting.
>
> As discussed a long time ago on the list, there is no reason why a
> wrapper function couldn't be created in python to make calls to the GUI
> from the command line, to allow for scripted control of the GUI using
> sockets (not Unix specific ones). One socket could be listened to by
> the GUI and the command line wrapper would simply pass calls to that
> socket thus allowing CLI access. I had planned to develop this myself,
> but being up to my ass in alligators (figuratively speaking) I've not
> had the time.

Being able to remote-control the GUI is a separate issue.

Functionality (including creating graphics) should be available in an
environment where you cannot create a window (no X server, no X libs).

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Trevor Wiens
On Sun, 22 Apr 2007 21:31:49 +0100
Glynn Clements wrote:

>
> Trevor Wiens wrote:
>
> > > I agree that these functions should be maintained and even enhanced,
> > > especially for scripting.
> >
> > As discussed a long time ago on the list, there is no reason why a
> > wrapper function couldn't be created in python to make calls to the GUI
> > from the command line, to allow for scripted control of the GUI using
> > sockets (not Unix specific ones). One socket could be listened to by
> > the GUI and the command line wrapper would simply pass calls to that
> > socket thus allowing CLI access. I had planned to develop this myself,
> > but being up to my ass in alligators (figuratively speaking) I've not
> > had the time.
>
> Being able to remote-control the GUI is a separate issue.
>
> Functionality (including creating graphics) should be available in an
> environment where you cannot create a window (no X server, no X libs).

In that case why not allow users to export their data to R and use that
or pipe to another graph producing package like ploticus (which I've
used extensively and found to be excellent as it includes CMYK
eps output options, and much better than any other of the products
suggested in this discussion so far IMHO). Neither of these solutions
would require as much work as maintaining duplicate modules which
produce lower quality results. Yes, it is an additional dependency, but
a general management rule states one should manage for the majority and
treat special cases individually. I would expect that the majority of
users use GRASS in a windowing environment, so we are talking about a
very small portion of the user base, no?

Another option would be to use a single solution that can be used in
all cases. If this were to be the case I would vote for serious
consideration being given to ploticus. FYI, Steve Grubb also has a
small postscript library which supports CMYK, which we might want to
look at using to enhance the ps output options with the d.* modules.

I'm not trying to make things complicated, but I'm trying to make sure
we don't waste effort recreating things that already exist and good.

One of my current projects is producing a book on birds for which I
produced almost 600 graphs as CMYK eps files. Matplotlib couldn't do it.
GnuPlot sucks IMHO. PyX was as user friendly as a poke in the eye,
although the list people were very nice. I was able to do what I needed
with ploticus within half a day of looking at it and could continue to
customize it as needed. It may appear a bit old fashioned compared to
some of the Python plotting products, but it is easily understood,
provides fine control when needed, and produces output in a variety of
formats. No GUI required. If we wrote wrapper to use it, the output
could be displayed in a separate window or written to file.

T
--
Trevor Wiens
[hidden email]

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Moritz Lennert
In reply to this post by Glynn Clements
On Sun, April 22, 2007 22:31, Glynn Clements wrote:

>
> Trevor Wiens wrote:
>
>> > I agree that these functions should be maintained and even enhanced,
>> > especially for scripting.
>>
>> As discussed a long time ago on the list, there is no reason why a
>> wrapper function couldn't be created in python to make calls to the GUI
>> from the command line, to allow for scripted control of the GUI using
>> sockets (not Unix specific ones). One socket could be listened to by
>> the GUI and the command line wrapper would simply pass calls to that
>> socket thus allowing CLI access. I had planned to develop this myself,
>> but being up to my ass in alligators (figuratively speaking) I've not
>> had the time.
>
> Being able to remote-control the GUI is a separate issue.
>
> Functionality (including creating graphics) should be available in an
> environment where you cannot create a window (no X server, no X libs).

+1

Moritz

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Glynn Clements
In reply to this post by Michael Barton

Paul Kelly wrote:

> > In fact, we can do considerably more now with the wxPython (and TclTk)
> > drawing commands to than is available in d.graph or d.linegraph, even with
> > your nice enhancements.
> >
> > In the case of histogramming and profiling, it seems a better display to
> > have them come up in a separate window (like is now the case with the TclTk
> > profiling module) than have them rendered like a map in the main display
> > (like we do now for d.histogram in the current TclTk GUI). Rendering maps is
> > complex and it doesn't seem efficient to have to go through the same complex
> > procedures to draw a histogram or profile that doesn't need to be drawn
> > georeferenced.
>
> Another thought - with the enhancements to the display architecture in
> progress/idea stage

Idea, currently. I need to introduce non-trivial API breakage in order
to go much further. Mainly, switching to floating-point coordinates
and adding begin/end operations to the move/cont and raster
primitives.

> it might actually be possible to produce better
> quality graphs for inclusion in reports/papers etc. using the existing
> display architecture. I'm thinking of the move towards PostScript as a
> display output format.

Certainly, I want (decent) PostScript output to at least be an option.

The main question is whether we can abandon other formats, i.e.
whether modules can rely upon being able to use the full feature set
(e.g. arbitrary clip paths, rotation/scaling of all output, pattern
fills etc), or whether they will be limited to a common-denominator
subset.

> I imagine with pop-up Windows in the GUI with
> histograms etc. you would be limited to printing the thing as a raster
> graphic at the same resolution as the screen?

Not quite. I'm assuming that lines, polygons etc wouldn't be
rasterised when using a print DC, but you're still stuck with
coordinates on integer boundaries (and a fairly primitive API).

This is one of the main distinctions between an "ideal" graphics API
(PostScript, OpenGL) and an "adequate for GUI use" API (X11, Windows
GDI).

[FWIW, the wx API is heavily based upon Windows' GDI, which hasn't
really changed much since Windows 1.0.]

> Not so good. Unless those
> new python modules you're looking at perhaps have an option to save as
> postscript (I mean proper line-graphics postscript) for printing.

wx has PostScriptDC and PrinterDC, which allow you to use the same
code as for drawing on a screen DC. Not all operations will work on
such contexts, e.g. you can't use raster ops (XOR-plotting etc) in
PostScript. And you're still limited to the standard DC methods, e.g.
no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X).

> And of
> course if you use GRASS modules to produce the graphs then as Glynn says
> it is also possible to produce them from scripts, which is rather
> important. (Rather than having all this functionality tied up in the GUI
> and having to re-implement it if we change the GUI).
>
> > For this reason, it seems better to do these kinds of analyses with the gui
> > tools, using underlying GRASS modules like r.profile and r.stats.
>
> I agree it "seemed" better/tidier/neater to me at first, but if we
> consider the display architecture is being enhanced beyond it's old
> clunky state it may not be as logical is it first seemed?

+1 ;)

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Michael Barton
A couple thoughts to add to the good discussion below.

Using native GUI graphics can make for much nicer output. Look at the TclTk
text layer in the current GUI. I is the only thing that currently outputs in
postscript/eps. The best example is the thematic vector legend.

OTOH, if a nice GRASS plotting routine could serve the relatively simple GIS
needs, I've been rethinking on how I could do it in wxPython without having
to go through the kind of complex rendering system. Using a single line
GRASS command like d.histogram is a lot easier than having to program
graphic primitives with data from r.stat--even if I can use the wxPython
plot routine. It simply needs to go to a PNG file and be picked up again by
a display window. No need to worry about georeferencing. The one
complication is changing window size. The GRASS command would need to be
rerun and the graphic rendered. With the new PS driver, we might not be
stuck with a rasterized version. The fonts are still ugly (to me at least)
and remain difficult to change. But maybe recent changes have improved this.

If writing C code for simple native GRASS plotting is as straightforward as
Glynn suggests, it might be worth a look. d.histogram already can render to
a graphics file that can be displayed in a canvas. An equivalent
(non-interactive) d.profile does not exist (perhaps a flag added to
r.profile?) I haven't looked at d.graph closely since Hamish upgraded it,
but will do so.

Michael


On 4/23/07 2:31 AM, "Glynn Clements" <[hidden email]> wrote:

>
> Paul Kelly wrote:
>
>>> In fact, we can do considerably more now with the wxPython (and TclTk)
>>> drawing commands to than is available in d.graph or d.linegraph, even with
>>> your nice enhancements.
>>>
>>> In the case of histogramming and profiling, it seems a better display to
>>> have them come up in a separate window (like is now the case with the TclTk
>>> profiling module) than have them rendered like a map in the main display
>>> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is
>>> complex and it doesn't seem efficient to have to go through the same complex
>>> procedures to draw a histogram or profile that doesn't need to be drawn
>>> georeferenced.
>>
>> Another thought - with the enhancements to the display architecture in
>> progress/idea stage
>
> Idea, currently. I need to introduce non-trivial API breakage in order
> to go much further. Mainly, switching to floating-point coordinates
> and adding begin/end operations to the move/cont and raster
> primitives.
>
>> it might actually be possible to produce better
>> quality graphs for inclusion in reports/papers etc. using the existing
>> display architecture. I'm thinking of the move towards PostScript as a
>> display output format.
>
> Certainly, I want (decent) PostScript output to at least be an option.
>
> The main question is whether we can abandon other formats, i.e.
> whether modules can rely upon being able to use the full feature set
> (e.g. arbitrary clip paths, rotation/scaling of all output, pattern
> fills etc), or whether they will be limited to a common-denominator
> subset.
>
>> I imagine with pop-up Windows in the GUI with
>> histograms etc. you would be limited to printing the thing as a raster
>> graphic at the same resolution as the screen?
>
> Not quite. I'm assuming that lines, polygons etc wouldn't be
> rasterised when using a print DC, but you're still stuck with
> coordinates on integer boundaries (and a fairly primitive API).
>
> This is one of the main distinctions between an "ideal" graphics API
> (PostScript, OpenGL) and an "adequate for GUI use" API (X11, Windows
> GDI).
>
> [FWIW, the wx API is heavily based upon Windows' GDI, which hasn't
> really changed much since Windows 1.0.]
>
>> Not so good. Unless those
>> new python modules you're looking at perhaps have an option to save as
>> postscript (I mean proper line-graphics postscript) for printing.
>
> wx has PostScriptDC and PrinterDC, which allow you to use the same
> code as for drawing on a screen DC. Not all operations will work on
> such contexts, e.g. you can't use raster ops (XOR-plotting etc) in
> PostScript. And you're still limited to the standard DC methods, e.g.
> no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X).
>
>> And of
>> course if you use GRASS modules to produce the graphs then as Glynn says
>> it is also possible to produce them from scripts, which is rather
>> important. (Rather than having all this functionality tied up in the GUI
>> and having to re-implement it if we change the GUI).
>>
>>> For this reason, it seems better to do these kinds of analyses with the gui
>>> tools, using underlying GRASS modules like r.profile and r.stats.
>>
>> I agree it "seemed" better/tidier/neater to me at first, but if we
>> consider the display architecture is being enhanced beyond it's old
>> clunky state it may not be as logical is it first seemed?
>
> +1 ;)

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Glynn Clements

Michael Barton wrote:

> A couple thoughts to add to the good discussion below.
>
> Using native GUI graphics can make for much nicer output. Look at the TclTk
> text layer in the current GUI. I is the only thing that currently outputs in
> postscript/eps.

Are you comparing it to stroke fonts or TrueType fonts?

I'm well aware that the stroke fonts are rather ugly; they're
maintained because they're guaranteed to work on all drivers and the
same set of fonts is always available.

If you use TrueType fonts, there's no reason why the quality should be
any worse than Tk's own text items, and may be better (d.text[.new]
and the PNG driver will generate anti-aliased output).

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Michael Barton
In reply to this post by Michael Barton



On 4/23/07 10:50 PM, "Hamish" <[hidden email]> wrote:

>> d.histogram already can render to a graphics file that can be
>> displayed in a canvas. An equivalent (non-interactive) d.profile does
>> not exist (perhaps a flag added to r.profile?)
>
> I don't fully understand your idea, but if you are getting at what I
> think you are getting at, I'm a bit doubtful that it should be in
> r.profile. (better use a wrapper script that calls r.profile)

d.histogram can be run non-interactively. This makes is possible to have it
draw to a PNG and popup in a window. d.profile cannot be run interactively.
So without some kind of modification (to d.profile or r.profile) the only
recourse is to draw the profile in the GUI, like in the TclTk one.

>
> IMO GRASS 5 d.profile and d.histogram are too ugly to live. I welcome
> GUI replacements for them both.

No disagreement from me about the need for better versions of both. I don't
mind doing this in the GUI. But if we can have nice C versions that can be
called from a script or displayed in the GUI, that's OK too.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Michael Barton
In reply to this post by Michael Barton
Actually, as you mentioned earlier, d.linegraph has the beginnings of the
tools needed to do both profile and histogram. I haven't tried it in ages,
but might take a look at what it looks like.

Michael


On 4/23/07 10:50 PM, "Hamish" <[hidden email]> wrote:

>> If writing C code for simple native GRASS plotting is as
>> straightforward as Glynn suggests, it might be worth a look.
>
> If following that path, prototype what you want to do with d.graph
> first. Translating from that into C is pretty easy.
>

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Glynn Clements
In reply to this post by Michael Barton

Hamish wrote:

> > The one complication is changing window size. The GRASS command would
> > need to be rerun and the graphic rendered. With the new PS driver, we
> > might not be stuck with a rasterized version.
>
> just to throw something else out there: What if we had a SVG driver?
>   http://en.wikipedia.org/wiki/Svg

SVG is a viable alternative to PostScript.

As it's orientated towards video graphics rather than hardcopy, it
provides some features which PostScript doesn't. OTOH, some of those
features (e.g. translucency) can't be realised in hardcopy (other than
by rasterising everything and printing the resulting image, which
effectively means lower resolution).

My main concern with SVG is whether it is sufficiently mature.

The "mismatch" with hardcopy output isn't critical; a lot of systems
offer a single interface for both video and hardcopy graphics, with
certain operations being documented as not working for hardcopy.

OTOH, even if it isn't critical, it may still be an issue. The main
risk is that some people may simply forget about hardcopy and end up
introducing gratuitous "video-only" restrictions.

> very rough idea:
> If window bounds are the same, maybe it is easier to render raster maps
> in the PNG driver and vector maps & decorations in the SVG driver before
> combining with g.pnmcomp?

I was thinking that might be worthwhile allowing display modules to
choose between two API "levels". The basic level would allow the use
of the current set of operations using the existing PNG driver code.
The advanced level would allow more operations, including the ability
to output arbitrary PostScript (or SVG if that was chosen).

Modules which use the advanced level would always generate
PostScript/SVG; if image output was selected, the graphics library
would automatically invoke the renderer to generate the image.

Modules which use the basic level would still generate PostScript/SVG
if that output format was selected, or if "quality" (rather than
"draft") output was selected, but would use the existing renderer for
"draft" image output.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] numeric-numpy-scipy for graphs?

Brad Douglas
On Tue, 2007-04-24 at 19:50 +0100, Glynn Clements wrote:

> Hamish wrote:
>
> > > The one complication is changing window size. The GRASS command would
> > > need to be rerun and the graphic rendered. With the new PS driver, we
> > > might not be stuck with a rasterized version.
> >
> > just to throw something else out there: What if we had a SVG driver?
> >   http://en.wikipedia.org/wiki/Svg
>
> SVG is a viable alternative to PostScript.
>
> As it's orientated towards video graphics rather than hardcopy, it
> provides some features which PostScript doesn't. OTOH, some of those
> features (e.g. translucency) can't be realised in hardcopy (other than
> by rasterising everything and printing the resulting image, which
> effectively means lower resolution).
>
> My main concern with SVG is whether it is sufficiently mature.

Last I checked, PS is used by virtually every GIS company in existence.
I don't believe SVG is going to be any advantage over PS for those of us
who print posters, etc.  No reason to reinvent a perfectly functioning
wheel...we could use a few more PS enhancements (transparency
immediately comes to mind), however.

Most of us paid heavily for that PS support and extra memory on our
printer/plotters.  Might as well get some use out of them. ;-)


--
Brad Douglas <rez touchofmadness com>                    KB8UYR/6
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui