Date: Tue, 3 Jul 2012 23:40:36 +0100
From: Andrew Ross <firstname.lastname@example.org
Subject: Re: [Plplot-devel] accessibility to plstrl & plP_mmpcy
To: "Alan W. Irwin" <email@example.com
, Axel Beckert <firstname.lastname@example.org
Alain Coulais <email@example.com
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 03, 2012 at 11:25:45AM -0700, Alan Irwin wrote:
> 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.
> > 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
> results for plstrl.
Sorry, I should probably have pointed that out as well.
> 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.
This makes sense. It is possible that users may want to convert to
coordinates in real units (mm) so it probably makes sense to include these
transformations in the API. This is relatively straightforward.
Alan, if you also think the string box is a useful idea then I'll
investigate further. I can imagine this being helpful for other users
anyway. This is likely to take a bit longer however.
In terms of the specific Debian issue I wonder if the best option is either
to turn off -fvisibility=hidden (I'd rather not), or as a temporary patch
just make the functions GDL requires visible until we get a more permanent
solution. Either would close the bug and allow GDL to build with the version
of plplot in testing / unstable. Given we are now in a freeze this seems the
best course of action.