Hello Fadi,

Thank you for sending us the document.

The PDF document uses a non-embedded TrueType font for the value of this barcode field. Examining the document I found the font descriptor doesn't contain the FontFamily of this font which leads to not successfully match with the fonts installed on the OS.

On the other hand, since the font is not provided on import, the PdfProcessing renderer fallbacks to default fonts which leads to undesirable results with the rendered text. With the current implementation of PdfProcessing, there isn't any mechanism for registering custom font files when importing documents with non-embedded TrueType fonts. I have logged a feature request on your behalf in our feedback portal (this is the reason I am declining this bug report) regarding such functionality, you can check it here: PdfProcessing: Provide a mechanism for loading custom font files when importing TrueType fonts. You can cast your vote for the implementation as well as subscribe to the task by clicking the Follow button so you can receive updates when its status changes.

In appreciation for bringing this to our attention, I updated your Telerik points.

In the workaround you mentioned (setting the font using the FontsRepository.TryCreateFont() method) the font is loaded from the operating system using the missing FontFamily and it fills the font source.

This functionality is already implemented in the .Net Standard version of our assemblies, so if it is an option for you you can reference them until this feature is developed.

As a side note, while examining the document I found a known issue related to a wrong TextBox widget appearance when the value of the field is modified. You can subscribe to the following item to follow its progress: PdfProcessing: TextBox widget appearance is exported with wrong text properties when recalculated.

I hope you find this information helpful.

Regards,
Martin
Progress Telerik