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

Glynn Clements glynn at gclements.plus.com
Wed Sep 5 11:18:36 EDT 2007


Michael Barton wrote:

> >> 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).
> 
> Will this also work on wingrass? Is there an equivalent command?

No. On Windows, printing works by using GDI functions on a
"printer DC".

There are probably file formats which can be printed using a "bare"
Windows installation, but they're likely to be Windows-specific (e.g. 
WMF).

wxGRASS can do this for its own content using wx.PrinterDC. But:

1. The output from d.* commands used by wxGRASS will have been
pre-rendered at screen resolution, so sending that to a printer is
going to produce substantially inferior results compared to using the
PS driver.

2. Having important functionality only available via the GUI isn't
acceptable.

> > 2. Invokes gs with DEVICE set to a user-defined string. [This one
> > looks wrong; it doesn't appear to send the output anywhere.]
> 
> Any idea what's wrong with it? It hasn't worked correctly for me, but I
> always blamed that on my Mac environment.

What's wrong is it doesn't specify -sOutputFile=, so the output goes
to stdout. As the return value from the "exec gs ..." isn't actually
used, it just gets discarded.

Note that -sDEVICE= simply specifies the format; it doesn't refer to a
"device" in the sense of a specific printer. If you actually want to
print, you need to pipe the output into "lpr".

But that assumes that the "printer" which lpr uses actually accepts
the printer's native data format. Most Unix systems handle
non-PostScript printers by creating a printcap entry which uses
Ghostscript as a filter, so the printer "appears" as a PostScript
printer insofar as you can feed PostScript to lpr and have it come out
right on the printer.

IOW, the lpr setup handles the conversion from PostScript to the
printer's native format, not the application.

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




More information about the grass-user mailing list