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

Reply via email to