Re: [Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Phil R. <p.d...@gm...>]

On 20 August 2015 at 20:44, Alan W. Irwin <ir...@be...> wrote:
> On 2015-08-20 14:43+0100 Phil Rosenberg wrote:
>
>>>> 1) Text size. As far as I am aware the text size in wxWidgets is
>>>> entirely correct - I haven't double checked this today, but this was
>>>> the case last time I checked. The docs state that the text size
>>>> provided by the user is in mm, and I use a value of 90 pixels per inch
>>>> (converted to metric) to convert to pixels. Counting pixels on the
>>>> screen it appears that the output is as I intended. The pixels per
>>>> inch value I used is the same as used by inkscape - so the wxWidgets
>>>> output should have similar sized text to the svg output rendered by
>>>> inkscape. However as you can find online (e.g.
>>>>
>>>>
>>>> http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
>>>> different svg renderers assume different pixels per inch in their
>>>> rendering. However if other drivers are providing text that is 2.2
>>>> times the size of that in wxWidgets they must be assuming around 40
>>>> pixels per inch which is much lower than any other standard I have
>>>> seen.
>>>> Basically where I am going is that we should set a standard value for
>>>> pixels per inch for all raster drivers. It would potentially be useful
>>>> to have an API call to set the pixels per inch too. Then each driver
>>>> can be checked to make sure it conforms - perhaps with the Peace
>>>> example being used to check.
>>>
>>>
>>>
>>> I am old school scientist on this issue on the one hand, and completely
>>> semiempirical on the other.  :-)
>>>
>>> I. Old school:
>>>
>>> Pixels per mm (and therefore pixels per inch or DPI) should not be an
>>> assumption.  Your monitor has a definite resolution in pixels and a
>>> definite size in mm so therefore it has a known value for pixels per
>>> mm and DPI in both X and Y.
>>>
>>> However, there are some important caveats about this for the
>>> Linux/X11 case see
>>>
>>> <http://unix.stackexchange.com/questions/75344/how-does-x-server-calculate-dpi>.
>>>
>>> That reference does not mention xrandr which is one way to determine
>>> actual DPI for the Linux/X11 case.
>>>
>>> irwin@raven> xrandr |grep " connected"
>>> HDMI-1 connected 1440x900+0+0 (normal left inverted right x axis y
>>> axis) 410mm x 256mm
>>>
>>> I verified those dimensions with a meter stick since my monitor manual
>>> does not include the actual display dimensions.
>>>
>>> Those results imply actual XDPI is
>>>
>>> irwin@raven> echo "1440*25.4/410" |bc -l
>>> 89.20975609756097560975
>>>
>>> and YDPI is
>>>
>>> irwin@raven> echo "900*25.4/256" |bc -l
>>> 89.29687500000000000000
>>>
>>> So those appear to be reasonably reliable numbers for DPI for my
>>> monitor, but as the discussion in the above URL states, the xdpyinfo
>>> application does _not_ provide reliable DPI information.
>>>
>>> irwin@raven> xdpyinfo | grep -E 'dimensions|resolution'
>>>   dimensions:    1440x900 pixels (381x238 millimeters)
>>>   resolution:    96x96 dots per inch
>>>
>>> That is, that app does report the correct pixels for the monitor, but
>>> arbitrarily fakes the size in millimeters to always return fake DPI
>>> values of 96!  I have read web assertions that these fake values are
>>> simply an attempt to follow a fake DPI "standard" set by Microsoft
>>> Windows, but I don't know that is the case.
>>>
>>> So PLplot could in theory (for at least the Linux/X11 xrandr case) be
>>> able to interrogate the operating system to determine the actual
>>> pixels per mm values and then use those values for all rendering that
>>> is done in units of mm.  But just because the xrandr-derived value was
>>> correct in my case does not mean is will be correct in all cases, and
>>> there is also concern about what to do for other platforms. So I doubt
>>> very much we will go there.
>>>
>>> Another approach might be to assume some reasonable DPI value and then
>>> attempt to enforce that for each of our device drivers. But that might
>>> be tricky for our device drivers like qt and cairo which depend on
>>> external libraries which might have their own independent standards
>>> about what to assume for DPI value.  So for now and perhaps
>>> indefinitely, I think we are stuck with the semiempirical approach
>>> below.
>>>
>>> II.  Semiempirical.
>>>
>>> The semiempirical approach is simply to multiply the character size
>>> for each device driver so it agrees reasonably with the others for the
>>> second page of example 2.  That is, the numbers on that page should be
>>> fairly closely inscribed by the inner square.
>>>
>>> I have just looked at that page for a wide variety of our devices, and
>>> they all pass this test more or less except for wxwidgets where the
>>> numbers are roughly half the size of the inner square.  So it is on
>>> that basis I suggest you approximately double the character size to
>>> match more closely what the other devices do here.
>>>
>>>
>>
>> HI Alan, in some ways I am fine with that. I think actually wxWidgets
>> has a cross platform display class which dimensions can be grabbed
>> from.
>> I did read a while ago about something on Windows where there is a
>> requirement to get into the App Store that an app notices high density
>> (i.e. phone/tablet) screens and scales text appropriately, but I can't
>> remember the details.
>>
>> However, if we decide we have no interest in matching the size of text
>> to an actual metric like mm, then we should remove that from the
>> documentation. The problem then becomes, what do we put in it's place?
>> Having something like "plplot uses an arbitrary and undocumented font
>> scaling which is approximately the same for all drivers but is not
>> linked to any physical dimension of the plot" obviously isn't
>> satisfactory but that is basically what we are doing.
>
>
> Good point.  The semiempirical approach tries to avoid opening this
> can of worms, but you are likely correct we should clean up this mess.
> Since using actual DPI values for each monitor
> used by our users is impossible for the reasons I stated, then probably the
> documented goal (although the documentation should state this is
> not realized yet for all device drivers) should be that PLplot does pixel
> to metric conversions based on a xdpi and ydpi specified by the
> user (via the existing -dpi command-line option or equivalent plspage call)
> or by the default dpi value set by PLplot.
>
> To implement that last, I suggest that default value (note, using 90 for
> that default value seems OK to me) should be specified as follows:
>
> #define PLPLOT_DEFAULT_DPI 90
>
> in include/plplot.h and
>
> plsc->xdpi = PLPLOT_DEFAULT_DPI;
> plsc->ydpi = PLPLOT_DEFAULT_DPI;
>
> in plstrm_init (which initialises all streams).
>
> If you agree with this approach for setting default PLplot-wide
> plsc->xdpi and plsc->ydpi values will you please push a commit to this
> effect to get this preliminary out of the way?

This seems perfectly sensible to me. I will make this change and commit it.

Phil