There are two separate issues here. One is making sure the overall plot keeps a nice shape when the window is resized - like if you have a responsive webpage, it would be cool if the plot could take its width from the container element and its height from this aspect ratio. That should work fine with layout.aspectratio.

The second is where the data on a plot has a 2D metric, like if you're showing physical positions in two dimensions, or in momentum space, really anything where x and y have identical units so relative scales and angles are meaningful. The first (layout.aspectratio) can be used to solve this problem, though not if you allow zooming, not if you allow auto-margin, and anyway you have to do a bunch of calculations to get it right even in the beginning. Really we need something per-subplot that enforces pixel equivalence in the two directions. This is tricky for a multitude of reasons:

API - as already mentioned, we don't have per-subplot settings for cartesian, we only have per-axis settings. That might be a blessing in disguise though, as you can't have more than one constraint per axis.
- one option: define axis.constrainwith and axis.aspectratio. I would think that if you provide neither, then both are omitted, but if you provide constrainwith then aspectratio defaults to 1, and if you provide aspectratio then constrainwith defaults to axis.anchor, or the first counteraxis if anchor=='free'.
- another option: define something like layout.xy_aspectratio which could perhaps be just a number for simple plots (or to give all subplots the same ratio), or an object like {xy: 1, x2y: 2} (my comments below about couplings should apply just as well if we choose this form, except that the obviously silly contradiction wouldn't be possible, but a circular reference could still be created out of 4 subplots).
couplings - what happens when you have two subplots sharing an x axis, with two y axes that both want to enforce an aspect ratio? We could certainly start out allowing only one constraint per axis, but eventually someone will want subplots sharing an axis and both to have aspect ratio constraints. But with a 2x2 or bigger layout, if all x and y axes had aspect ratio constraints you could actually define a self-contradictory system:

xaxis: {constrainwith: 'y', aspectratio: 1}
yaxis: {constrainwith: 'x2', aspectratio: 1}
xaxis2: {constrainwith: 'y2', aspectratio: 1}
yaxis2: {constrainwith: 'x', aspectratio: 2}

In fact you could say something obviously silly:

xaxis: {constrainwith: 'y', aspectratio: 1}
yaxis: {constrainwith: 'x', aspectratio: 2}

I think for the most general case we need to allow both x and y axes to define constraints, otherwise there would be no way to create a legitimate fully-constrained 2x2 layout, or even three subplots (central, top, and right, for example). We could just say it's an error to define a circular constraint reference, that should avoid this problem.

conflict resolution - say the user specifies both x and y ranges, as well as aspect ratio. What do we do? It seems like we want the aspect ratio to be enforced, and probably only show more than what was asked for, ie never reduce a range, only expand (symmetrically). Similarly for autoscale, just symmetrically expand one axis. But then what happens if someone resizes the plot multiple times, does the range keep growing (ie the x range grows when you make the plot wider, then the y range grows when you make it narrower...)? Or does it somehow remember what the last range was that the user really asked for, and size based on that? Maybe it would work to have layout just keep what the user asked for, and _fullLayout the recalculated (expanded) ranges?
zoom - I already had to do one form of constrained zoom for ternary Ternary phase diagrams #390 - and I suspect we could do something similar here for the main zoom... like the smallest rectangle that contains the start and end points of the drag, centered in the direction that needs to be bigger than you've dragged. But for ternary I totally ignored the single-axis and corner draggers. At least initially we could do the same here too, though I imagine we could come up with fairly compelling arguments as to what should happen with each of these draggers. Corner draggers could just project your drag onto the diagonal from that corner to the opposite one. Single-axis pan draggers (and 2D pan) are no problem as they don't alter aspect ratio. Single-axis endpoint draggers (And again for coupled subplots, where one axis change is triggered by the main or corner draggers of a different subplot), the obvious choice seems that the counteraxis should get a symmetric change keeping the same center point.

Uh oh!

Aspect ratio key for 2d plots #272

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions