Arabic Text Components Render with ~36% Excess Height When Using Noto Naskh Arabic Font
Posted: Mon May 11, 2026 12:19 pm
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:
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.
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:
Environment:
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:
- Create a report with a StiText component.
- Set the font to Noto Naskh Arabic, size 12pt.
- Bind the component to a data field containing multi-word Arabic text (e.g. a sentence of 10–15 Arabic words).
- Enable AutoGrow = true on the component.
- Render the report using Stimulsoft.Reports.Blazor.
- Observe the rendered component height in the viewer vs. the actual text content height in the browser.
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.
Root Cause Analysis:Example measurement (same component, same font, same data):
Actual text height in browser: 529px
Stimulsoft rendered component height: 718px
Ratio: 718 ÷ 529 = 1.357
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
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
Code: Select all
.NET Version: 10.0
Stimulsoft Version: 2026.2.2