[GRASS-dev] Scale display in GRASS Monitor

[Glynn Clements]

Markus Neteler wrote:

> >> the GRASS monitor does not show the approx. scale of the map.
> >> In the past I introduced that one or two times but it was
> >> reverted. Since every GIS shows a scale on screen, it is
> >> hard to explain why GRASS doesn't do it.
> >>
> >> So I launch a new attempt to get the scale (back) on top
> >> of the GRASS monitor... I know about dpi and all this stuff
> >> but we really don't need centimeter precision :-)
> >>
> >> Opinions?
> >
> > The movement towards gis.m and the PNG driver only makes this even
> > less feasible now than it was in the past. What is the DPI of a
> > PNG/PPM file?
> >   
> I was thinking of the XDRIVER GRASS monitor only.
> > I'm willing to extend the driver protocol so that such a feature
> > becomes possible, if you can:
> >
> > 1. Persuade me that even at this late stage in its life, XDRIVER is
> > still worth extending.
> >   
> I have the code ready...
> > 2. Convince me that it really doesn't matter that the reported scale
> > will be *significantly* inaccurate for most users.
> >
> > [For me, xdpyinfo reports 75x75dpi. Given that the screen resolution
> > is 1920x1440, that implies that I have a 32" monitor. In reality, the
> > monitor is (nominally) 22", so the actual resolution is more like
> > 110dpi. IOW, the reported resolution has a relative error of ~50%.]
> >   
> I have tested it on my monitor (flat screen):
> 
> d.screenscale
>   D0/0: True map size:  we_meters: 19020.000000 ns_meters: 14310.000000
>   D0/0: monitor size: screen_we_pix: 640 screen_ns_pix: 480
>   D0/0: Pixel numbers used in screen: ns: 480.000000  we:637.000000
>   D0/0: Map rows: 477  map cols: 634
>   D0/0: Xserver screen resolution: x:85.109948 dpi y:83.097764 dpi

Your X server is configured with knowledge of the physical screen
dimensions of your monitor (either through manual configuration or via
DDC).

That won't be true for all X servers. Apart from anything else,
anything other than 75x75 or 100x100 dpi tends to produce ugly (even
illegible) results with legacy applications and bitmap font. 
Conseqently, many users (including myself) lie about the monitor
dimensions to force the computed resolution to equal 75x75dpi.

It doesn't work with Cygwin's XWin.exe (which doesn't have a
configuration file; and in any case, Windows only gives you a choice
of 96 or 120dpi, and quite a few applications are hardcoded to 96dpi).

There are plenty of other cases where trying to report accurate
physical dimensions will fail: multiple, different-sized monitors in
clone mode (typically used if you have a laptop which is sometimes
connected to an external monitor), dynamic resolution changes via
RandR, etc.

>   D0/0:  Map height in true centimeter on screen: 14.325000
>   D0/0:  Map width in true centimeter on screen:  19.470801
>   D0/0:  (note: deviations may arise from your screen adjustments)
>   D0/0:  Current map scale (note: Xserver x_res != y_res):
>   D0/0:    y-scale: 1:99895.287958
>   D0/0:    x-scale: 1:97684.734253
>   Approximate map scale in GRASS monitor <x0> 1:99000
> 
> Compared to the measured monitor window dimensions, they deviate for me by
> around 3% in x direction and 1% in y direction which IMHO is fair.
> > 3. Tell me what resolution the PNG driver should report.
> >   
> Maybe none? Or is the XDRIVER now a  wrapper around the PNG driver? I lost
> a bit track how it is working now.

The only reliable way for a client to obtain the display resolution is
to ask the driver for this information (querying the resolution of
some random X server which may or may not be the one on which XDRIVER
is running is no better than hardcoding 75x75dpi; or using rand(), for
that matter).

For the driver to provide this information, there needs to be an R_*
function (and a corresponding protocol opcode). In turn, this means
that each driver must implement this operation. It's easy enough to do
for XDRIVER (although I suspect that libW11 will need to be extended
or else --enable-w11 will stop working), but what should the PNG
driver implementation do?

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