[GRASS-dev] d.out.file now talks to the PostScript driver

[Glynn Clements]

Hamish wrote:

> > > Small observation: the barscale font color is grey in the resulting
> > > PS file while black in PNG (at least for my eyes).
> Glynn:
> > If you're using GV, try turning of anti-aliasing.
> 
> See attached. Turning off anti-aliasing doesn't help.

What am I supposed to be looking at? I don't see any grey text in that
image.

> > Changing details of the output format depending upon the $GRASS_PSFILE
> > extension is simple enough. What I can't do in the PS driver is to
> > change the way that d.* commands use the R_* API. That can only be
> > done by changing the d.* commands themselves.
> 
> Suggested "best practice" text for the Programmer's Manual wrt the R_*
> API?

Avoid using frames or erasing the screen unless you are writing
d.frame or d.erase ;)

Anything beyond that needs API changes, which I'd rather deal with as
a whole than through piecemeal fixes.

The API should have a generalised encapsulation (save/restore)
mechanism. Not just for frames, but for all state, e.g. line width,
font, text size, text rotation, etc.

> "IOW, you can't just call D_set_cur_wind() etc and forget about it; you
> would have to explicitly revert to the previous window when you're
> done with it."
> 
> 
> FWIW, I count 22 d.* relevant modules that do original drawing:

"original drawing"?

> > FWIW, I've added some enhancements to the PS driver:
> > 
> > 1. DSC comments are added.
> 
> .ps format now includes "%%BoundingBox: 36 72 559 769" (GRASS_PAPER=A4)
> which crops off the margins. Usually I'd expect the BBox to be the full
> A4 range. Is this intentional?

BoundingBox refers to the actual graphics:

	This comment specifies the bounding box that encloses all
	marks painted on all pages of a document. That is, it must be
	a "high water mark" in all directions for marks made on any
	page.

> .eps format needs the last two BBox numbers swapped to render correctly
> in gv if GRASS_LANDSCAPE=TRUE. (if landscape is even meaningful for .eps)
> %%BoundingBox: 0 0 469 675
> Landscape .ps is fine already.

So GV interprets it differently depending upon whether the file is PS
or EPS? (is it using the extension or the EPSF-3.0 in the header?)

Does the %%Orientation setting affect it? How about the relative sizes
of the width and height?

The DSC manual is unclear as to how %%BoundingBox and %%Orientation
interact. I think that the existing behaviour was necessary to get .ps
to work correctly; getting this to work correctly with .ps files took
several attempts.

I'll look into it some more as I get time.

> > 2. If the output file ends in ".eps", the problematic operators will
> > not be used, and "EPSF-3.0" will be added to the %!PS- line.
> > 
> > One problem with the DSC comments is that the driver cannot determine
> > the language level at the point that the header is written, so it
> > always reports level 3.
> > 
> > Printers don't read DSC comments, so this shouldn't have any effect
> > upon printers which don't support level 3.
> 
> I added a ps_level= option to d.out.file to set/unset GRASS_TRUECOLOR.
> We could use sed to force that into the output file header, but I think
> it would be badly misleading.

GRASS_TRUECOLOR requires either level 2 or level 1 plus the colorimage
and setrgbcolor operators (this is the case for colour printers which
pre-date level 2 PostScript).

Only masked images (d.rast -o, d.rgb -o, d.his -n) require level 3.

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