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

[Hamish]

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