I thought this might be a useful point to jump in. Alan and I had some
discussions recently about newlines in the wxWidgets drivers. They are
currently inconsistently applied to the wxGraphicsContext and wxDC and
wxAgg/freetype versions of the drivers. We weren't entirely sure how well
newlines were dealt with in other drivers. Other even worse inconsistencies
were found when a string contains newlines and escape characters.
I've written a patch to deal with the wxGraphicsContext and wxDC drivers, but
not yet looked at how Agg deals with things nor have I yet written the patch
for plfreetype. Unfortunately I used v 5.9.9 to work on the patch so need to
transfer the work to the trunk version.
I definitely think a string box function would be very useful, (e.g. to add
newlines to a long string to avoid it spilling off the edge of a plot), but
inconsistent newlines might be an obstacle to watch out for too.
I will make sure the wxWidgets newline patch is submitted as soon as I have it
ready.
Phil
Message: 3
Date: Tue, 3 Jul 2012 23:40:36 +0100
From: Andrew Ross <andrewr...@users.sourceforge.net>
Subject: Re: [Plplot-devel] accessibility to plstrl & plP_mmpcy
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net, Axel Beckert <a...@debian.org>,
Alain Coulais <alain.coul...@obspm.fr>
Message-ID: <20120703224036.GD31408@gandalf.rivendell>
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. 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.
Sorry, I should probably have pointed that out as well.
>
> @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.
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.
Regards
Andrew
------------------------------------------------------------------------------
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
