On 2015-08-26 11:02+0100 Phil Rosenberg wrote: > Hi All > I think I have found some inconsistencies in the plplot rotated text > text routines. > > I am trying to get the 3d text correct in the wxWidgets driver in x28. > It dawned on my that the driver reports the size in device units as > the maximum int in both directions - i.e. square. So I applied a > correction to the rotation and shear to account for the actual aspect > ration and suddenly all the 3d text looked perfect. Even better when > the aspect ratio changed, the text also changed to match giving > perfect resizable windows. I was very pleased. > > The I tested example 4 and found that the in plot text was no longer > parallel with the line. I was less pleased. > > Tracing through c_plptex I realised that the device units per mm have > been set bythe driver to reflect the actual aspect ratio. So xpmm is > 156.1 and ypmm is 221.6. > > I therefore think that the 3d text and the standard rotated text are > calculated in different unit spaces. One in mm which honours the > aspect ratio and one in device units which assumes a square. > > I'm not sure what to do about this. Does anyone know any other drivers > which report sizes in this way or am I being an idiot for trying to do > this - (if I am then we should replace xpmm and ypmm with a single > dupmm to stop it happening to anyone else). I actually rather like the > fact that by telling plplot the page is square I can get the text to > adjust to aspect ratio changes, but it will probably break the replot > function if it uses a different driver that doesn't do this. > > I could try to make the 3d and standard rotated text consistent, but > I'm not sure which is "right". > > Any suggestions would be very welcome right now before I start making > decisions based on wxWidgets requirements.
It makes no sense that pixels per inch in each dimension is the same (assuming you are using the default value of 90 for these data) yet xpmm and ypmm are different. That sounds like a fundamental bug to me. Of course, it is also possible that fundamental bug has been papered over for many devices so fixing it might require a lot of device fixing as well. But a fundamental fix in this area might do wonders for a number of coordinate-related bugs that are floating around out there such as the problem with weird results for -ori x, where x is not an integer; the fact that the octave "p" examples don't work unless the device is square; and the difference in gradient results at angles other than n*PI/2 between gradients from external libraries and software fallback gradients. So to me it sound like what we really need is clear documentation of all the different coordinate systems used by PLplot and our devices before we do anything else, and then a bug search for parts of PLplot that do not follow that documentation. Are you game for starting such documentation based on what you have discovered in the past few days? For now, simple ascii text in drivers/README.coordinates would do, but eventually such documentation should be part of our DocBook documentation. 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
