[GRASS-dev] d.out.file now talks to the PostScript driver
glynn at gclements.plus.com
Tue May 15 13:41:36 EDT 2007
> > > Small observation: the barscale font color is grey in the resulting
> > > PS file while black in PNG (at least for my eyes).
> > 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
> > 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_*
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:
> > 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
> .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
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>
More information about the grass-dev