Gentlemen, Welcome to the wonderful World of Margins !!!
As you're beginning to see, nothing is as it seems ... or so it seems ...
Remember though , that SimplePlot tries to be too clever for it's own good in 'automatically' re-adjusting things when the many parameters 'conflict'.
I'm still trying to get my head around it all.
Agustin, as well as Picture Margins and Page Margins there is Periphery, and also Group Margins.
You're probably right about %pl only plotting single graphs. For most that's all that's required I guess (doesn't mean it shouldn't be an option though).

As for log scales, the 3/30/300 look like they might be 'specific labels (but why they have been put there is anyones guess) since they are aligned differently (lower, better) than the major tick labels.

My heads hurting because, as an F77 stalwart, I'm struggling with some of the constructs you've thrown into your code Agustin !

Gentlemen, Welcome to the wonderful World of Margins !!!
As you're beginning to see, nothing is as it seems ... or so it seems ...
Remember though , that SimplePlot tries to be too clever for it's own good in 'automatically' re-adjusting things when the many parameters 'conflict'.
I'm still trying to get my head around it all.
Agustin, as well as Picture Margins and Page Margins there is Periphery, and also Group Margins.

Yes, I know, but I tried not to play with them because it would complicate the menu....

Quote:

You're probably right about %pl only plotting single graphs. For most that's all that's required I guess (doesn't mean it shouldn't be an option though).

I guess that the original idea of %pl was just to give the user a simple and fast way for plotting some data in a cartesian plot (see that there is no way to plot a surface, an histogram, a pie, etc., UNLESS you use the option user_drawn in %pl with a call-back function...).....and for a more complex graphs was of course the "elegant" solution of using %dw with the full power of Simpleplot.....in this sense, I find more useful to update Simpleplot than to increase the complexity of %pl, but it just my opinion.....

Quote:

As for log scales, the 3/30/300 look like they might be 'specific labels (but why they have been put there is anyones guess) since they are aligned differently (lower, better) than the major tick labels.

this is what I mean when I say that Simpleplot needs an update.....the way it manages fonts is not quite right......

well, that's Fortran 90.....I defined a derived data type variable in order to group together all the information about each curve.....each variable works like an array that can have many components but unlike an array, the component of a derived data type may have different types (integer, real, character, etc.).......I find this more straightforward and useful than defining arrays for line width, line colour, line type, etc......

I don't think the log-log happenings are a specifically %pl originated problem.
Modifying your last code Agustin (i.e. no %pl) with: CALL SCALES(1.0,100.0,2,0.1,1.0,2) , for example gives
a similar effect on both axes to that seen with Dan's code.

It should not affect the labelling...it affects the type of axis...if Simpleplot detects that the data includes the value of zero, it uses a linear scale instead of a log one.....if Messages.txt is allowed (if you avoid de call DIAGLV(0)), Simpleplot sends the following diagnostic: "Range through 0; linear scale used" .

There exist few more annoyances in Simpleplot. Like inability to use real*8 numbers despite they are declared as real*8. Try a=1d55 - it causes floating point violation.
Or sensitivity to initial data used which causes crash with "exception" diagnostics (and you scratch the head why it crashes. ). Try do i=1,100 instead of do i=1,1001
There exist one more problem which is superannoying. Try to make also array limit changeable and update the plot with simpleplot_redraw@. It does not work at all. In the code below versus previous one i just added adjustable size of arrays Ncurr for Simpleplot to plot
....800, 600, Ncurr, x, y, z, u) instead of fixed size N=999 in the past ....800, 600, 999, x, y, z, u)
to show that this does not work when you change it (click on red box). I may miss something, if not i hope this is fixable issue without Simpleplot source code. To work correctly i always close existing and open new window with %pl in it. Also hope fixable is Clearwin+ own minor bug in %tl when you try to use TAB size lower then 8 it also does not make any effect -see the arrow.

I think that the problem is not Simpleplot but %pl.....%pl has been developed to plot a simple plot in a straightforward way....I think we cannot ask too much to %pl.....for the moment...

I have modified my Simpleplot version of your program and found no problem with neither a=1d55 nor adjustable size of arrays Ncurr.....check my code (sorry I couldn't resist to include the classic BUSS logo....)...you will see that it is better to work with Simpleplot and not %pl, although I know that you have good reasons to insist with %pl...

By the way, I would suggest to start a new topic as what we have been discussing during the recent posts are not related anymore with Hershey fonts...maybe something like "Simpleplot and %pl plots"? .....you can decide the name of the new topic...

I think that maybe the problem is that %pl involves a single call to a Simpleplot plotting subroutine (BRKNCV or MARKCV) and it does it only once, i.e. you can redraw Simpleplot but not the curve(s). With SimpleplotRedraw@ you replot your original data, that was frozen to some extent, and if you have changed some things by calling Simpleplot subroutines (like AXLBLV, Pagvw, TEXTMN, AXLBJS, etc.) they will update those characteristics of the graph, but only those. See that in your code of the call-back function you are not calling subroutines for plotting whereas in my code I replot the data every time by including Subroutine plot_curves in Function bitmap. Try to change not only N, but x or y and I guess you will find the same behaviour....That's why Clearwin offers the possibility of using '%pl[user_drawn] with direct calls to Simpleplot....at least I guess so....

I suppose how %pl implemented is in total control of Silverfrost. When Simpleplot is doing anything it should look at its key parameters supplied by %pl if they dynamically changed or not. Almost everything in CWP right now works this way and if small portion of controls still not updatable then they definitely have to in the future

I still hope you guys find the hack to push the array size Ncurr down the Simpleplot throat through %pl. As I said I will not touch full Simpleplot with the 100 foot pole until Silverfrost will share full control of its source code OR like many currently existing graphics libraries not supported by its authors until it will be in open domain. That way if needed I will easily rewrite small %pl parts of the code to something else which is supported

You know how much time i lost on the bugs of SPlot? Just today 3 hours full voice swearing (was getting exception violations on 10 years old code). And i thought i know all its pitfalls. This POS somehow i still don't understand is sensitive to the data it plots even if it is in the real*4 limits range. How to find the error in this case if source is not available and using debugger is not possible ? If author would at least cleaned the source and got the major bugs out then being eternal betatester of SP would not suck so much

*** ***
*** THIS DISCUSSION TRANSFERRED TO NEW POST !!! ***
*** ***
*** DO NOT POST ANYTHING ELSE HERE PLEASE !!!! ***
*** GO TO NEW POST which has been set up, still in the ***
*** SUGGESTIONS Forum which is entitled :- ***
*** '%pl and Simpleplot graphs' ***
*** ... where this topic is continued ***
*** ***