Hi Alan I have just noticed there is a value PL_NOTSET. This is documented in plsdidev as a value to pass in when you do not wish to set a value. I wondered if this might be usefully used in plspage. It would be much better than passing in 0 or using zero to represent unset particularly for the location. Currently in plspage it is impossible to set the location (xoff, yoff) to (0,0) or to tell if the location is supposed to be zero or if it is just unset.
Of course the upshot is that this is an API change that will probably break all the drivers and some user code. Also the value of PL_NOTSET of -42 is not ideal as it would be perfectly legal to have a position of -42. Something like MIN_PLINT would be better. This is really just a mention, I'm not saying we should do it as the cost is pretty high. But something to think about. Phil On 25 August 2015 at 20:06, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-08-25 08:15+0100 Phil Rosenberg wrote: > >> Hi Alan >> >>> Instead of multiplying the MM values by 72/25.4 within drivers like >>> svg whose length units are pts, I intend instead to simply #define >>> PLPLOT_DEFAULT_PTPI, PLPLOT_DEFAULT_WIDTH_PT, and >>> PLPLOT_DEFAULT_HEIGHT_PT in plplotP.h and use those values in pt devices. >> >> >> Works for me, I have no strong feelings here. >> >>> >>> It is also becoming pretty clear to me that plsc->xdpi and plsc->ydpi >>> are misnomers since dots per inch normally would refer to pixels only. >>> Thus, I will probably change those to plsc->xupi and plsc->yupi where >>> "upi" stands for units per inch where units could be pixels, pts, mm, >>> or whatever length unit is appropriate to the device. >> >> >> In the documentation it says that dpi will only be used by raster >> drivers and drivers which use real world units will ignore the dpi >> measurements. I don't know if svg or ps or pdf drivers actually use >> the dpi value at all, but given that statement in the docs then >> leaving it as dpi or using ppi might be a better description. >> In the API these variables are called xp and yp, which are not very >> descriptive This is somewhere it might be worth making a change, where >> I would suggest changing them to dpi or ppi. > > > Hi Phil: > > Actually, that remark about dpi being ignored by "real-world" drivers > is something you included in your recent changes to the plspage > documentation which was probably based on an earlier e-mail remark by > me. I am not sure this is actually true at the moment for our > "real-world" drivers, but I certainly believe it is a worthwhile goal > for them since changing the number of mm per inch or pts per inch > should do very little other than to cause mass confusion. > > At the same time, though, I see nothing wrong with real-world devices > calling plspage with the units per inch that they use so that > plsc->xupi and plsc->yupi will reflect that in case those values are > of some use to the user. Therefore, I am still leaning strongly toward > the above rename from dpi to upi. > > Also, I plan to change > > PLPLOT_DEFAULT_MMPI ==> PLPLOT_MMPI > PLPLOT_DEFAULT_PTPI ==> PLPLOT_PTPI > > (i.e., drop DEFAULT from the name) since there is nothing "default" > about these values). But I will retain the > > PLPLOT_DEFAULT_PIXPI > > name since that really is a default value that is only adopted if the > user does not select some other value. > > Finally, I have to say that making all devices follow the same set of > rules for getting and setting upi and length values (with > well-established variations for each general kind of device length > unit) is long overdue, and we are still very early in the stages of > the whole process. So our current ideas about what the rules should > be are mostly theoretical and will likely require revision as we gain > practical experience with this change for more and more of our > devices. > > > 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
