Add support for DrawText maxSize parameter to all platforms

[Jonarw]

As became apparent in #1558, not all IRenderContext implementations support the maxSize parameter of DrawText(...).

I think we could address this by:

• Remove the maxSize parameter from IRenderContext.DrawText()
• Add a RenderingExtensions.DrawText() extension method with the maxSize parameter
• Implement this functionality using a combination of text measurement and regular clipping

That way I think it should be possible to get this to work on all platforms that natively support clipping.

I might have a look at this later.

[VisualMelon]

I have also been thinking about this with respect to #1556, where a common method to perform text arranging could handle computing/intersecting clipping rects also (currently it throws if given a non-null maxSize).

The WPF behaviour seems to be to equivalent to clamping the bounds of the whole block of text before arranging it, and then effectively rendering the text in the top-left corner. I'll try messing around with this later on today.

[VisualMelon]

Irritating, I think the clipping has to be done on the text itself, because clipping rects are non-rotational.

[VisualMelon]

I've thrown together maxSize support in 1df261a (see #1556, where it is implemented for SkiaSharp) using a binary search to reduce the string. It's not properly tested, but I thought I'd push this now as a POC now because I might be busy tomorrow.

[Jonarw]

The more I think about this the more I realize that this is a feature that brings a lot of complications when we want to support it properly. Especially when it is combined with multi-line text and rotation. I am wondering if this is really worth the trouble?

After all, I think pretty much the only place where this is actually used is to clip axis titles and (since recently) plot titles. Is there an easier way we could achieve this?

Just a thought: Could we remove the maxSize functionality alltogether and change the few instances where it is actually used such that they just set an appropriate clipping rectangle?

[VisualMelon]

I guess it depends on what we want. From my perspective, the current WPF behaviour is undesirable, because clipping by pixel produces partial glyphs that could be misleading, and can otherwise fail to convey that anything has been trimmed. I'd prefer something equivalent to WPF's CharacterEllipsis. This is what people are used to from e.g. Windows Explorer. This would be easy to add to #1556 for example, and it would be easy to switch WPF and GDI+ to use these methods as they are built in.

You mentioned not encountering it in usage, and I'll second that experience: if anything were ever clipping then I would make the plot bigger to accommodate, but I usually have the freedom to make them any size I want where others might not. Maybe we should try to solicit input from people who do rely on it (e.g. @UndisputedBasement33). I'm certainly happy to go to the trouble of implementing all of this if we can put it all in one place.

[UndisputedBasement33]

I would also prefer the CharacterEllipsis rather than just clipping by pixel.

In my (windows wpf)-App I have a Tab with in total 6 PlotViews. Each plot has a title, that fits nicely, if the app is started. But since the user has the possibility to change the window size the plots scale accordingly. I want to have this behavior because even the smaller plots deliver the information that is necessary. But at some point the size is that small that the title doesn't fit anymore, and then the titles of the plots next to each other start to overlay:

(the pictures are from the released Oxyplot version, without clipping functionality)

Standard:

Scaled:

As you can see the title overlays even space that is not assigned for the plotview (means it goes out of the border of the groupbox and overlays even the border of the whole app)

[VisualMelon]

@UndisputedBasement33 thanks for commenting: I'll be sure to add CharacterEllipsis to my work in #1556 in my next round of changes so we can evaluate it.