[GRASS-dev] discussion: replacing ps.map

[Sören Gebbert]

Hi Glynn,
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?

     I need to stop the PS driver and restart it again to avoid rerendering.

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.

3.) I don't know how to tell the PS driver to use real colors, is there documentation available?
     eg.: g.manual -m psdriver

4.) I would love to see a doxygen documentation of the driver library,
     so i can understand how it works :)

5.) Is there a way to create eps output? This would be great, especially to use the created maps
     within other documents. (latex ...)

IMHO the psdriver is absolutely fantastic.
Thanks!

Best regards
Soeren

Glynn Clements schrieb:
> Jachym Cepicky wrote:
> 
>> hi,
>> tahanks for you answer
>>
>> 2007/4/6, Glynn Clements <glynn at gclements.plus.com>:
>>> J-Báchym Čepický wrote:-A
>>>
>>>> the PS driver works nice, thanks!
>>>>
>>>> What about d.text.freetype ? I wonder how complicated it would be to
>>>> implement too..?
>>> Huh?
>>>
>>> d.text.freetype should work with the PS driver, although it will
>>> rasterise the bitmaps at a resolution of 1 point, then embed the
>>> bitmaps.
>> d.mon PS
>> d.text.freetype font=luximr text="hallo, world" at=10,10
>> d.mon stop=PS
>>
>> gv map.ps
>>
>> document is not opend
> 
> Oops. There are a couple of bugs in the bitmap code.
> 
> The first is in the prolog; the string is allocated with one byte per
> pixel, when it should be one bit, causing too much data to be read.
> 
> 	Index: lib/psdriver/psdriver.ps
> 	===================================================================
> 	RCS file: /grassrepository/grass6/lib/psdriver/psdriver.ps,v
> 	retrieving revision 1.2
> 	diff -u -r1.2 psdriver.ps
> 	--- lib/psdriver/psdriver.ps	30 Mar 2007 06:29:35 -0000	1.2
> 	+++ lib/psdriver/psdriver.ps	6 Apr 2007 13:48:00 -0000
> 	@@ -39,7 +39,7 @@
> 	 /BITMAP {
> 	   gsave
> 	     4 2 roll translate
> 	-    1 index string /tmpstr exch def
> 	+    1 index 7 add 8 idiv string /tmpstr exch def
> 	     true [1 0 0 1 0 0] {currentfile tmpstr readhexstring pop} imagemask
> 	   grestore
> 	 } bind def
> 
> If you make this change to the map.ps file, the file should display,
> but you'll notice the second bug; the accumulator wasn't being
> cleared, resulting in "echoes":
> 
> 	Index: lib/psdriver/Draw_bitmap.c
> 	===================================================================
> 	RCS file: /grassrepository/grass6/lib/psdriver/Draw_bitmap.c,v
> 	retrieving revision 1.1
> 	diff -u -r1.1 Draw_bitmap.c
> 	--- lib/psdriver/Draw_bitmap.c	30 Mar 2007 04:51:23 -0000	1.1
> 	+++ lib/psdriver/Draw_bitmap.c	6 Apr 2007 13:48:00 -0000
> 	@@ -25,6 +25,7 @@
> 	 			{
> 	 				output("%02X", acc);
> 	 				bit = 0x80;
> 	+				acc = 0;
> 	 			}
> 	 		}
>  
> Both of these are fixed in CVS, and it appears to work.
> 
>> same for d.font && d.text
>>
>> What am I missing?
> 
> That I said "should work" rather than "does work" ;)
> 
> This time, I have actually tested it.
>