@Jonarw just wondering if I could get your opinion on some naming. I'm wondering if OuterMargin should be Margin, and Margin should be Inset (I would have called it padding, but that's taken).

I've finally addressed all the little concerns I was putting off, so I'm opening this for review.

Regarding naming, just as an idea: How about we call the OuterMargin TickMargin and the Margin SeriesMargin?

Other than that I'll take a look at the code soon.

@Jonarw that's a great idea! I'd be tempted to go for DisplayMargin (to correspond with DisplayMinimum and because it also applies to clipping and gridlines and the axis line itself), and I'm not sold on SeriesMargin, but they make the semantic distinction that I was completely ignoring before.

On the other hand, this only becomes an issue if MinimumMargin != 0, correct?

Yeah, that's absolutely the idea.

I still wonder if we could make the difference between DisplayMinimum and ActualMinimum more obvious from the naming

Yeah, I'm by no means attached to any names, and an option I've still not fully would be to 'rename' DisplayMinimum as ActualMinimum, and rename ActualMinimum some other way. I'll take another look at that over the weekend, because I think ActualMinimum is only really used internally, so using it as the display bounds would limit the another things that break.

Sorry, squashed everything because I thought I'd made a mistake with the revert, but it was just conflicts in the changelog...

Over the weekend I concluded it would be perfectly reasonable to change DisplayMinimum back to ActualMinimum (which corresponds to most existing usage, since it has always been informed by display concerns). ActualMinimum has been renamed to LogicalMinimum. Since they are what one would traditionally consider margins, I've renamed the MinimumOuterMargin to just MinimumMargin (i.e. I don't think a prefix like Display is necessary; Actual would just be weird), and renamed the MinimumMargin (the 'inner' one) to MinimumLogicalMargin.

I think names for the 'outer' stuff (i.e. what is now ActualMinimum and MinimumMargin) are better, but I'm not happy with Logical for the inside stuff. Possibilities:

• Logical
• Data
• Series

Again, I'm not attached to any of the names, so any suggestions are welcome.

Because Actual has become Internal, I've renamed CoerceActualMinMax.

Looks like Snyk is unhappy with me again.

@Jonarw feedback addressed. For the record, my only reservation with Data and Series is they don't make sense when the user starts interacting. I don't like Logical because it doesn't convey anything at all.

@objorke I wondered if you might have time to provide an opinion on the naming? It's probably easiest just to look at the grey screenshot above to see the current state of naming. Actual I think will stick (because it provides backwards compatibility), but Logical (the bounds determined by data min/max + padding or user interaction) doesn't fill us with joy.

[ ] Update the changelog when we settle on the naming
[ ] Couple of Update methods that need renaming; double check Zoom makes sense

A big issue has just occurred to me while looing through the axis tests: the ActualMinimum/ActualMaximum are no longer known until the plot renders (they can't be known until the plot measures itself, and currently these happen at once).

I've not noticed any weirdness anywhere, but someone could be calling IPlotModel.Update and expecting that to update ActualMinimum (as it would before), only to find it isn't updated, and that LogicalMinimum isn't what they want. What they want is to be able to measure/layout the plot (see #391). This provides a case for changing Logical back to Actual so that it is updated when expected.

Maybe a slightly crazy idea:
What if we avoid this whole naming conundrum by completely removing ActualMinimum and ActualMaximum (or at least marking it as obsolete, redirecting it and mentioning the new properties in the obsolete message)? Then people will be aware that something changed here and can choose the appropriate property themselves.

A possible naming scheme could be:

ActualMinimum -> TickMinimum
LogicalMargin -> DataMargin
LogicalMinimum -> ??? maybe SuggestedDataMinimum or DataMarginMinimum or DataMinimumWithMargin or ???

Just brainstorming, feel free to completely dismiss all of this ;)

I think I'm slowly coming coming to like Data as the prefix for the inner bounds and margins... but I'm also rapidly coming to the conclusion that I'm not going to be happy with anything until someone can call Measure on the PlotModel and find out the outer margins. I'll have another look at that today.

Obsoleting and redirecting ActualMinimum etc. sounds like a plan to me... that or it should be the inner bounds so that it is always up-to-date.

I've gone with ActualMinium this time, determined by DataMinimumMargin; and ClipMinimum determined by MinimumMargin. The rationale is that ActualMargin is the exactly the same as ever when the Data margins are zero. While the match is worse when the Data margins are non-zero, the Clip margin is only known at render-time, and we don't want that to be true for ActualMargin because that would be nightmare inducing silent change, and the odds of old-code being updated in response to it being marked obsolete are probably quite low.

I'm not happy with Clip, but Tick is too specific I think. I'm gravitating back to Display, but I don't have very objective reasons.

If we can expedite #1556, then we can hopefully do a nice job of #391 (because we can split IRenderContext and ITextMeasurer), and then the outer bounds can be computed before rendering, which will make me feel much better (and deal with #1621), but I think keeping Actual as it is now is the right thing to do, whether we make it obsolete or not.

@Jonarw any other comments on this? By keeping the Actual min/max as they are, the changes shouldn't change any existing behaviour.

The only thing that I'm not especially happy with is the Clip prefix, for which some options are:

• Clip: it is indeed used for clipping, but that's not its logical purpose
• Display: it is indeed the limits of what is displayed, but if I was asked to guess what a Display bound is, I would say it had something to do with monitors
• Tick: it does indeed limit the ticks, but it also limits other things, and could be confused with the smallest and largest values on the actually presented ticks
• Data: an argument could be made for DataMin and DataMax to go with ScreenMin and ScreenMax, since they are analogues of one another. I didn't like this when I started writing this entry, but it's pretty tempting now.... (though it's probably inconsistent with DataMargin)

Note that the Clip bounds can be changed by the StartPosition and EndPosition also.

Sorry, I was away for a couple of days.

DataMinimum sounds nice in theory, but is actually already taken and represents the minimum value of the data displayed on this axis.

I don't think there is a perfect option, but I guess Clip will have to do.

So I'd say, if there is nothing more from your side, this should be good to go.

@Jonarw thanks. I'll hold on for the moment, but when I have time to start working on things properly again I'll get this merged (assuming no other problems comes up).

Plan for the weekend:

• Review what's already here (in particular, the documentation and changelog)
• Review ScreenMin and ScreenMax: half of the values are nonsense... but I need to need to check how they are used. A fix will probably go into another Issue/PR, but I want to check it won't throw up any problems with this
• Get this merged

@Jonarw I've not checked if there are conflicts, but if #1661 goes through today, I'll try to get this though as well (nothing much else to do today). Then I think it's worth thinking about a 2.1 release to get Skia out there, but I'd like this feature too ;). If we think a release is a good idea, we should quickly decide whether #1556 should be included or not. My main concern is that I don't know who to test it properly with non-latin script. I think by bringing the test trimming 'in-house', issues like #1659 should stop occurring.

I'm guessing there are no major changes since I last looked through the code, right?

One more thing that occured to me - we have this nice example:

Could the subtitle state the exact names of the related properties in code, e.g. ClipMinimum etc.?
(Or if we want to be fancy this could be even done with some TextAnnotations in the plot, but I guess that's not really necessary)

@Jonarw How about this?

I don't think anything has changed; I think I was just working on the examples. I still need to go through all the documentation again for my sanity, which I'll get on with now.

Yes, I think that's good.
I think it's good to have a place to look when I forget which property is which (and to have somewhere to point others if the question comes up).

Rebased. I've nothing else to add.