Well running the code of 21st April post (which is same Ithink as the code in your zip file) with DLLs8 I have no problem with compilation (which you did with dlls7), and the Y scale looks fine with integer values plotted on the scale.
X-scale title is still right-justified.

I did however have to delete the code of the first %ww (with the 'original' plot) because it went off the bottom of my screen and no way to view it !
Even re-sizing by hand didn't help because no scroll bars.
I'm confused as to why, I was actually expecting 2 seperate windows. Why does it produce everything in one window (all in the second one: 'Default Window' ) ?

Vertical window positioning was taken because i used large resolution 3840x2160 (4k TV as a PC monitor).

/** which i also recommend to everyone - this is way cheaper and infinitely better than any non-4k real PC large monitors in the world. Latter one because there are no PC monitors of size ~50" but this is exactly the minimum size all monitors have to have. As the owner of many top notch monitors in the past (i hated some of them despite their sometimes $3-4K price tags) i will assure that you will be stunned both with the improved quality of work and entertainment. Also, before, couple years back, only NVIDIA 900 series videocards worked with 4K monitors via HDMI ports, but today probably all work (the only condition for good text rendering is that the monitor has to support 60Hz at 4:4:4 chroma simultaneously. And if your kids play games on it then it has to have also small input lag ~25ms or less in game mode. There such good chroma bandwidth is rarely needed. Consumption is by the way only 72W in my case of 50", less then for 2-3x smaller CRT monitors).

finally got back onto the benchmarking on my machine.
thanks for the file Dan and the mod to get everything on my screen.

I don't see all the problems you commented on on 8th May.

Re-sizing doesn't do strange things with axes scales.

I did notice one small thing which hasn't been mentioned before -
the very first label on x-axis scale is not centre justified over tick -axis tick mark, it looks like it's left justified against the left extreme of the y axis tick mark just above it.
A small and subtle discrepancy.
This is presumeably to avoid clashing of the x-axis and y-axis lbels when they both exist ?

The curves still plot out of the graphic area.
To note here, playing around with an Excel plot (chart), they too extend beyond the borders of the graphic frame but only marginally. Just enough to indicate that the curves go out of bounds but nothing drastic like we have in ftn95 at the moment
.[/img]

Last edited by John-Silver on Wed Jun 21, 2017 8:42 am; edited 1 time in total

I also havee the same quažestion as Dan, 'what does this ENUMERATOR code do ?'
... and that might clify to me what you mean by 'replace it with PARAMETER' (or maybe it won't ! , at the moment I have no idea what you mean)

Thanks Paul. I found myself looking at the native %pl again today after 6 weeks doing other things and rediscovering some of the minor issues for a second time - my memory is not as good as it used to be - hence the question.
Ken

1) With the latest DLLs i found that the code produces initially bad looking Y scale numbering and goes out of scale, see for example this simple code (the code for plotting must be always short and simple like this or even shorter)

But if you try to resize the plot just a tiny bit pulling window border or corner using mouse it abruptly displays everything correctly.

Interesting is that if we change one number 8333 to 3333 this trick does not work

Probably will be easy to fix.

2) I hope that in the future after fixing all the bugs Silverfrost will make the default plotting with the one simple command like with the code above and the plot will look nice and perfectly ready for publication. This is how Matlab is doing that flattening competition landscape for decades. Of course it is easy to do all the "beautifications" with just one-two more lines of code like here

But my previous two decades experience with the hundreds of uses of Simpleplot in my codes tells me that beautification takes a lot of time so that you end up with no any. As a result many my plots which were quickly made look ugly like the first picture above, and there is no time to change anything because any touch to the working CWP code always causes many recompilations, CWP has a lot of intricate details you always forget.

This nicer looking example shows the defects of absence of Scientific, Decimal etc numbering formatting options: the numbering does not look concise, in one style, it mixes different styles.

3) As to the numbering formats of LOG plots we here suggested to introduce few distinct user-definable formatting options: Scientific (numbers shown as 10^0, 10^1, 10^2, 10^3 etc) and Decimal (1, 10, 100, 1000...). All these ( and few other options like Engineering (1e0, 1e1, 1e2, 1e3) and Decimal with FP (1.0, 2.0, 3.0) ) are already there, they just need to be introduced into the user changeable settings.

With the LOG scale it is often possible for the code to choose these formats automatically: if the numbers are very small or very large and there are a lot of orders of magnitude to display then just the Scientific format has to be used

At the end here how this exact XY data is visualized by the professional scientific software using Scientific and Decimal formats. As you can compare the new %PL is already pretty close to the best of the best (the new PL can also do antialiasing for curves and in this example is even better doing data interpolation - compare how 8333 peak values are displayed)

Decimal format is of course the most difficult. If extend the plotted data to