#673 Autoscale logic now has a margin


The current autoscale logic has no consideration for a margin, which makes for very unclear plots in some cases. For instance, look at the output of this:

gnuplot -persist -e 'plot sgn(sin(x))'

This is a square wave, but the top/bottom edges lie exactly at the plot boundary, so you can't see them. The current autoscale code expands the view to the next tic. In this case, the curve edges lie on a tic exactly, causing the problem. I'm attaching a patch that adds a 10%-of-tic margin to the autoscale logic.

1 Attachments


  • Ethan Merritt

    Ethan Merritt - 2014-04-15

    Separation from the plot borders is already possible under control
    of the command "set offset".
    set offset .01,.01,.01,.01
    set auto noextend
    plot sgn(sin(x))

    I think that's better than tying it to the current tic interval.

  • dima

    dima - 2014-04-24

    Hi Ethan. I replied to this earlier, but sourceforge apparently doesn't believe in using email.

    I've been thinking about this, and I'm not sure I agree. The current code already aligns the viewport to the tics. All this patch does, is expand to the next set of tics, if needed. In any case, I do think the current behavior is a bug since it's very easy to make a plot where a chunk of the data is invisible by default.

  • Ethan Merritt

    Ethan Merritt - 2014-04-28

    I do not like the extra space. The problem is that although the patch per se only adds a fraction of a tic-interval, the autoscaling code bumps this up to the next full tic. That can be quite far away.

    It is particularly strange when added at the bottom of a plot that would otherwise have the x axis at y=0. Consider for example the 2nd plot in "using.dem", or indeed any plot style that uses 0 as a baseline on y (impulses, boxes, histograms, ...). I think it makes no sense to raise the visual baseline by extending the plot to some negative value. "mgr.dem' is another one where the extra margin is unfortunate.

    3D plots come out strangely also. For example "contours.dem", where the extra space around the contours gives the impression of an incomplete plot.

  • dima

    dima - 2014-04-28

    OK. Those are fine points, and I need to think about how to resolve those. Do you have any thoughts about it, or do you think the current state (where a square wave plot is pretty much unreadable by default) is reasonable?

  • Ethan Merritt

    Ethan Merritt - 2014-04-28

    In the end only you yourself know what the plot is supposed to look like. No set of defaults will be optimal for every case. I can think of several commands that would avoid your square waves being hidden behind the borders:
    - set offset (adds empty space around plot)
    - set border back (plot line will be drawn on top of the border line)
    - unset border (do not draw the border at all)


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks