[GRASSLIST:8466] Re: ps.map resolution

[Hamish]

> > Glynn, I guess I just don't understand.  The raster can not be
> > written  at the region's resolution with ps.map.  In my example I
> > sent, the same  region produced rasters of different resolution
> > solely based on the  scale entered in ps.map.  The resolution is
> > much coarser for a 1:50000  map compared to a 1:500 map.  These maps
> > were made without changing the  region.  I understand that the
> > raster is embedded within the postscript  file, but that raster's
> > resolution can not be based only on the  region's settings if one
> > can get different resolutions without changing  the region.
> 
> Sorry, you're right; ps.map has a hardcoded limit of 75dpi. The
> "scale" command changes the size of the image, and thus of the
> computed resolution.

Indeed! Nicer prints for everyone! Thanks for correcting us Ian.


> set_paper.c has a hardcoded setting:
> 
>     PS.res = 75;

note in 6.0 source this code is in read_cfg.c and map_setup.c.
Just bumped that 75dpi to 1200dpi in read_cfg.c locally and remade a map.
It does look quite a bit better in gv at zoom=10x.


> Thus it effectively rescales the raster by powers of two until it is
> less than 75dpi and contains less than 3E8 pixels for greyscale or 1E8
> pixels for colour.
..
> Personally, I think that code should simply be removed. I suspect that
> it was put there to prevent users from accidentally creating huge
> print jobs on a system which couldn't handle them.
> 
> Note that the image is "streamed" (rendered as it is read from the
> PostScript file, not stored), so the amount of memory in the printer
> isn't an issue.


Suggestion: 

1) We add a "dpi" control to the "paper" ps.map instruction. Bump current
75dpi restriction to a default of 300dpi(??). My original thought would
be to make the default 1200dpi, but those 200mb PostScript files really
start to pile up after a while..

2) As for the 1e8 limit, that's a 10000 x 10000 cell region which isn't
uncommon on a modern system. Dumb fix is to bump that to e9 which sets a
max of ~31600 x 31600 region size for the color case. Bumping to e10
means 100000 x 100000 which we probably won't hit for a long while. But
making this arbitrarily large gets away from the point of having a limit
in the first place, so maybe better just to rip it out and only leave in
the max dpi control (variable).



Hamish