forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

native %pl --> User-drawn Captions - Info. Reqd.
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Mar 28, 2018 8:53 am    Post subject: native %pl --> User-drawn Captions - Info. Reqd. Reply with quote

For quite a while we have had this workaround available to cater for the occasions when the automatic axes generation and/or labelling 'throws a paddy'.

Quote:
Setting [x-axis=@] or [y-axis=@] prevents ClearWin+ from drawing the caption which could then be drawn using a callback function.


I have a few questions relating to it:-

1. Is there an equivalent for suppression of the main title ?
If not can one be easily implemented ?

This would be very useful because often on graphs several lines of title are accomodated for clearer identification, also it would enable the possibility of changing the position of the graph title within the bounds of the available margins obviously) to be on any of the 4 sides of the graph.

2. To be able to accurately draw and position captions it's necessary to know what the 'available area' is.
The captions offset parameters are provided but they are 'hit and miss'. It's not really convenient when one has many plots to generate which may end up having different scales/labels/etc ....

To program in required user-defined captions I think requires:-

A. using the existing function GET_PLOT_POINT@ ), to " ... obtain the extremities of the plotting area ... called from within a %PL callback function in order to get the pixel coordinates of a particular point relative to the axes."

A clarification is required here .... are 'the axes' the screen pixel axes, or the graph axes (centred at bottom left of graphical area, or plot co-ordinates axes (x=0 y=0) ?

Also, I seem to remember from problems on certain plots that the position of the co-ordinates for log graphs isn't any of the above.
So, Can a clear and unambiguous drawing showing the position(s) of the axes be supplied and included in the documentation for reference ?

Also, for the 'automatic' plot case the axes maximum and minimum x and y values chosen are required as these may or may not correspond to the dataset maximums and minimums depending on the axes scaling algorithm implemented !
How can the user obtain those values ?

and also - Where exactly are the points - on the axes lines ? just inside them (i.e. the axes are plotted 'outside' the plotting area)? or where exactly.


B. knowing the extent of the plot 'components' outside the graphing area.
That's to say: the axes & ticks, the labels, and the spaces between them.
Also knowledge of the sizes margins on each side
I have drafted up an initial diagram (below) showing what I think are the minimum dimensions that need to be known in order to calculate where to put accurately and without interference user-drawn captions.

In some cases a lot of this info. will be known because the user will specify for example axes thicknesses, tick lengths, labels fonts and accuracy (hence allowing label lengths to be obtained) but in the fully automatic case, and other cases in between, all or some of these things remain unknown to the user..

Q. - is it possible to create a function ( e.g. GRAPH_PARAMETERS@ so that the user can obtain all these (and maybe other relevant) parameters ?

I may have missed a few things , details, but those should come out in the wash during discussion.

Here's a firděst draft of dimensions I think are needed :-

(Link to following Image UPDATED as of 10_04_2020)

P.S.
I noticed in the documentation for native %pl options that the inverse function GET_PLOT_DATA@ is:

a) subject to inaccuracy ?

b) not particularly useful - much more useful would be a point and click recovery of actual data aqt t
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Fri Apr 10, 2020 1:56 am; edited 4 times in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Wed Mar 28, 2018 4:29 pm    Post subject: Reply with quote

The [title=xxx] option is optional - if you don't use it then you don't get a title.

a) I don't think that GET_PLOT_DATA@ is inaccurate - a least not in the latest version.

b) The latest version includes [full_mouse_input], [box_selection], etc. from %gr. Then you can get pixel data from clearwin_info@("GRAPHICS_MOUSE_X").

This will be illustrated in a ClearWin+ demo program that will be released shortly (about two weeks).
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Mar 29, 2018 12:57 am    Post subject: Reply with quote

Thanks Paul for those clarifications.

By 'inaccurate' I meant by definition since a pixel is of a specific size clicking on it will only give the 'real co-ordinates' corresponding to the centre of it.
Hence even if you select exactly the specific pixel where a data point is plotted it won't necessarily give the actual value of the data at that point.
Think of the error being the rounding of the pixel co-ordinates to the nearest whole pixel.

What about all the other questions regarding getting the allowable areas where captions, titles, legends etc .... can be user-drawn ? (they're all in bold in the top post.)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Thu Mar 29, 2018 6:46 am    Post subject: Reply with quote

Hopefully the feedback that you need will be obtained from GET_PLOT_DATA@, clearwin_info@("GRAPHICS_MOUSE_X") and clearwin_info@("GRAPHICS_MOUSE_Y").
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Mar 29, 2018 10:18 am    Post subject: Reply with quote

Would be great to have specific font and size for the title. Right now the main title size is the same one as for the axis labels and this no matter how much you try never looks good.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Mar 30, 2018 8:47 am    Post subject: Reply with quote

Paul, I think you missed the point slightly, probably because I didn't explain clearly.
the need for this information is so that a program can be pre-programmed to have user-specified captions, legends, titles, etc ... without knowing what a first pass gives and then having to go in on a case-by-case basis and use the mouse to find the points I referred to and then change the program accordingly.
As such reliance on mouse-clicking to get the data is not on the menu (as it were). I'm not looking for an intractive solution for my application.

Surely the key dimensions I refer to in the diagram I posted are known at any given moment and could be output ?
For example for Y axis aptions - automatic default axes thicknesses, automatically generated tick lengths, axis tick labels length (max), apacing labels to caption, the starting point co-ords of Y (or X) axis captions (marked with asterisks on my diagram, then the font type, size, even maybe the height directly too.
If these parameters were made available the simple determination of where user-drawn captions could be drawn would be easy. Without it it's a stab-n-miss procedure which is not really satisfactory solution.

Surely those sort of parameters are known and easily outputable ? (outputable not actually being a word ...probably)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Sun Apr 01, 2018 7:34 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Mar 30, 2018 8:49 am    Post subject: Reply with quote

The intention is that the title is larger but I will check this out.

It's not particularly difficult to draw your own title via a callback.

It would also be a relatively easy addition to %pl (maybe an hour's work in total).
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sat Mar 31, 2018 8:39 am    Post subject: Reply with quote

Dan

The title is drawn using the current font at the point where %pl appears in the winio@ continuation list. You set the font before %pl and restore it afterwards.

The x and y axes captions are drawn using the same font reduced in size by the factor 0.85.

A new option to specify the font and size of the title is feasible.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Apr 01, 2018 7:37 am    Post subject: Reply with quote

... and maybe the same for the axes captions ? or at least be able to specify the reduction factor ? because otherwise if you want a 'bigger' title the captions will also be bigger ! (and likely too big)

You also overlooked my questions in my previous comment Paul.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Apr 02, 2018 10:28 am    Post subject: Reply with quote

Dan:
A new option [title_hfont=val] has been added together with a new routine winop_hdl@ so that val can be easily supplied. The font handle can be obtained from %gf and then used in winop_hdl@...

Code:
      iw=winio@('%fn[Verdana]%ts[1.2]%it%gf%sf&',hTitleFont)
      CALL winop_hdl@("%pl[title_hfont]",hTitleFont)


hTitleFont has type INTEGER(7).

John:
The font for the x and y captions is the current font at the point where %pl is used and the size is 0.85 of the current size.
I don't have an answer to your earlier question other than that it looks like a lot of work for little or no gain.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Apr 02, 2018 12:24 pm    Post subject: Reply with quote

Here is a link to a new set of DLLs together with updated documents and the new ClearWin+ demo mentioned above. This fixes various issues in the v8.30 release. The DLLs may not work with releases earlier than v8.30.

An updated document is provided for the new parallel processing/multi-tasking feature of FTN95.

The demo appears as demo.zip and this should be extracted to a new dedicated folder.

https://www.dropbox.com/s/a7cgpkacbz6cxuf/newDLLs22.zip?dl=0

p.s.
Unfortunately this version of clearwin64.dll contains an incomplete fix with the result that SDBG64 always fails to start. The download has been removed pending further tests. I apologise for this oversight.


Last edited by PaulLaidler on Thu Apr 05, 2018 7:37 am; edited 1 time in total
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 04, 2018 8:39 am    Post subject: Reply with quote

any update on the v8.3 Personal version release ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Apr 05, 2018 11:36 am    Post subject: Re: Reply with quote

PaulLaidler wrote:


dropbox_com/s/a7cgpkacbz6cxuf/newDLLs22.zip

p.s.
Unfortunately this version of clearwin64.dll contains an incomplete fix with the result that SDBG64 always fails to start. The download has been removed pending further tests. I apologise for this oversight.


Yesterday, when you had not yet posted this P.S., I tried to act on one of your suggestions in another thread, and decided to try newDLLs22 with FTN95 8.10 Personal. Everything else worked as usual, but when I started SDBG64, I received a ClearWin64 pop up saying
ClearWin wrote:
For error reports you must have an FTN95 licence from Silverfrost".

At this point, I reverted to the older set of DLLs. Was this restriction intended?

Thanks.

[I have mangled the URL so that readers will not get a 404 by clicking the link.]
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Thu Apr 05, 2018 8:50 pm    Post subject: Reply with quote

No. The restriction was not intentional.

p.s.
In fact the message is the direct consequence of SDBG64 failing because of an error in clearwin64.dll. If you had a licence then you would get the actual error message which would be of no value because it relates to code in SDBG64 and in any case is false.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Apr 06, 2018 9:33 am    Post subject: Reply with quote

Paul
I find the graph_parameters@ John-Silver is suggesting to implement would be great for complete control of plotting process in native PL. My only change/suggestion to it would be to use relative numbers for everything not pixels which is basically the same but more universal if we scale the plot increasing or decreasing its size.

I suggest to consider even to completely switch native PL to relative numbers like in other Professional graphics software before many people started using native PL. In this case the Fortran text will be the same when you scale the plot. By relative numbers I mean pixel value divided by the entire width or height of the plot. All the numbers will be below 1. For example left margin will be 0.15, top one 0.2, right one 0.05 etc. The relative width of lines of course in this case will have too small numbers so there arbitrary numbers can be used. In Origin for example the line with 0.5 means very thin line, 1 - pretty thin, 2 and 3 are pretty much close to bold line etc
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group