PDF/A compliance is not embedding fonts

Stimulsoft Reports.NET discussion
Post Reply
jerry.larsson
Posts: 4
Joined: Wed Jun 07, 2023 10:32 am

PDF/A compliance is not embedding fonts

Post by jerry.larsson »

Font is not embedded into PDF.

I've created a simple report with one text field and font set to Arial; 24pt.
When exporting the report from within the Designer (Windows), to PDF with PDF/A compliance, the font is embedded.

When trying to export the same report from code and setting StiPdfExportSettings,PdfComplianceMode to StiPdfComplianceMode.A3, the font is not embedded in the resulting PDF file. I've tried setting all sorts of settings, like StiPdfExportSettings.EmbeddedFonts = true, but nothing seems to embed the font.

What am I missing?

Code: Select all

var report = new StiReport();

report.Load(reportFile);
await report.RenderAsync();

var exportSettings = new StiPdfExportSettings();

exportSettings.PdfComplianceMode = StiPdfComplianceMode.A3;

await report.ExportDocumentAsync(StiExportFormat.Pdf, outputFile, exportSettings);
Lech Kulikowski
Posts: 6198
Joined: Tue Mar 20, 2018 5:34 am

Re: PDF/A compliance is not embedding fonts

Post by Lech Kulikowski »

Hello,

If you use NET Core, you should add fonts in the StiFontCollection.

Thank you.
jerry.larsson
Posts: 4
Joined: Wed Jun 07, 2023 10:32 am

Re: PDF/A compliance is not embedding fonts

Post by jerry.larsson »

Yes, I'm using NET Core. I thought that fonts installed in Windows would automatically be added, but you're saying that is not the case?
So I have to add Arial to StiFontCollection to make font embedding work?
jerry.larsson
Posts: 4
Joined: Wed Jun 07, 2023 10:32 am

Re: PDF/A compliance is not embedding fonts

Post by jerry.larsson »

It seems to be working when adding the font to StiFontCollection from C:\Windows\fonts\arial.ttf. However, when validating the PDF/A file I get another validation error saying "Glyph widths in font dictionary are not consistent with embedded font program widths." it seems I'm missing something else?
Max Shamanov
Posts: 768
Joined: Tue Sep 07, 2021 10:11 am

Re: PDF/A compliance is not embedding fonts

Post by Max Shamanov »

Hello,

Please send us a sample report with test data for analysis.

Thank you.
jerry.larsson
Posts: 4
Joined: Wed Jun 07, 2023 10:32 am

Re: PDF/A compliance is not embedding fonts

Post by jerry.larsson »

I just created a new report in the latest version of Stimulsoft Designer for Windows. Added a basic text label at the top and saved it.

Wrote the above code to export it to PDF/A3 and validated it on some online tool. The report is very basic with just one text field with static text.
Max Shamanov
Posts: 768
Joined: Tue Sep 07, 2021 10:11 am

Re: PDF/A compliance is not embedding fonts

Post by Max Shamanov »

Hello,

We need some additional time to investigate the issue, we will let you know about the result.

Thank you.
#11653
Max Shamanov
Posts: 768
Joined: Tue Sep 07, 2021 10:11 am

Re: PDF/A compliance is not embedding fonts

Post by Max Shamanov »

Hello,
However, when validating the PDF/A file I get another validation error saying "Glyph widths in font dictionary are not consistent with embedded font program widths." it seems I'm missing something else?
Unfortunately, we do not know the solution to this problem.

Inside the pdf-file, in addition to the font file itself, a block of information about this font is also recorded: the name, the encoding, and a "Widths" table in which the width of all the characters used is specified. This table is used by the viewer to speed up the work with the text (as a cache), so as not to calculate the width of characters every time from the font data.

PDF/A validation has many steps. One step is to check that the data in the Widths table matches the font data. The check utility calculates the character widths and compares them to those in the Widths table. The standards allow for a deviation of 0.1%.

This is where the problem appears.
Different graphic libraries calculate character widths using different methods with different accuracy, so the values may differ, sometimes up to 1-2%. And this is much more than the allowable 0.1%. Because of a discrepancy in these numbers and displays the specified error check. Moreover, even different scanning utilities may calculate the width in different ways and, respectively, complain about different files.

This problem is described in more detail here:
http://martin.hoppenheit.info/blog/2018 ... formation/

Thank you.
Post Reply