You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for DrawText maxSize parameter to all platforms #1559
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.
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.
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?
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.
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)
@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.
Activity
VisualMelon commentedon May 11, 2020
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 commentedon May 11, 2020
Irritating, I think the clipping has to be done on the text itself, because clipping rects are non-rotational.
Support maxSize in ArrangeText (oxyplot#1559)
VisualMelon commentedon May 11, 2020
I've thrown together
maxSizesupport 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 commentedon May 12, 2020
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
maxSizefunctionality alltogether and change the few instances where it is actually used such that they just set an appropriate clipping rectangle?VisualMelon commentedon May 12, 2020
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 commentedon May 13, 2020
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 commentedon May 13, 2020
@UndisputedBasement33 thanks for commenting: I'll be sure to add
CharacterEllipsisto my work in #1556 in my next round of changes so we can evaluate it.Support maxSize in ArrangeText (oxyplot#1559)
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1554, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1554, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1554, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…
Overhaul text arrangement and trimming (oxyplot#1531, oxyplot#1551, o…