Custom fonts on a Linux server

[Jamie]

Hi,

I am using the Reports.Web.NetCore package (v2018.3.2) in a .NET Core web API that is deployed on a Linux server running Ubuntu 16.04.4 LTS. The custom fonts we are using SourceSansPro-ExtraLight.ttf SourceSansPro-Light.ttf SourceSansPro-Regular.ttf don't render in the PDF report generation and instead default to an Adobe Sans MM font (I've tried adding a screenshot but getting a parsing server response). We have installed the above fonts onto the server but they still don't render. To try and replicate the issue we installed an Arial font onto the Linux server to see if the same problem would occur but the Arial font is generated correctly in the reporting template.

This problem only occurs on Linux. When running the API locally on windows, the custom fonts work correctly and display as expected so we're at a loss as to how to get them working correctly on the Linux server. We have set StiOptions.Export.Pdf.AllowImportSystemLibraries = true; but this causes a console error and the PDF isn't generated. Again this is only an issue on Linux and not when run locally on windows.

Does anybody know what we need to do to get the above fonts working correctly on Linux?

Thanks

Jamie

[Lech Kulikowski]

Hello,

Please try to use the following code to add fonts in the collection:
Stimulsoft.Base.StiFontCollection.addOpentypeFontFile()

Thank you.

[Jamie]

Hi Lech,

thanks for your response. I have tried adding Stimulsoft.Base.StiFontCollection.addOpentypeFontFile() as you suggested but getting the following error 'StiFontCollection does not contain a definition for addOpentypeFontFile'. The method doesn't exist so can't use it. I tried using AddFontFile instead like - Stimulsoft.Base.StiFontCollection.AddFontFile() and passing in the file location but this hasn't worked when deployed onto a Linux server. Works fine on Windows.

I've updated the version of Stimulsoft.Reports.Web.NetCore to Version 2019.2.1 to see if that would resolve it but get the same error message as above. At the minute we are still using the trial version, could that have anything to do with it? This is the last thing we need to resolve before we purchase the worldwide licence so any further suggestions on how to resolve is appreciated.

Thanks

Jamie

[HighAley]

Hello, Jamie.

We know about this issue.
The main problem is that our engine needs access to the font files for the PDF export.
Unfortunately, it's impossible to get it in .Net Core that is run on Linux.
The StiOptions.Export.Pdf.AllowImportSystemLibraries = true; option is for Windows only.
The StiFontCollection does not work on Linux too.
We are working hard on this issue and have plans to make an improvement next week.
We will let you know when it will be available.

Thank you.

Ticket reference: #8025

[HighAley]

Hello.

We have made a deep analysis of the issue with the custom fonts.
We made tests on a .Net Core project with Debiandocker package.

The issue with custom fonts in PDF export.
The PDF file needs the font files to be embedded.
Unfortunately, there is no access to font files on Linux from .NET Core.
And we can't load the fonts without loading them a special way.
There are two ways:

Load the font file as a resource of the report.

Load the font file to a special font collection using StiFontCollection.AddFontFile(name).

Also, we have found another issue in GdiPlus for Linux. The Measure/Draw text methods work if the font is installed in the system.
So these files should be installed on the system too or you get the wrong width of the symbols.

There is one more issue with font styles.
The NetCore(GdiPlus) support 4 styles only (Normal, Bold, Italic, Bold+Italic.)
All other font styles are defined in separate files. For instance, SourceSansPro-ExtraLight and SourceSansPro-Light are different fonts.

On Linux, all font styles with the same font name are merged into one file SourceSansPro. All styles are stored in it (ExtraLight, Light, Bold, SemiBold and etc.).
But there is no way to get other than standard styles with NetCore(GdiPlus). So there is 'SourceSansPro-Regular' font only.
n the .Net Framework all fonts works right.

We can try to make an improvement but this task needs too much time.

As a workaround, we can suggest you choose any other similar font or remove the preferredFamily and preferredSubfamily from your fonts.

Please, check our latest build. The fonts should be exported to PDF there.

Thank you.

[Jamie]

Hi,

thanks for the detailed response. Looks like you've tried everything possible to resolve this issue. I think going forward we may be best looking at a windows server to host as the business are pretty set on the font type they want. Was our least preferred option but hopefully should resolve. Thanks again.

Jamie

[Lech Kulikowski]

Hello

Please let us know if you need any additional help.

Thank you.