[GRASS-user] need help with mac os x installation

[Glynn Clements]

William Kyngesburye wrote:

> > Yea. TclTk (at least the packages we use) doesn't have any good built in
> > printing routines. I wrote one that is included in the GUI, but it needs
> > ghostscript to translate from the native postscript of the canvas  
> > into print output.

On Unix, "print output" traditionally *is* PostScript.

The backbone of most Unix printing setups is the use of Ghostscript to
make your printer look like a PostScript printer. If you happen to
have an actual PostScript printer, the Ghostscript step is omitted.

There's no need for gis.m to invoke Ghostscript itself when printing;
it can just feed PostScript to "lpr" (with CUPS, you can feed a lot of
other formats, but PostScript is the one format which is likely to be
accepted on non-CUPS systems).

Moreover, using gs to render to an image format then sending the image
to lpr will invariably produce worse results than letting the printing
system perform the rendering (or sending the data directly to a
PostScript printer).

> I got to thinking about the GS license (it's GPL now) and I'll either  
> have to make it a separate download or find an existing Mac binary,  
> or maybe use an older AFPL GS.  Maybe there's an equivalent in the  
> system somewhere - it already uses CUPS for printing, maybe there's a  
> CLI postscript renderer...

"lpr file.ps" should work.

> Is your GUI printing use of GS the only thing in GRASS that uses it?   
> Does it generate an image, or print-ready postscript?

Looking at mapprint.tcl, it either:

1. Generates an image and sends it to "lpr". (CUPS will first convert
this to PostScript, then either invoke Ghostscript to convert it to
the printer's raw image format or send it directly to a PostScript
printer).

2. Invokes gs with DEVICE set to a user-defined string. [This one
looks wrong; it doesn't appear to send the output anywhere.]

3. Generate a PDF.

-- 
Glynn Clements <glynn at gclements.plus.com>