[GRASS-dev] Re: [GRASSLIST:10288] Re: ps.map resolution

On Tue, 14 Feb 2006 05:06:20 +0000
Glynn Clements <glynn@gclements.plus.com> wrote:

Tom Russo wrote:

> Back in October there was a discussion of how ps.map had a hard
> coded setting of 75DPI for its output, and a bit of a discussion of
> fixing that.
>
> I just spent a bunch of time trying to make postscript map files of
> some fairly high-quality map scans, only to have them come out
> looking blotchy. Only just now did I remember this discussion and
> look it up in my mail archives.
>
> Has there been any more thought about how to do away with this
> hard-coded limit in ps.map? The temporary solution is to rebuild
> ps.map with a different, higher hardcoded resolution, which is
> icky, to say the least (but easy, and that's what I did).

Sorry, I didn't realise it was still there. The latest CVS version no
longer downsamples raster maps.

grass6/ps/ps.map/read_cfg.c still has two "PS.res = 75;" statements.

Can these safely be removed?

Hamish

Hamish wrote:

> > Back in October there was a discussion of how ps.map had a hard
> > coded setting of 75DPI for its output, and a bit of a discussion of
> > fixing that.
> >
> > I just spent a bunch of time trying to make postscript map files of
> > some fairly high-quality map scans, only to have them come out
> > looking blotchy. Only just now did I remember this discussion and
> > look it up in my mail archives.
> >
> > Has there been any more thought about how to do away with this
> > hard-coded limit in ps.map? The temporary solution is to rebuild
> > ps.map with a different, higher hardcoded resolution, which is
> > icky, to say the least (but easy, and that's what I did).
>
> Sorry, I didn't realise it was still there. The latest CVS version no
> longer downsamples raster maps.

grass6/ps/ps.map/read_cfg.c still has two "PS.res = 75;" statements.

Can these safely be removed?

Nothing appears to read PS.res, so it should be safe, although the
field should be removed altogether rather than left uninitialised.

--
Glynn Clements <glynn@gclements.plus.com>