InlineUIContainer is randomly offset from baseline in TextBlocks

[Earlh21]

I'm trying to render some buttons inline in a TextBlock using InlineUIContainer. However I find that the buttons are offset from baseline, and the amount of offset varies line by line.

It's not unique to Button; when using inline TextBlocks the issue still occurs.

Latest Avalonia version (12.0.5). Am I doing something wrong, or is this a bug? Thanks in advance.

Setup:

protected override void OnAttachedToVisualTree(VisualTreeAttachmentEventArgs e)
{
    base.OnAttachedToVisualTree(e);

    var mainTextBlock = new TextBlock()
    {
        Width = 800,
        FontSize = 30,
        TextWrapping = TextWrapping.Wrap
    };

    for (int i = 0; i < 100; i++)
    {
        if (i % 2 == 0)
        {
            mainTextBlock.Inlines?.Add(new Run(" rung "));
        }
        else
        {
            mainTextBlock.Inlines?.Add(new InlineUIContainer
            {
                Child = new Button()
                {
                    Padding = new(0),
                    Margin = new(0),
                    BorderThickness = new(0),
                    FontSize = 30,
                    Content = "button"
                },
                BaselineAlignment = BaselineAlignment.Bottom
            });
        }
    }

    Content = mainTextBlock;
}

Render:

Not super visible there, but it can get bad (from my actual app):

[VectorPeak]

This does not look like a Button padding/template issue. In the first screenshot the repeated rung button text is subtle, but the colored block screenshot is a stronger signal: two apparently identical inline UI elements are ending up at different vertical positions. The app screenshot with the red 1d8 Psychic damage fragments shows the same kind of per-line drift against the surrounding black text.

A couple of things are worth separating here:

• BaselineAlignment = BaselineAlignment.Bottom does not mean “align this child’s text baseline with the surrounding text baseline”. It aligns the inline object by its box, and a control like Button does not expose a typographic baseline in the same way a glyph run does.
• Even with that caveat, identical inline UI containers should not appear to jump around line-by-line. If the same content, font size, and measured size produce different vertical offsets depending on wrapping, that usually points to a layout/text-line metrics bug or rounding issue in InlineUIContainer.

For the sample as written, I would first try removing BaselineAlignment.Bottom and testing the default / BaselineAlignment.Baseline behavior:

mainTextBlock.Inlines?.Add(new InlineUIContainer
{
 Child = new Button()
 {
 Padding = new(0),
 Margin = new(0),
 BorderThickness = new(0),
 FontSize = 30,
 Content = "button"
 },
 BaselineAlignment = BaselineAlignment.Baseline
});

If your real case is only styled inline text, avoid InlineUIContainer entirely and use text inlines instead. A nested TextBlock inside a TextBlock is much more likely to hit this kind of object-layout path, while a Run/Span participates in normal text layout:

mainTextBlock.Inlines?.Add(new Run("1d8 Psychic damage")
{
 Foreground = Brushes.Red
});

If the child really needs to be interactive, then InlineUIContainer is the right area to investigate, but I would treat the current behavior as suspicious. The useful repro would be the smallest version with no Button template involved, for example an InlineUIContainer containing a fixed-size Border or TextBlock with a background color. Your second screenshot is the right direction because it removes most of the styling noise and makes the offset obvious.

A few details would make this easier to confirm as a framework bug:

• OS and rendering backend, since this could involve text measurement/rounding.
• Whether the offset changes with display scaling, for example 100% vs 125%/150%.
• Whether it reproduces with a plain Border child of fixed Width/Height.
• Whether LineHeight being explicitly set on the outer TextBlock changes the result.
• Whether it reproduces on 11.x, if you have an easy way to compare.

As a workaround, if you need this to ship today, the most stable options are either using real text inlines for non-interactive colored text, or laying the tokens out with a wrapping panel / items control instead of embedding controls in a TextBlock. A small RenderTransform or margin adjustment can hide a constant baseline mismatch, but it will not be reliable if the offset is genuinely varying per wrapped line.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆