[GRASSLIST:10287] Re: ps.map resolution

Tom Russo russo at bogodyn.org
Mon Feb 13 22:53:45 EST 2006


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).

On Mon, Oct 03, 2005 at 01:04:45PM +1300, we recorded a bogon-computron collision of the <hamish_nospam at yahoo.com> flavor, containing:
> > > 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

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit."  --- The Tick




More information about the grass-user mailing list