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
The IRenderContext.MeasureText method doesn't have a formal specification, and is implemented in different ways all over the place.
We should consider formalising its behaviour so that we can make everything consistent before attempting to address inconsistencies in multi-line text rendering between platforms (see Issue #1538 and discussion in PR #1549).
Similar to what we do in OxyPlot.SkiaSharp and OxyPlot.ImageSharp for vertical text alignment, I would argue that the vertical text measurement should not actually be dependent on the content. I think it is more important that the baselines of multiple text runs are guaranteed to be aligned regardless of content.
A possible definition could be: [text-height] = (|[ascent]| + |[descent]| + [leading]) * [number-of-lines] - [leading]
which would be equivalent to: [text-height] = [line-height] * [number-of-lines] - [leading]
Width
This should take into account text shaping, if applicable
A possible definition could be: [text-width] = MAX([line] => SUM([advancement]))
It's not immediately obvious how to implement the width computing manually in some APIs, but in practice the width doesn't seem to be much of an issue.
Yes, probably most of the APIs do exactly this computation under the hood, and if there is no issue there would be no need to change anything. The definition should only serve as a reference in case of doubts / inconsistencies.
Activity
Jonarw commentedon May 10, 2020
There appear to be some different nomenclatures around this topic. To be sure we are talking about the same thing, I will use the same nomenclature as in this blog post:
http://www.cyrilchandelier.com/understanding-fonts-and-uifont
Some thoughts:
Height
OxyPlot.SkiaSharpandOxyPlot.ImageSharpfor vertical text alignment, I would argue that the vertical text measurement should not actually be dependent on the content. I think it is more important that the baselines of multiple text runs are guaranteed to be aligned regardless of content.[text-height] = (|[ascent]| + |[descent]| + [leading]) * [number-of-lines] - [leading]which would be equivalent to:
[text-height] = [line-height] * [number-of-lines] - [leading]Width
[text-width] = MAX([line] => SUM([advancement]))VisualMelon commentedon May 10, 2020
Thanks for putting that so clearly.
It's not immediately obvious how to implement the width computing manually in some APIs, but in practice the width doesn't seem to be much of an issue.
Jonarw commentedon May 10, 2020
Yes, probably most of the APIs do exactly this computation under the hood, and if there is no issue there would be no need to change anything. The definition should only serve as a reference in case of doubts / inconsistencies.
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…