Creating reports and dashboards | Stimulsoft community forum

Hi Max,

please check this post viewtopic.php?t=64153 for the fix and workaround for the first time print dialog blank issue.

Thanks.

but the PDF export issue with the dots that i mentioned before needs to be fixed.

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.

the Root cause for PDF issue:

Steps to reproduce

Register a custom Arabic font (e.g. Noto Naskh Arabic) via StiFontCollection.AddFontBase64().
Create a report with a text component containing Kurdish Sorani text, for example: ئەمرۆ (letters with dots/marks above them).
Export the report to PDF via StiPdfExportService.
Open the exported PDF in any PDF viewer (Adobe, Edge, Chrome).
Expected result
Diacritic dots appear correctly positioned on or around their base letters, matching the designer preview.

Actual result
Diacritic dots appear displaced — floating at incorrect positions unrelated to their base letters. The positioning is consistent with the marks being placed at their default glyph advance positions with no GPOS offsets applied.


OpenType fonts position combining marks via the GPOS table (specifically the MarkToBase and MarkToMark lookup types). These lookups define the anchor coordinates that place, for example, the two dots of the letter ڤ precisely above the base letterform.

I performed a binary scan of Stimulsoft.Report.dll (the PDF rendering assembly) searching for the strings "GPOS", "HarfBuzz", "MarkToBase", and "MarkAttach". None of these strings are present anywhere in the DLL. This confirms that the PDF export engine has no OpenType GPOS implementation — it writes glyph positions from its own text layout engine without reading GPOS mark-to-base offsets from the font.

Binary search results in Stimulsoft.Report.dll:
"GPOS" → not found
"HarfBuzz" → not found
"MarkToBase" → not found
"MarkAttach" → not found


Please implement OpenType GPOS mark-to-base and mark-to-mark positioning in the cross-platform PDF text layout engine, or integrate a shaping library such as HarfBuzz (available as a .NET binding: HarfBuzzSharp) which handles full GSUB+GPOS shaping for all complex scripts. This is a critical correctness bug for RTL/Arabic-script language support.


Thanks.

Hello,

We have reproduced the issue.
We need some time to investigate it in detail and find a solution for you.
To reproduce the issue, it is not necessary to load the font into StiFontCollection, as the report you sent indicates that the fonts are located in the resources.
Simply load your report into the viewer and export it to PDF.

Thank you.
#20204

Thanks

Hello,

We will let you know when we get any results.

Thank you.