@tacaswell
Thomas, I have created the pull request to get your feedback. Do you think this is the correct and complete solution for#2150 ?
I have tested horizontal and vertical bar graphs with leading and trailing zeros and it gives the correct and expected output.

If so, I will add image tests and polish it for merging.

It seems reasonable to me and all of the tests pass, however I am worried about un-intended consequences.@efiring or@mdboom should sign off on this on.

If there is not some compelling reason that this logicmust be anor, this is much better than the proposed solutions of passing extra hints to the auto-limit code.

One of the fun things about a large code base is you tend to assume things are done some way 'for a reason'.

I am a bit concerned by the 'merge from master' in the history. Our practice is to keep re-basing branches if the conflict with master.

The comment in update_patch_limits says the rationale for "or" is that otherwise log scaling has problems. I don't know offhand whether this is still the case, and if so, whether there might be a better solution to that problem. Apart from that, the "and" proposed here seems reasonable.

@sfroid This needs to be rebased (conflicts in CHANGELOG).

Did you get a chance to investigate how this interacts withlog?

It seems to work fine with log-scaling.

Closing because I merged the non-merge commits on a local machine and pushed to master.

@tacaswell - I know it adds a small overhead, but would you mind linking to the change if you end up doing it by hand? It just makes it easier to find what has gone on where. Thanks 😄

Sorry about that, I will take care of this next time I am at a real computer.

Merged in899f11d