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

[Hamish]

Hamish:
> > > I added PostScript support to d.out.file, and also did a bit of
> > > cleanup in the script along the way. It seems to work very nicely.
> > > For an example see the d.out.file help page.

[I've now added support for .eps too, thanks Glynn!]

Markus:
> > 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. I guess it happens
as the default line width is 0 not 1? Adding D_line_width(1) to the
start of d.barscale/draw_scale.c makes everything a bit thicker
(probably too thick, although the "N" and stroke text is nicer), but it
doesn't solve the jagged bits where the lines meet the black rectangles.

>From memory d.barscale has a bad mix of float->int rounding throughout.

Glynn:
> For now, the only practical solution is to provide a way to avoid the
> initclip in the WINDOW operation. That will have the side-effect that
> programs which create their own frames will be largely incompatible
> with EPS output. Once a frame has been created, it will cease to be
> possible to draw anything outside of that frame.

We can note this in the PS driver help page, and suggest .ps + ps2epsi
for those cases.

> 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?

"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:

d.barscale
d.correlate
d.frame
d.geodesic
d.graph
d.grid
d.his
d.histogram
d.labels
d.legend
d.linegraph
d.path
d.polar
d.rast
d.rast.arrow
d.rast.num
d.rgb
d.rhumbline
d.text
d.title
d.vect
d.vect.chart


> round() rounds to the nearest integer:

sorry, I misread the man page, focusing on what happened in a tie.


Glynn:
> 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?

.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.


> 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.


Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: barscale_eps.jpg
Type: image/jpeg
Size: 10162 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070515/9711e45d/barscale_eps.jpg