Fixed #412

[Thor181]

Closes #412.

[ForNeVeR]

(also, feel free to ignore the test failure; I won't ask you to fix it right now since this PR is more of a discussion starter than an applicable fix — which is totally okay)

[Thor181]

You are right, the previous solution was very rough. There is a more elegant option. FormattedText calculates the height itself with extra padding. In this commit I converted the FormattedText to geometry and took its actual height.

[ForNeVeR]

Alright. I have read through the code and tried to create something that will work, based on the FormattedText API:

    private static TeXFontMetrics GetFontMetrics(char c, Typeface typeface)
    {
        var formattedText = new FormattedText(c.ToString(),
            CultureInfo.CurrentUICulture,
            FlowDirection.LeftToRight,
            typeface,
            1.0,
            Brushes.Black
#if !NET452
            , 1
#endif
        );
        formattedText.LineHeight = 1.0;

        var depth = formattedText.Height - formattedText.Baseline;
        return new TeXFontMetrics(formattedText.Width, formattedText.Baseline, depth, formattedText.Width, 1.0);
    }

My way should theoretically work correctly as well: we base our character's parameters on the font baseline and count the extruding element (if any) as depth.

In reality, however, it turns out to be less precise than your suggestion.

I have also tried combining some more obscure properties such as formattedSize.Extent and formattedText.OverhangAfter, with no avail: the actual geometry calculation is just better.

Also, some property values just doesn't make any sense: for example, Extent of the f character is considered to be 1.01, more than the line height itself; most letters also give negative OverhangAfter, while I expect them all to give zero.

[ForNeVeR]

Alright, I was able to get it right, while keeping the text baseline calculation. Will open a follow up issue though.