Leading Spaces in xstring

classic Classic list List threaded Threaded
12 messages Options
Richard llom Richard llom
Reply | Threaded
Open this post in threaded view
|

Leading Spaces in xstring

Hey All,
I have this code to print some information in the graph:
// Save info as string
infobox(1) = msprintf('Min V      %.2f V \n',min(log_data(:,3)));
infobox(2) = msprintf('Max V      %.2f V \n',max(log_data(:,3)));
infobox(3) = msprintf('Capacity   %.2f Ah\n',amphrs);
infobox(4) = msprintf('           %.2f Wh\n',watthrs);
// Print info as box on the figure
xstring(1,0.1,infobox,0,1);
boxh = gce();
boxh.font_style = 0; // Set monospace font

As you can see in infobox(4) I'm using just spaces to align the values. However unfortunately xstring isn't printing these leading spaces.
Is this expected behavior or a bug?

Any ideas to workaround that limitation?

Thanks
richard
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

Hi Richard,

Le 10/08/2017 à 13:58, Richard llom a écrit :
Hey All,
I have this code to print some information in the graph:
// Save info as string
infobox(1) = msprintf('Min V      %.2f V \n',min(log_data(:,3)));
infobox(2) = msprintf('Max V      %.2f V \n',max(log_data(:,3)));
infobox(3) = msprintf('Capacity   %.2f Ah\n',amphrs);
infobox(4) = msprintf('           %.2f Wh\n',watthrs);
// Print info as box on the figure
xstring(1,0.1,infobox,0,1);
boxh = gce();
boxh.font_style = 0; // Set monospace font

I agree, this forced trimming is often annoying.
There is here an easy workaround: use a 2-column matrix instead of a unique column:

t = ["abc"  "def"
     "ghij" "kl"
     ""     "mn"
     ];
xstring(1,0.1,t,0,1);



HTH Samuel
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Richard llom Richard llom
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

Hi Samuel,
thanks for the hint, that works nicely.

Regarding xstring is there a way to place it relative in the graph?

I.e. not at a fixed axis position, but at e.g. lower and left 10% of the graph?
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

Le 11/08/2017 à 16:10, Richard llom a écrit :
> Hi Samuel,
> thanks for the hint, that works nicely.
>
> Regarding xstring is there a way to place it relative in the graph?
>
> I.e. not at a fixed axis position, but at e.g. lower and left 10% of the
> graph?

AFAIK, only data coordinates are possible:
https://help.scilab.org/docs/6.0.0/en_US/text_properties.html
Otherwise, you may build your own routine to make the coordinates change
from axes-normalized to data.

Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Richard llom Richard llom
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

> AFAIK, only data coordinates are possible:
> https://help.scilab.org/docs/6.0.0/en_US/text_properties.html
> Otherwise, you may build your own routine to make the coordinates change
> from axes-normalized to data.

In both legend() and captions() are pos/ location handles available, like "in upper right". I think it would be reasonalbe to add this this argument to xstring as well. Hence I filled this bug:
http://bugzilla.scilab.org/show_bug.cgi?id=15245

Furthermore in captions:
""by_coordinates": the upper left corner of the captions box is given by the "position" field of the associated data structure. The x and y positions are given as fractions of the axes_bounds sizes."
This seems to be what I need, however I cannot figure where I can specify x and y?

Richard

PS:
Whats the difference between captions and legend anyway?
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

Le 14/08/2017 à 12:05, Richard llom a écrit :
AFAIK, only data coordinates are possible:
https://help.scilab.org/docs/6.0.0/en_US/text_properties.html
Otherwise, you may build your own routine to make the coordinates change
from axes-normalized to data. 
In both legend() and captions() are pos/ location handles available, like
"in upper right". I think it would be reasonalbe to add this this argument
to xstring as well. Hence I filled this bug:
http://bugzilla.scilab.org/show_bug.cgi?id=15245

I am afraid that you are making still worse the already very bad situation about
legends(), legend(), captions() and the leg= plotting options, that all basically
do the same thing, but all with pitfalls: http://bugzilla.scilab.org/5371

By the way, why improving xstring() in this way to make it legend-like instead
of using one of the existing functions? In one hand, you agree on removing duplicates
like xstringl() of stringbox() (http://bugzilla.scilab.org/14755#c1) . In the other hand,
you are aiming to make a 5-plicate ;) Arrrg.
I definitely disagree on making xstring() modifying the margins. IMO, it would be much
better a) to actually gather existing legends functions, b) to add missing features to the merged version.

Samuel


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Richard llom
I am answering separately to the secodn item:

Le 14/08/2017 à 12:05, Richard llom a écrit :
> Furthermore in captions:
> ""by_coordinates": the upper left corner of the captions box is given by the
> "position" field of the associated data structure. The x and y positions are
> given as fractions of the axes_bounds sizes."
> This seems to be what I need,
> .../...

Are you sure? .axes_bounds is a figure's property, not an axes one (this
is why it can't be specified in data coordinates). AFAIU, you would like
to have coordinates normalized either to the full axes, or to the full
data ranges. This .position coordinates could match your requirement
only when you have a single full scale plot in the figure (so no subplot
nor xsetech() other insets), and you want coordinates normalized to the
full axes (not data ranges).

Regards
Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Richard llom Richard llom
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Samuel GOUGEON
> I am afraid that you are making still worse the already very bad situation about
> legends(), legend(), captions() and the leg= plotting options, that all basically
> do the same thing, but all with pitfalls: http://bugzilla.scilab.org/5371

Ah, I wasn't aware of this...

> a) to actually gather existing legends functions, b) to add missing features to the merged version.
Well, I'm all favor of removing these duplicates, however I don't think xstring is one of them.

See my example at the very beginning of this thread. I'm using xstring to print some custom text, which AFAICS cannot be done using legends, legend, or captions.

Furthermore by unifying the syntax, between e.g. captions() and xstring() (i.e. by providing the same location options), this should simplify things - both from a user and code perspective!

richard
Richard llom Richard llom
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Samuel GOUGEON
> Are you sure? .axes_bounds is a figure's property, not an axes one (this
> is why it can't be specified in data coordinates). AFAIU, you would like
> to have coordinates normalized either to the full axes, or to the full
> data ranges. This .position coordinates could match your requirement
> only when you have a single full scale plot in the figure (so no subplot
> nor xsetech() other insets), and you want coordinates normalized to the
> full axes (not data ranges).

I see .. yes you are right.

The option to set normalized positions would really be nice, but specifying "lower left" would probably already be sufficient for me (see bug report).
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Richard llom
Le 14/08/2017 à 12:52, Richard llom a écrit :
I am afraid that you are making still worse the already very bad situation
about
legends(), legend(), captions() and the leg= plotting options, that all
basically
do the same thing, but all with pitfalls: http://bugzilla.scilab.org/5371
Ah, I wasn't aware of this...

a) to actually gather existing legends functions, b) to add missing
features to the merged version.
Well, I'm all favor of removing these duplicates, however I don't think
xstring is one of them.

See my example at the very beginning of this thread. I'm using xstring to
print some custom text, which AFAICS cannot be done using legends, legend,
or captions.

Right, because any legend block plots the legend together with a line's sample.
I forgot this "small detail" :(


Furthermore by unifying the syntax, between e.g. captions() and xstring()
(i.e. by providing the same location options), this should simplify things -
both from a user and code perspective!

As posted in comment of the wish report:

Being able to specify normalized coordinates relative to the data ranges or to any full axes range
would actually be very great, but not only for xstring().
IMO, implementing and distributing a function dedicated to this job would be very useful and better.
An option of it could be to provide the block of text, to take its size into account in the answer
(to make it not crossing the border or margin after plotting).
The locations by keywords like "in_upper_right" etc looks too stiff to me. The same should be possible
at any location, not only on borders or margins, and again, for all plotting functions.

xchange() could be extended. But it is hard-coded, so less easy to adapt (imo).

Samuel


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Richard llom
Le 14/08/2017 à 13:12, Richard llom a écrit :

>> Are you sure? .axes_bounds is a figure's property, not an axes one (this
>> is why it can't be specified in data coordinates). AFAIU, you would like
>> to have coordinates normalized either to the full axes, or to the full
>> data ranges. This .position coordinates could match your requirement
>> only when you have a single full scale plot in the figure (so no subplot
>> nor xsetech() other insets), and you want coordinates normalized to the
>> full axes (not data ranges).
> I see .. yes you are right.
>
> The option to set normalized positions would really be nice, but specifying
> "lower left" would probably already be sufficient for me (see bug report).

As a work-around, this is definitely the easiest location to point to in
data coordinates, since the block's anchor is set on its lower left
corner: If your x and y axes are not reversed, the following should work:
db = gca().data_bounds; // in Scilab 6, or  ax = gca(); db =
ax.data_bounds; // in Scilab 5
xstring(db(1), db(3), ...)

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Leading Spaces in xstring

In reply to this post by Samuel GOUGEON
Le 14/08/2017 à 12:44, Samuel Gougeon a écrit :

> I am answering separately to the secodn item:
>
> Le 14/08/2017 à 12:05, Richard llom a écrit :
>> Furthermore in captions:
>> ""by_coordinates": the upper left corner of the captions box is given
>> by the
>> "position" field of the associated data structure. The x and y
>> positions are
>> given as fractions of the axes_bounds sizes."
>> This seems to be what I need,
>> .../...
>
> Are you sure? .axes_bounds is a figure's property, not an axes one
> (this is why it can't be specified in data coordinates).

My fault: .axes_bounds is (obviously!) an AXES property, not a figure's
one. So yes, it would answer to your need... if there were no lines
reminders.

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users