[GRASS-dev] d.out.file now talks to the PostScript driver
Hamish
hamish_nospam at yahoo.com
Wed May 16 06:12:19 EDT 2007
Glynn Clements wrote:
>
> 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.
I moved on.. not grey text but jagged lower edge of the barscale box.
> 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.
for now I have added a warning in d.out.file that PS driver + d.frame
will not work as the user might expect, and to use ps2epsi for that.
> > FWIW, I count 22 d.* relevant modules that do original drawing:
>
> "original drawing"?
I meant not modules like d.rast.leg and d.vect.thematic that just call
other d.* modules.
> > .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?
I am working d.out.file example 1 here. Inserting as a figure in LyX for
a more real-world test. (I can live with GV not being 100% if it prints ok)
.ps displays as expected in GV, both G_LANDS= Portr & Landsc.
.eps G_LANDS=FALSE (Portrait) displays as expected in GV
.eps G_LANDS=TRUE is the funny one.
> > (if landscape is even meaningful for .eps)
- GV orientation box says Landscape
- GV canvas is 640 Tall by 480 wide
- GV map is 480 tall and falls off the right edge
* Same brokeness in LyX display, seen in full in PS output but the top
figure caption falls off of top of output PS page (rot 90 CCW)
- if I change orientaion in the GV top menu to Portrait,
canvas is 480 Tall by 640 wide but map is rot 90 CCW and falls
off top
- if I edit the .eps file to switch the last 2 nums in %%BBox, GV
displays as expected (640x480, orientation menu says Landscape)
* edited version is rot 90 CCW in LyX but all there. Top figure
caption obeys expected page margins.
(rot 90 ccw is ok as LyX allows figure rotation)
- if I edit the .eps file keeping BBox as created but changing %%Ori,
GV canvas is 480 Tall by 640 wide but map is rot 90 CCW and falls
off top
* Same brokeness in LyX display, seen in full in PS output but the top
figure caption falls off of top of output PS page (rot 90 CCW)
So AFAICT, %%Ori is used independently of {%%BBox and the following}:
%%BeginSetup
0 0 translate
-0 480 translate 1 -1 scale
+90 rotate 0 1 -1 scale
640 480 BEGIN
%%EndSetup
ie %%BBox and the above exist in the same plane, %%Ori rotates that plane.
??
> How about the relative sizes of the width and height?
not tested.
> 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.
For sure .eps in landscape mode is the lowest priority and everything
else seems to work properly.
> I'll look into it some more as I get time.
thanks.
> > > 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.
I have left ps_level= setting GRASS_TRUECOLOR (and nothing else), not sure
what else to do with it. (could grep for those three MASK calls and print
a warning or something if level<3)
Hamish
More information about the grass-dev
mailing list