forums.silverfrost.com

PaulLaidler · Posted: Fri Jan 06, 2017 5:21 pm Post subject:

Dan

I can't do any more development on this for now. After the next full release we aim to revisit this subject and consider if there is a better way to get this kind of facility to the user.

DanRRight · Posted: Sat Jan 07, 2017 4:58 am Post subject:

Paul,
Here are few other problems after I tried to plot in LOG-LINEAR scale.
On top for comparison is the same data plotted in scientific graphics software OriginLab. In this software when you increase or decrease image using mouse it proportionally scales all elements making the whole plot perfect for all sizes even the thumbnail one. That is what I was advocating to implement in %pl. Hope you will soon find the time to return to %pl.

PaulLaidler · Posted: Sat Jan 07, 2017 8:42 am Post subject:

Thanks Dan.

DanRRight · Posted: Sat Jan 07, 2017 10:45 am Post subject:

As a good point one can note from these two pictures above that with its antialiasing FTN95 beats professional graphics software in line smoothness quality -- it produces MUCH less visible jaggedness.

Here is one more small defect with axis numbering. Plotted with different data set but this thing is pretty reproducible with almost any. Also, in this plot antialiasing is switched off so one can see the sharp edges of lines

PaulLaidler · Posted: Sat Jan 07, 2017 11:27 am Post subject:

Thanks Dan. For now you will probably need to use a smaller font size.

DanRRight · Posted: Mon Jan 16, 2017 1:27 pm Post subject:

I do not know if this bug below should be fixed or we have to wait when the entire way of plotting LOG functions should be changed.

1) As i wrote that for example LOG_LINEAR way of plotting in new %pl is inconvenient as it requires LOG10 of all Y values. As the new %pl is in early development it would be easy to change things completely to the way older %pl doing same things. But may be it would be still a good idea to fix the current plotting way too. This simple annoying bug in tic numbering makes sometimes almost impossible to use %pl.

Here is the text for plotting of some simple function (i took y=x) where some y(i) take large values,like for example y(1)=1e20. In this case some tic marks here get crazy, like instead of 1e9 we see 1e909e7 etc

PaulLaidler · Posted: Mon Jan 16, 2017 1:32 pm Post subject:

Dan

In the next release I have taken logarithmic scales out of the native %PL until I get more time to work on this.

DanRRight · Posted: Tue Jan 17, 2017 2:54 pm Post subject:

This bug looks easy fixable, may be it is worth for now just to fix it?

Also the question: why it was chosen to define the line width this way which is harder to change dynamically

PaulLaidler · Posted: Tue Jan 17, 2017 5:03 pm Post subject:

Unfortunately I don't have time to do anything more on this at the moment.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Paul,

I am using a recent download of libraries date stamped 5/11/2016 10:29am
(I am not sure if this is the file date stamp, or the download date.)
I think I got it from this thread.

When I run my graphics program I get the message:
" Argument number 2 of WINIO@ (continuation 113)
should be an INTEGER(7) at address 1c007ee9"

The traceback gives:
In scc_lib_version at address C4
In clearwin_error at address 14E
In _set_edit_delay at address 1361
In _set_edit_delay at address 209B
In _winop at address 501B
In _winio at address 87E
In WINDOW_PRINTF$$ at address 15A
Within file saplot.exe
in TEST at address 514

This has me a bit stumped, as I have checked all WINIO@ arguments and can not find the problem. I have used INTEGER(7) for all handles or previously INTEGER*8.
(continuation 113) is not easy to locate !

Ver 8.05.00 (17/06/2016) does not produce this problem.
Could the problem be in something else, say a function call ?

My 64 bit attempt to get the date stamp of the .dll is:

PaulLaidler · Posted: Tue Jan 24, 2017 8:22 am Post subject:

John

I think that there was a point where the beta DLLs got out of step with the last full release of FTN95. You may need to use the DLLs downloaded via a link in the current thread about %PL. If you can wait a little while, a full release is expected soon when hopefully everything will be sorted out.

DanRRight · Posted: Tue Jan 24, 2017 11:08 pm Post subject:

John-Silver, I am sure Paul knows himself many these defects even without our mentioning. This new %pl is just in beta state, or, better say, even pre-beta. Just first attempts.

I will tell you based on my experience with 2D graphics, that it is actually not easy to make this graphics stuff look perfect from first attempts. It took me many years just to make it look not like utter ugly cr#p. And based on the same experience i may say even more: there were may be just couple run-time graphics packages which you can embed into your running codes in the entire history of computing which make regular XY plots look not like a cr#p.

I just hope to shorten potentially long try and fail attempts if we will show the best examples to follow and warn to avoid dangerous minefields. One of these fields is to use pixels as plot units. And i afraid this already took place with first version of new %pl. The plot design must be based on the entire X and Y dimensions of the plot and everything else must be based on percentage from these X and Y sizes (besides may be axis and line sizes which good to measure in pixels). That will allow to create scalable size graphs where the plots will look perfect with any magnification