[GRASS-dev] ps.map consolidation

roger at spinn.net roger at spinn.net
Fri Mar 2 17:25:06 EST 2007


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




More information about the grass-dev mailing list