[GRASS-dev] discussion: replacing ps.map

[Sören Gebbert]

Glynn Clements schrieb:
> S-Bören Gebbert wrote:-A
> 
>> thanks a lot for your effort.
>> The PS driver is working great for me
>> and i have a couple of questions about it:
>>
>> 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps.
>>      Using the d.erase command after i have added raster or vector maps results in
>>      rerendering the "erased" content.
>>      Is there a way to reset the map.ps file to avoid rerendering of
>>      "old" maps after using d.erase?
> 
> Only ...
> 
>>      I need to stop the PS driver and restart it again to avoid rerendering.
> 
> ... like this.
> 
> The PS driver simply appends all output to $GRASS_PSFILE.
> 
> It could truncate the file (although that will only work for files,
> not pipes or e.g. /dev/stdout) upon erase, or it could close and
> re-open the file.
> 
> It's not entirely clear what the "correct" solution is.
> 
> Is there a reason why you might want to send graphics to the driver
> when you are subsequently going to erase them?

Well, i was expecting a similar behaviour like the XDRIVER.
Erasing the monitor to visualize new maps. In case of the PS driver
i'm using kghostview or gv as monitor.

> With the existing behaviour, the ERASE procedure can be redefined in
> the prolog ($GISBASE/etc/psdriver.ps) to do something else. E.g. it
> could call "showpage", so you could generate a multi-page file, using
> ERASE for page breaks.

That's interesting i will try this out.

> 
>> 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1.
>>      If i choose a larger line width, polylines are broken into pieces
>>      spearfish60 example:
>>      d.mon PS
>>      d.vect roads color=black width=4
>>      d.vect roads color=white width=1
>>      gv map.ps
>>
>>      Is there a way to avoid this? Well, i guess this is not an easy task.
> 
> Modify d.vect to generate polylines (R_polyline_abs()) rather than
> individual line segments (R_{move,cont}_abs()). Unlike the PNG driver,
> the PS driver implements polylines as a single stroked path. If you
> send it a polyline, you'll get joins (rather than caps) between the
> segments.
> 
> This is a good example of what I mean when I say that the main problem
> with implementing a PostScript driver is the way that modules use the
> graphics API.
> 
> Note that being able to change the line width is a relatively recent
> feature (2005/08/09). Back when lines were always single-pixel, there
> wasn't any difference between a polyline and lots of individual
> segments.
> 
> Also note that the PS driver cannot realistically convert move/cont
> operations into polylines, as a polyline has to be "stroke"d in a
> single operation.
> 
>> 3.) I don't know how to tell the PS driver to use real colors, is there documentation available?
>>      eg.: g.manual -m psdriver
> 
> "real" colours? As opposed to imaginary colours? ;)
> 
> If you're getting monochrome output, use:
> 
> 	export GRASS_TRUECOLOR=TRUE
> 
> to get colour PostScript.

Its working great!

> 
> I made monochrome the default because that results in the most
> portable code (a minimal level 1 PostScript implementation doesn't
> support colour).
> 
>> 4.) I would love to see a doxygen documentation of the driver library,
>>      so i can understand how it works :)
> 
> Regarding the graphics subsystem, documentation tends to become
> inaccurate faster than it gets written.

That hopefully does not mean that no documentation will be written at all. ;)

> 
>> 5.) Is there a way to create eps output? This would be great, especially to use the created maps
>>      within other documents. (latex ...)
> 
> Try ps2epsi (normally included with Ghostscript).
> 

That's the tool i need, thanks.

Soeren