Arabic Text Components Render with ~36% Excess Height When Using Noto Naskh Arabic Font

[noob]

Arabic Text Components (Noto Naskh Arabic Font) Render with ~36% Excess Height on AutoGrow

Product: Stimulsoft.Reports.Blazor
Version: 2026.2.2
Severity: High

Description:

Text components using the Noto Naskh Arabic font (NotoNaskhArabic-Regular.ttf / NotoNaskhArabic-Bold.ttf) render with approximately 36% excess height when AutoGrow = true and the component content is populated at runtime. The excess space appears as blank whitespace below the Arabic text within the component bounds.

Steps to Reproduce:

1. Create a report with a StiText component.
2. Set the font to Noto Naskh Arabic, size 12pt.
3. Bind the component to a data field containing multi-word Arabic text (e.g. a sentence of 10–15 Arabic words).
4. Enable AutoGrow = true on the component.
5. Render the report using Stimulsoft.Reports.Blazor.
6. Observe the rendered component height in the viewer vs. the actual text content height in the browser.

Expected Result:

The rendered component height fits the Arabic text content with no excess blank space — consistent with how the same text renders in the browser using the same font and size.

Actual Result:

The rendered component height is approximately 1.357× (35.7%) taller than the actual text content height.

Example measurement (same component, same font, same data):

Actual text height in browser: 529px
Stimulsoft rendered component height: 718px
Ratio: 718 ÷ 529 = 1.357

Root Cause Analysis:

The Stimulsoft text measurement engine appears to apply GSUB Arabic ligature/contextual shaping when calculating string width for word-wrap purposes. This joins Arabic characters into their contextual connected forms before measuring, producing line widths that are ~1.36× wider than what the browser renders for the same text using the same font.

This width discrepancy causes the internal word-wrap algorithm to produce ~1.36× more line breaks than are actually needed, and therefore AutoGrow expands the component to ~1.36× the correct height.

This issue is specific to:

• Arabic script fonts — confirmed with Noto Naskh Arabic (Regular and Bold)
• Text components with AutoGrow = true and multi-word Arabic content populated at runtime

Font Information:

Code: Select all

Family:      Noto Naskh Arabic
File:        NotoNaskhArabic-Regular.ttf
UPM:         1000
WinAscent:   1405
WinDescent:  351
TypoAscent:  1405
TypoDescent: -351
yMax:        1405
yMin:        -590

Environment:

Code: Select all

.NET Version:       10.0
Stimulsoft Version: 2026.2.2

NotoNaskhArabicFontTest.mrt

(267.86 KiB) Downloaded 89 times

[noob]

Updated the post.

[Max Shamanov]

Hello,

Could you please clarify what you mean by ‘Auto Grow’: ‘Can Grow’ or ‘Grow to Height’?

Thank you.

[noob]

Hi,

i mean 'Can Grow' = true

[noob]

please check the attached screenshot for more clarifications.

Screenshot5.png (531.87 KiB) Viewed 3463 times

[Max Shamanov]

Hello,

We would need more time to get an answer for you.
We will let you know as soon as we have any results.

Thank you.
#20239

[noob]

Thanks

[Max Shamanov]

Hello,

We will let you know when we get any results.

Thank you.

[Max Shamanov]

Hello,

The main issue was that the calculation of the line height coefficient did not take into account that the font was being loaded.
As a result, the default font was used, and the measurement was incorrect.
For the ‘Noto Naskh Arabic’ font, the ratio was almost half of what it should have been.
We have fixed this issue and it will be solved in version 2026.2.4.

But there is one more problem.
Browsers use different rendering engines to display text than GDI+ and SixLabors.Fonts.
And it is impossible to precisely adjust the dimensions in the export to work with these engines.
Therefore, when text is displayed in a browser, there may always be a difference of a few per cent in the dimensions compared to how the product engine perceives them. In some cases, these differences cause text to wrap at a different point, resulting in the text size in the browser increasing by one or two lines, which are then cut off by the component’s edge.

For example, in this report using the ‘Noto Naskh Arabic’ font, the SixLabors. Fonts library slightly reduces the line spacing of the text if it contains Arabic characters. As a result, long texts in the browser may not fit within the component – the last line is slightly cut off. To ensure the line height is correct everywhere, it needs to be recalculated during export for each text component. However, this would slow down the export process significantly. Therefore, we did not implement this adjustment.

The problem is exacerbated by the fact that browsers may display text differently on different systems and at different zoom levels. In general, it is very difficult to create an HTML file that displays identically everywhere.

Thank you.