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? Here is the current status for how drivers use plspage (where if the first two arguments are zero, user-defined or default DPI values are not overridden, but otherwise they are overriden). software@raven> grep plspage drivers/* drivers/cgm.c:// or plspage drivers/cgm.c: plspage( 0., 0., 800, 600, 0, 0 ); drivers/cgm.c: plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 ); drivers/deprecated_wxwidgets.cpp: plspage( 0.0, 0.0, (PLINT) ( CANVAS_WIDTH * DEVICE_PIXELS_PER_IN ), drivers/deprecated_wxwidgets.cpp: plspage( VIRTUAL_PIXELS_PER_IN / dev->scalex, VIRTUAL_PIXELS_PER_IN / dev->scaley, 0, 0, 0, 0 ); drivers/deprecated_wxwidgets_app.cpp: plspage( 0.0, 0.0, width, height, 0, 0 ); drivers/deprecated_wxwidgets_app.cpp: //plspage( 0., 0., width, height, 0, 0 ); drivers/gd.c:// or plspage drivers/gd.c: plspage( 0., 0., 800, 600, 0, 0 ); drivers/gd.c: plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 ); drivers/gd.c:// or plspage drivers/gd.c: plspage( 0., 0., 800, 600, 0, 0 ); drivers/gd.c: plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 ); drivers/pdf.c: plspage( DEVICE_PIXELS_PER_INCH, DEVICE_PIXELS_PER_INCH, drivers/svg.c: // Set the bounds for plotting in points (unit of 1/72 of an inch). Default is SVG_Default_X points x SVG_Default_Y points unless otherwise specified by plspage or -geometry option. drivers/tkwin.c:// size: pls->xlength, pls->ylength (use plspage() or -geo option) drivers/wingcc.c: // or plspage drivers/wingcc.c: plspage( 0., 0., 800, 600, 0, 0 ); drivers/wingcc.c: plspage( GetDeviceCaps( dev->hdc, HORZRES ) / GetDeviceCaps( dev->hdc, HORZSIZE ) * 25.4, drivers/wxwidgets_dev.cpp: // the user might have already set this with plspage drivers/wxwidgets_dev.cpp: c_plspage( 90, 90, 900, 675, 0, 0 ); drivers/wxwidgets_dev.cpp: c_plspage( 90, 90, 0, 0, 0, 0 ); drivers/xwin.c:// size: pls->xlength, pls->ylength (use plspage() or -geo option) So most of our device drivers and especially our "best" drivers (e.g., svg, qt, and cairo) do not attempt to override user-set or default (above) dpi values, and assuming you implement the above suggestion, then the only change to wxwidgets would be setting the first two arguments of plspage to 0., to use the default (or user-set) dpi values instead of wxwidgets-specific values of 90 regardless of what the user sets. And then the hard slogging begins for each maintainer of a device driver to (a) review whether it is really necessary to override default or user-set dpi values as occurs for all plspage calls above with non-zero first two arguments, and (b) honoring the dpi values that have been set by default or by the user. It sounds like this might all just work fine for the new wxwidgets device driver with the changes above I have recommended, and I also notice lots of dpi-related logic for drivers/qt.cpp so that device driver may be OK, but drivers/cairo.c doesn't have anything relevant to dpi that I can find so presumably there will be lots of work to do by whoever (Hazen?) is maintaining that device driver. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
