On 2012-07-03 13:21+0100 Andrew Ross wrote: > On Tue, Jul 03, 2012 at 11:05:17AM +0200, Sylwester Arabas wrote: >> Hi Andrew, >> >> Thanks for your answer. >> >> On 03/07/12 10:05, Andrew Ross wrote: >> > On Sat, Jun 30, 2012 at 11:54:37AM +0200, Sylwester Arabas wrote: >> >> In GDL (gnudatalanguage) we use two "private" plplot functions: >> >> plstrl and plP_mmpcy to get string width: >> >> ... >> >> Are there any "public" equivalents or any elegant way to achieve >> >> this functionality without #including<plplot/plplotP.h>? >> > >>> These functions are part of the internal API of plplot as you note and so >>> are not guaranteed to be available to >>> the user. In fact using -fvisibility=hidden enforces this (and hence shows >>> up problems like yours). I don't think >>> there is a sensible alternative in the current external API. Why do you >>> need to access these functions? Is there >>> some other functionality in plplot that is missing? >> >> We use to it to implement in GDL the WIDTH keyword of the IDL's XYOUTS >> procedure. XYOUTS plots a string label on the current device, and >> optionally returns the width of the plotted string. >> >> Could plstrl() and plP_mmpcy() be made public (and part of the C++ API)? > > Sylwester, > >> From the link you sent it looks like you also make use of the internal > plP_mmpcx and plP_gphy functions. Really what you want is the string > width, or even a box around the string, returned in physical coordinates > rather than mm? This would then only require a single new API call? > > We may be add in a API function if you can convince us it is useful. Before > doing so we would need to make sure we designed a proper and generally useful > external interface rather than just making the existing private functions > available.
Hi Andrew and Sylwester: Some additional background is that the new pllegend capability uses string widths internally to sort out spacing issues in the legend, and we found that the original plstrl did not handle utf8 unicode strings very well. So the solution for the internally updated plstrl was to hand that problem off to drivers (whose dependent libraries sometimes have a nice calculation of string length that works well even in the utf8 case). So if a device driver has the "has_string_length" capability (currently that is just the cairo and qt device drivers, but those two cover virtually everything you need) you will get much more reliable results for plstrl. @Andrew: I liked your idea of providing a new public API (called, say, plstringbox) to give a bounding-box for the string. One nice thing about mm coordinates (typically used within PLplot for any coordinates having to do with text) is the size in mm is invariant to rotation. I suspect the mm coordinates are the only ones that have this property. In that case, we would probably wish to stick with mm coordinates for the plstringbox result and make transformations from mm to other coordinates part of our public API as well. However, the emphasis is on the "probably" there because I am rusty on all the many different PLplot coordinate systems and couldn't find decent documentation for them. Therefore, I suggest if this idea is taken further that writing good docbook documentation for our coordinate systems should be part of the effort as well. 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 __________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel