This seems to be font related. Perhaps the font metrics aren't being processed correctly in all cases?

I got the same problem with the Segoe UI font...

There is no issue with text, in general, this is an issue with the TextBox template.

Consolas is very off-center since updating to Avalonia 11, is there something I can do to fix it?

I cannot use Padding because it will affect fallback fonts that don't have this problem.

@chylex looks like it can be solved by adding VerticalContentAlignment="Center" into a style: https://github.com/AvaloniaUI/Avalonia/blob/97f2d8e74e0a64f98f855a5dc92ac30d03440d7f/src/Avalonia.Themes.Fluent/Controls/TextBox.xaml#L167C73-L167C97

Can you double-check it on your end?

VerticalTextAlignment to center is non ideal especially for TextBox. This is because is cannot work for multi-line text.

FluentUI upstream hardcodes some internal margins to make the first line of text appear as center even though it is actually top aligned. I need to check the actual control templates to validate this though.

If true, we are going to have to pull out a lightweight styling resource to adjust this based on font. Ideally, it could be calculated with measurements of the text controls though.

@robloo if you know you have a single line TB, it's probably a valid "workaround" but in general, I think there is no easy solution for it. A dynamic padding can be a way, but it's not that easy probably. Many things to consider here...

@timunie Yea, it's tricky for sure and there are case-by-case workarounds (incliding shipping a standard font).

However a general solution is going to be needed for this. On my end it is even more severe in appearance using FluentAvalonia with default macOS fonts. This all needs to work out of the box in a cross-platform, generalized way. It should be possible now that we have full text measuring too.

@robloo my concerns are:

• what do we do with density styles?
• what do we do with overridden height? center text anyway?

@timunie I think the first step is narrowing down exactly which controls have the issue. I think ComboBox can be fixed with center vertical alimentment in a general way. TextBox and TextBlock need something more complex or at least different like a margin resource.

what do we do with density styles?

TextDensity would have to just redefine the lightweight styling resource that controls the left/top text padding in certain controls.

what do we do with overridden height? center text anyway?

If a dev customizes a height they are then responsible to control alignment. So we ignore this case in text heavy controls as always.

There are three solutions and each control may need a different one.

1. Just vertical align to center i.e. ComboBox
2. add a lightweight styling resource for text left/top margin to make text appear center when actually top aligned. This resource could also be special and defaults calculated and injected in the resource dictionary at startup.
3. Another crazy idea is to add a new property for TextMargin and that can be automatically calculated per control and then used or ignored in templates.

Keep in mind if this is really all driven just due to different fonts we inherit the issue from WinUI. They didn't need to solve it and just hard-coded padding and margins for the windows font. So something new is needed for sure.

That said, I'm still not 100% convinced there isn't something else going on as in WPF this kind of stuff just seems to work.

I thought of another solitution here too. Have a special converter that calculates a thickness to be used as left/top margin based on given font pproperties. The control itself could be passed as a parameter to get the attached font properties and then run the calculations. Not sure how ugly this would look in practice but it should be possible.

@chylex looks like it can be solved by adding VerticalContentAlignment="Center" into a style: https://github.com/AvaloniaUI/Avalonia/blob/97f2d8e74e0a64f98f855a5dc92ac30d03440d7f/src/Avalonia.Themes.Fluent/Controls/TextBox.xaml#L167C73-L167C97

Can you double-check it on your end?

@timunie These textboxes already have VerticalContentAlignment set to Center. None of the other values work either, they make the text even more off-center than it already is.

@chylex The issue is the Padding property and TextControlThemePadding styling resource. Try overriding either of these and you should be able to center it better. The defaults are carryover from WinUI which assumes Segoe fonts. You'll have to measure Consalas font though to calculate the correct values...

@chylex The issue is the Padding property and TextControlThemePadding styling resource. Try overriding either of these and you should be able to center it better. The defaults are carryover from WinUI which assumes Segoe fonts. You'll have to measure Consalas font though to calculate the correct values...

@robloo Will that not mess up centering of fallback fonts on systems that don't have Consolas?

In that case a converter is proably needed. The converter should get TextBox as input and Padding as output. A Behavior could also work imo.

This should be built-in directly and allow changes in the future if a better idea comes up. So a DefaultTextPaddingConverter is the way to go for now I think.

This would require changing a handful of control templates and will effectively make the TextControlThemePadding useless. This also does cause a potential issue with compact density styles. Not sure how you would know to calculate smaller values for that case yet.

@robloo Will that not mess up centering of fallback fonts on systems that don't have Consolas?

Yes, it will break for any other fonts with significantly different metrics...

This also does cause a potential issue with compact density styles. Not sure how you would know to calculate smaller values for that case yet.

Actually, the converter can special case the Fluent theme. It will search for a TextContropThemePadding in the control resources and then use that to detect compact is needed. If the entire control is passed to the converter parameter we have access to all this information including resources and attached font properties including family.

Obviously the converter will be Fluent theme specific though.

Related WinUI issues upstream:

• CheckBox & RadioButton labels become off-center when text scaling >= ~150%. microsoft/microsoft-ui-xaml#1520 (comment)

@Gillibald what's your feeling about this topic? Do we want such a converter inside Avalonia build in?

Such a converter needs access to the underlying glyph layout. So this is something Avalonia needs to provide. Calculating some padding based on the bounding box of black pixels aka glyph bounds is possible. So you could get centered text all the time. When it comes to multi-line content this strategy gets more complicated. So maybe this only applies to the first line or the MaxLines count.

Yeah I guess this should be only calculated for single line textbox for now.

I have found a Workaround for TextBox using a Behavior. This can be adjusted according to your needs. However, I think this should not be included into Avalonia as is. The benefit over a converter is, that it reacts dynamically to property changes. Can be refined as needed

public class TextCenteringBehavior : Behavior<TemplatedControl>
{
    /// <summary>
    /// Defines the <see cref="AdditionalPadding" /> property
    /// </summary>
    public static readonly DirectProperty<TextCenteringBehavior, Thickness> AdditionalPaddingProperty =
        AvaloniaProperty.RegisterDirect<TextCenteringBehavior, Thickness>(
            nameof(AdditionalPadding),
            o => o.AdditionalPadding,
            (o, v) => o.AdditionalPadding = v);

    private Thickness additionalPadding;

    /// <summary>
    /// Gets or sets an additional padding to the calculated one
    /// </summary>
    public Thickness AdditionalPadding
    {
        get { return additionalPadding; }
        set 
        {
            if (SetAndRaise(AdditionalPaddingProperty, ref additionalPadding, value))
            {
               UpdatePadding(); 
            } 
        }
    }

    protected override void OnAttached()
    {
        base.OnAttached();

        if (AssociatedObject is not null)
        {
            // listen to property changes
            AssociatedObject.PropertyChanged += AssociatedObjectOnPropertyChanged;
        }
    }

    protected override void OnDetaching()
    {
        if (AssociatedObject is not null)
        {
            AssociatedObject.PropertyChanged -= AssociatedObjectOnPropertyChanged;
        }

        base.OnDetaching();
    }

    private void AssociatedObjectOnPropertyChanged(object? sender, AvaloniaPropertyChangedEventArgs e)
    {
        if (e.Property == TextBox.TextProperty
            || e.Property == ContentControl.ContentProperty
            || e.Property == TemplatedControl.FontFamilyProperty
            || e.Property == Visual.BoundsProperty
            || e.Property == TemplatedControl.FontSizeProperty)
        {
            UpdatePadding();
        }
    }

    private void UpdatePadding()
    {
        if (AssociatedObject is null) 
            return;
        
        var typeface = new Typeface(
            AssociatedObject.FontFamily, 
            AssociatedObject.FontStyle,
            AssociatedObject.FontWeight,
            AssociatedObject.FontStretch);
        var textLayout = new TextLayout(null, typeface, AssociatedObject.FontSize, null);

        var verticalPadding = (AssociatedObject.Bounds.Height - textLayout.TextLines[0].Height) / 2;
        
        AssociatedObject.Padding = new Thickness(0, verticalPadding) + additionalPadding;
    }
}

usage:

<TextBox Text="{Binding Greeting}" 
         VerticalAlignment="Center"
         Height="50"
         FontSize="35"
         FontFamily="Consolas">
    <Interaction.Behaviors>
        <behaviors:TextCenteringBehavior AdditionalPadding="10,0" />
    </Interaction.Behaviors>
</TextBox>

When it comes to multi-line content this strategy gets more complicated. So maybe this only applies to the first line or the MaxLines count.

Yeah I guess this should be only calculated for single line textbox for now.

Using an internal text padding and top alignment is entirely for multi-line text. If we only had to worry about one line we would just center and remove the default paddings. What this means is the converter or behavior solution will work for both single and multi-line text.

That said, this isn't going to work with text runs and multiple font families and sizes. So perhaps controls should be calculating everything internally in the long term. A TextPadding property could be calculated by each relevant control.

So, I think controls will need to expose their internal text area bounds publicly as read-only properties. I think two pieces of information are needed (naming is a placeholder):

1. TextBounds
2. TextFirstLineBounds

TextBounds would be everything -- all lines -- and allow XAML control templates usage of that information if it's needed. TextFirstLineBounds is what is needed to actually fix this issue. But it alone isn't enough, a converter is needed to calculate how to center that TextFirstLineBounds within the overall control bounds. Someday XAML is going to have to support basic arithmetic.

Anyway, each text-based control will have to calculate those properties based on their internal text presentation. That could include multiple font sizes, font families and lines (different runs).

This seems like the cleanest, general-purpose approach. A converter or behavior that can reach into the internal control template and calculate this information seems worse long-term.

Also note:

• WinUI fixes this issue by hardcoding the internal paddings to match the default Windows font size. This always centers things like radio buttons and textboxes to the first line of text. It is completely not adaptable though and is actually why we inherited this issue.
  • It is still possible to fix this on a per-app basis by hardcoding the font (like Inter) and then settings the paddings (TextControlThemePadding with Fluent theme)
• WPF seems to side-step this issue entirely by making control templates in a different way (need to dig more into this though)

Thoughts? This is entirely new territory.

EDIT: Nevermind, I found it in NuGet package Avalonia.Xaml.Behaviors.

public class TextCenteringBehavior : Behavior<TemplatedControl>
...

usage:

...
    <Interaction.Behaviors>
        <behaviors:TextCenteringBehavior AdditionalPadding="10,0" />
    </Interaction.Behaviors>
...

In my attempt to use your workaround I failed by not having the Behavior class in my referenced libraries and the <Interaction.Behaviors> neither. I wonder where do they come from?

Is there any update regarding a permanent solution (restoring the old behavior)?

I want to know if it is worth waiting for a fix or if I have to start making padding adjustments across my entire application!?

@chkr1011 maybe you want try the linked PR

Can now be tested using nightly builds if anyone wants to do it.

I tested it with the latest nightly build but it still looks the same.

Interestingly enough it only affects the Font "Consolas" on Windows. Other monospace fonts work perfectly on Windows and Linux. I was not able to test "Consolas" on Linux.

I get a similar issue with the Oxanium font. It seems to be calculating the bounds height as too large, so the text appears vertically offset towards the top

Some good discussion here: Oxanium Font is always vertically aligned to the top, or is Avalonia not rendering it correctly? #15262

• Oxanium Font is always vertically aligned to the top, or is Avalonia not rendering it correctly? #15262 (comment)

It seems someone figured out exactly what is going on too:

toptensoftware/RichTextKit#67