Hi Phil: On 2015-08-19 12:01+0100 Phil Rosenberg wrote:
> Hi Alan > Congratulations on getting that release out. You are welcome. > On with the next one! >> >> Currently I am aware of the following development possibilities for >> this release cycle: >> >> 1. Phil has already prepared an important memory management fix for >> wxwidgets, and I assume he will also want to deal with some/all of the >> remaining wxwidgets bugs. > > I will push that fix as soon as I get chance. I look forward to that push. I just discovered another serious issue for wxwidgets which is it sometimes just hangs depending on when a PLplot example that uses -dev wxwidgets is launched and other things going on at the time. For example, my interactive comprehensive test had no trouble with this issue prior to release. However, post-release I reorganized that script to do interactive tests in a more concentrated matter, and under those changed conditions wxwidgets hangs occur and make it impossible to finish the interactive comprehensive test unless wxwidgets is excluded from the interactive testing. I assume the hangs are due to something going wrong with IPC between app and wxPLViewer on Linux. Once you get your memory management fix pushed, I will attempt to figure out a simple way to demonstrate the hangs so it will make it much easier for you to verify the issue. > Thanks for the testing > and the bug reports. I will spend my time this release cycle working > on these. However there are two points I would like to bring up: > > 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. > 2) The second point is to do with alignment. Does anybody on the list > have a thorough understanding of how the various alignment and aspect > ratio variables (are intended to) interact? I have fought through > these more than once now and yet on Linux and Windows I am getting > different results - which in itself is baffling. This might be the > cause of the text alignment problems. Changing to a floating point > coordinate system might help as it will remove one level of scaling, > but I currently don't understand how all the core scaling variables > work. I cannot help you with the inner details of PLplot on that matter, but if you get different alignment for Linux and Windows results for the wxwidgets device driver, that is very likely a bug in the wxwidgets library and not a bug in the wxwidgets device driver. And similarly for our qt and cairo device drivers if you get different alignment for those results depending on platform. 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
