[GRASS-dev] ps.map consolidation

[Michael Barton]

In order to better create backgrounds in v.digit from the GUI, I added a new
global variable, named "commandlist" to the TclTk code. Commandlist stores a
TclTk list of the commands needed to create the current display. It is
updated every time the display is updated. Thinking about it, I may need to
index it by display, like many other variables.

However, this could be used for a variety of other uses, including being
parsed to create a ps.map command file.

Michael


On 3/2/07 3:25 PM, "roger at spinn.net" <roger at spinn.net> wrote:

> 
> I have a rudimentary GUI for ps.map written as a TCL/TK script.  It works by
> reading the content of the monitor and using that content to construct a
> basic input file for ps.map.  The GUI (which, as I said is pretty
> rudimentary) allows the user to view and edit instructions in the input
> file, to insert elements like eps files and to use options like line styles
> that aren't supported on the GRASS monitor.  It uses xpdf a previewer.  xpdf
> is fairly fast and has a remote server mode that allows the user to update
> the preview without restarting the viewer.  It is distributed under the GNU
> public license by Glyph and Cog, LLC ; http://www.foolabs.com/xpdf/home.html
> 
> The grass developers may not want to introduce a dependency on xpdf, but I
> encourage you to do something to give ps.map a friendlier front end.  The
> benefit is tremendous.  Having even a simple interactive ability to develop
> better graphics within the grass environment improved the quality of my
> products and decreased the time necessary to produce them.
> 
> 
> Roger Miller 
> 
> Glynn Clements writes:
> 
>> 
>> J-B�chym �epick� wrote:-A
>> 
>>> another point: How to write GUI for ps.map, so it is usable for the
>>> user. Several approaches are possible:
>>> 
>>> Drawing boxes for legend, measure, text and so on, so the user has at
>>> least idea about where and how the object will be placed on the paper.
>>> 
>>> Another sollution would be, if we would copy the map display approach:
>>> render separate layer for each map instruction in the temporary file
>>> and put them together in the map display. User could than take a mouse
>>> and position each object interactively.
>>> 
>>> We would need support of transparency for this... Does ps.map support
>>> creation of transparent files?
>> 
>> ps.map creates PostScript files. If you use Ghostscript's "pngalpha"
>> driver, the resulting PNG file will have a transparent background. But
>> then you would need to convert the PNG files to PPM/PGM (that's all
>> that g.pnmcomp understands), and you would need to manually
>> re-composite those files whenever the relative position changes.
>> 
>> Personally, I don't see the point in a ps.map GUI; this task is better
>> suited to general-purpose DTP software.
>> 
>> -- 
>> Glynn Clements <glynn at gclements.plus.com>
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> 

__________________________________________
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