[GRASS-user] d.out.file Usage (version -6.5svn)

[Hamish]

Rich:
> (version -6.5svn)

(ie the shell script version)

> I ran 'd.out.file' on a map of the entire basin with format=ps
> and paper=us-letter. This produced a 657M file. Whew! Running
> it through ps2pdf dropped the size by 90%.

what was your region set as? number of rows/cols?
outputting raster maps or ..?
posting the full command line usage is always helpful too.
Cairo mode makes it use the CAIRO display driver instead of
GRASS's PS driver in this case.

for me it works fine.

> So, when I repeated the module on a portion of the basin, I
> specified format=pdf.
> This produced a 30byte file. No kidding! So I reverted to the
> .ps output format.

probably your libcairo was not built with PDF support.

for me it works fine, but the `evince` viewer does give me
this warning message:
"Error: PDF file is damaged - attempting to reconstruct xref table..."


I'll note that the Cairo (incl .ps and .pdf) and direct PS
drivers are rather new, and a big lesson/reason why Glynn
took the time to rewrite much of the display architecture
for grass 7. The ps.map module has traditionally been the
way to do proper cartography but it is hoped that the new
display system will allow the d.* modules to do an equally
nice job. (personally I like ps.map more than GMT for hard-
copies, and having climbed both I think the ps.map learning
curve is not as horrifying, but that's just my biased opinion.
I'm keen to try out qgis's brand new map composer tool at
some point)


> If not too time consuming, could the '--o' (overwrite) option
> be added to d.out.file?
> Avoids having to manually delete the previous version when it
> needs to be redone.

this chuck of code should be doing that:


#is there a simpler way of testing for --overwrite?
if [ -e "$outname" ] ; then
   if [ -z "$GRASS_OVERWRITE" ] || [ "$GRASS_OVERWRITE" -ne 1 ] ; then
      g.message -e "File <$outname> already exists"
      exit 1
   fi
fi


and for me, --overwrite (or not) works as it should.


>   When I use d.out.file specifying format=ps and
> paper=us-letter I don't get the results I expect from reading
> the man page. I don't now know if the same issues arise with
> version-6.4svn; I'll try that latter today.

but the PNG output looks ok, right?
 
>   In both the basin and closeup maps I use d.text to
> label the stream name.
> The label is in the proper position and at proper size on
> the display monitor. However, in the PostScript (and PDF)

probably the PostScript is created by the PS driver and the PDF
by the Cairo driver, so be casreful about lumping them together)

> output the label size is increased and it's moved relative to
> its position on the display. Is this something I can control?

probably not without using v.label. For custom labels you
can either digitize a few points by hand & use v.label or
probably just as easy to add some entries to the end of the
existing labels text file in $MAPSET/paint/labels/.


>   I don't understand the size option. Is it to be presented
> in pixels, picas, centimeters, inches, percent of the page?

Guessing from what happens with label offsets rendered with
ps.map, I'd say one is using pixel offsets and the other one
is using points as the unit (1/72 of an inch).

So it is probably context dependent. d.* were only written with
pixels in mind, I'm not sure how the new drivers deal with that.
For d.labels & ps.map I've tried calibrate things to (sort of)
line up like the other one does, more or less, given the semi-
unitless offset value.


> When I specify paper=us-letter, why do I get extra border
> lines on the left and top of the image itself?

those are at the bounding box of the ps/eps/pdf. In `gv` if
I set the page size to BBox they exactly line up. As to why
and if they should be there, Glynn will have to answer that.
I expect you can be sneaky and edit the PostScript file in a
text editor to get rid of them, just search for coords matching
the bbox in the header line and nuke that move/stroke.


>   How do size, resolution, and paper relate to each
> other? Are they mutally exclusive?

mutally exclusive. "size" overrides "resolution" setting.
"paper" is only used for postscript output using the PS driver.
(so .ps + Cairo flag ignores it)


.pdf uses the Cairo driver which ignores the paper setting.
(ie what the GRASS_PAPER environment variable gets set to)
It probably should respect that..
So use the ps2pdf ghostscript util to make your PDFs if you
care about printed paper size. (oh, and OT but `pdftk` rocks)


Hamish