%pl[frame,scale=linear_log]

Paul,

Something that needs looking at when you have time. In the second %pl graph the options frame and scale=linear_log are used. The resulting plot is not correct. Please see my mark up here:

https://www.dropbox.com/scl/fi/whuaiw6wfwhy8zpu0r6ss/Screenshot-2025-08-13-120045.jpg?rlkey=pqjut46zi1uabeqk6netkmbtk&st=rl1kaxh5&dl=0

program p
use clrwin
implicit none
integer, parameter :: n = 100
integer :: i, iw
real*8 :: x(n), y(n)
real*8 :: xend = 10.d0**3, xstart = 10.d0**(-1), twopi = 8.d0*atan(1.d0)

  ! Log spaced x values
  x = [( 10.0d0**(log10(xstart) + (i-1)*(log10(xend)-log10(xstart))/(n-1)), i=1,n )]

  ! y(x) = sin(2pi * log10(x)) will produce a repeating sine pattern evenly
  ! spaced on the semilog x-axis so you can immediately tell if the x-axis
  ! is scaled correctly.
  y = sin(twopi*log10(x))
  
  iw = winio@('%fn[Tahoma]%bf%ts&',1.5d0)
  
  call winop@('%pl[n_graphs=1,native,width=3,gridlines]')
  call winop@('%pl[colour=red,x_array,scale=linear_log]')
  iw = winio@('%ta%pl&', 600, 600, size(y,kind=3), x, y)
  
  call winop@('%pl[n_graphs=1,native,width=3,gridlines]')
  call winop@('%pl[frame]')
  call winop@('%pl[colour=red,x_array,scale=linear_log]')
  iw = winio@('%ta%pl', 600, 600, size(y,kind=3), x, y)
end program p

Thanks. I will take a look at this.

Ken

All the tick values ought to be at the bottom when using [frame] and I have fixed this. The alternative [framed] works correctly in this context.

Ken

I added

call winop@('%pl[y_min=-1.005]')

to both for the graphs in your code in order to display the lowest y value and grid line.

Paul, Thanks for the recent DLLs with updates.

Your suggestion of call winop@('%pl[y_min=-1.005]') got me thinking. The “obvious” value for y_min is -1, and where does the additional 0.005 come from?

Suppose the y data ranges from ymin to ymax, then the corresponding “nice” range for the y axis might be yminp to ymaxp spanning y_range = ymaxp - yminp

The range of the y_axis in pixels is gh – top – bottom, where gh is graphics depth and top and bottom are margins. All of these are known or can be calculated. Call the resulting integer value y_range_pix.

So we can calculate y_per_pix = y_range/y_range_pix. Where the correction is required to show the minimum y value the additional value (subtracted from the obvious ymin value) is y_per_pix.

This correction can be calculated dynamically at runtime, allowing the graphic to be stretched vertically via a pivot, or if the data changes.

The code below explores this idea, although probably needs more work!

https://www.dropbox.com/scl/fi/9chqvm9bigraz35kja5fv/set_ymin_auto.f95?rlkey=ssybl8p69wjt5aqhzlea0j7ap&st=i4hjkmi9&dl=0

Ken

The additional value was just a guess at something to make it work.

%pl could probably be improved in this respect but I don't know how much time it would take.

Changes of this nature must of necessity be minimal in order to avoid breaking existing usage.

Paul,

I too have been guessing the value when I’ve encountered the problem in cases where the limits are well defined.

The relationship:

Yminpl = Ymin_desired -  (Ymax_desired - Ymin_desired)/(graphics_height – top_margin – bottom_margin)

may be useful to others encountering this problem and eliminate guessing - particularly as the y data range and also the size of %pl region and its margins change.

The “correction” is only required if ymin_desired .LE. 0.0 and ymax_desired .GE. 0.0 are both true.

I got rather carried away testing different values and adding pivots to test this yesterday! The program I posted obscures the simplicity of the underlying calculation.

Thanks Ken. That is helpful. I will see what I can do.

Ken

I have made some adjustments in order to include your formula.

Thanks Paul, That should eliminate some guesswork!