Printing reports with custom fonts in self-service deployment environments

Are you having problems with custom fonts when you generate, print, send, or archive reports in Dynamics 365 for Finance and Operations self-service deployment environments? If this is the case, we have a new exciting feature for you. But before we dig into how Docentric can help you, let us quickly explain why those problems occur.

Font-related problems

Fonts are a fundamental component of each document, and this is how we can describe them in a simple way. A font is the design of characters, symbols, or icons. It contains their style details that are shown on our generated reports and public-facing documents.

The problems occur because you need to install the fonts you are using locally on each machine. If a font is missing on your machine, the application used for viewing the document replaces (font substitution) the font with another one available. The result is usually not what you intended to achieve.

The same problem can occur when you are using an online service for generating, saving, and converting documents from one document format to another. In this case, you can’t even install fonts since the online service can’t upload/ doesn’t support uploading custom fonts.

Font-related problems in D365FO

There are many examples of font-related problems in D365FO. Let us just list a few of them:

  • The resulting document layout is not the same as the one in the document design.
  • The text is shown instead of a barcode.
  • The special symbols are displayed as squares or other strange-looking characters.
  • Customers are requesting usage of special fonts to automate data capture with cognitive services (e.g., OCR – Optical Character Recognition).
  • The machine-readable line in printed checks is not showing with the MICR font.
  • Our corporate design fonts and styles are not shown in public-facing documents.

Most of these problems usually have the same root cause – your D365FO environment is missing the fonts used in your documents. We can simply simulate such a problem by creating a document with some custom fonts in Microsoft Word that is installed locally on our machine, and then convert it to PDF. Next, we can convert the same Word document to PDF using cloud-based Word without these fonts installed. You can see the difference in the image below.

Is there a solution to preserve the appearance of documents opened anywhere on any device, without installing custom fonts?

Font embedding as a possible solution

Some document formats support font embedding,, so anyone who opens your document will see it as it was originally designed. This approach is not always the best choice, as it leads to larger documents (e.g., MS Word, Excel, etc.). The exception to this are the PDF documents, where font embedding is the recommended approach. Documents in PDF format are commonly used for viewing, distribution, and long-term archiving.

You can see it on your own by downloading the ZIP package with 2 samples. The first shows how embedding fonts affects the file size of Word documents. The second one is a PDF document converted from the Word document with custom fonts and demonstrates how missing fonts can change the way you see the document content.

As D365FO has evolved, two possible standard solutions for generating, emailing, and archiving reports and documents have emerged. The first and certainly most developed/thorough is SSRS, and the second one is the Electronic Reporting, which is being used more and more in the D365FO world.

Before we show you how Docentric can solve problems with custom fonts, let us look at what kind of problems you are facing with SSRS and Electronic reporting.

Using custom fonts with SSRS

D365FO with the SSRS reporting engine, allows you to generate reports in various output formats. The most common formats are PDF, Microsoft Excel and Word.

If you are using Microsoft Excel or Word, your users must install the same custom fonts used on SSRS report designs.

For PDF documents, on the other hand, font embedding is supported but limited to those fonts that are installed on the SSRS rendering engine server (in Azure for cloud environments).

This is the official response from Microsoft regarding rendering documents with custom fonts using SSRS in self-service deployment environments:

Custom fonts are no longer supported for document reports rendered using the built-in SSRS framework. Finance and Operations apps include access to hundreds of standard, business-ready fonts available for documents rendered by the cloud-hosted service. This portfolio will continue to grow as the service expands into new regions and industries. However, the service no longer supports the installation of custom fonts in customer environments. Requests to expand the collection of fonts supported by the service will be considered on a case-by-case basis.

Using custom fonts with Electronic Reporting

The Electronic Reporting framework uses Microsoft Excel and Word documents as report templates. Most of the reports available in the General Electronic Reporting configurations provided by Microsoft are in Excel format. However, Excel does not support font embedding, and you are facing the same problems as in SSRS!

Alternatively, you could switch from Excel to Word templates since Microsoft Word supports font embedding. The drawback/downside here is that by embedding fonts, you might be producing huge documents. In some cases, your output document size can even increase over 5 MB and become a showstopper for emailing such documents, as most companies have policies that restrict the size of email attachments.

For more information about the embedding of fonts, you can check the Microsoft Office support documentation here.

Recently Microsoft has added a new feature called Convert Electronic Reporting outbound documents from Microsoft Office formats to PDF. This feature is implemented via the Office 365 cloud service, which converts Excel and Word documents to PDF. The converted PDF documents contain embedded fonts by default, and Office 365 cloud service has more pre-installed fonts than the SSRS reporting engine. However, you are bound to use only the fonts listed here, and you might not find a font that fits your needs nor you have a possibility to upload a custom one.

Using custom fonts with Docentric

The good news is that we have listened to users from the community and implemented a new feature in Docentric version 3.3.8, which enables you to upload and use custom fonts in your PDF documents generated by the Docentric rendering engine.

Docentric rendering engine is a lightweight component running as a part of the D365FO AOS instance. Unlike SSRS Reporting Services or Electronic Reporting with Office 365 PDF conversion service, Docentric allows usage of custom fonts. We have already described those scenarios in our previous articles.

You can embed custom fonts you need to use in your Docentric templates, or you can store them as AOT resources. Learn more >>

In this article, we will explain the improvements we made in the version 3.3.8, using custom fonts with Docentric.

To be specific, up to version 3.3.8 you could embed custom fonts in Docentric templates, which could increase your templates and output Word document size, or ask your developer to store the needed custom fonts as AOT resources. This means that deployment was needed to get custom fonts working in your environment. From 3.3.8 on, you can upload custom fonts directly from within D365FO and use them instantly, e.g. in production.

Self-service deployment environments

Sometimes, some regular fonts, such as Calibri, are missing on AOS instances in these environments. If this is the case, the Docentric rendering engine will not be able to generate PDF documents with Calibri. To remedy this instantly, you can use our new functionality to confirm first that Calibri is missing in the environment, and then upload it directly from within D365FO if needed.

How to use Font Management

In the Docentric Workspace > Docentric AX Parameters form, locate the Templates tab page. You will notice a new section Template font.

In this section you can:

  • Check which fonts are already installed in your D365FO environment.
  • Upload new custom fonts to Azure Blob storage to be used in your generated PDF documents.

Let’s take a quick look at how this works.

Which fonts are installed on my environment?

When you are experiencing font-related problems, the first step towards resolving them is checking whether you have fonts installed in your D365FO environment. You can do this by clicking the Show installed fonts button. The diagnostic report will pop up on the screen with a list of all installed fonts grouped by their source. As simple as that!

There are three locations where the Docentric rendering engine looks for fonts and loads them in the following order:

  • Custom Azure storage fonts – Custom fonts uploaded to Azure blob storage by users with access to Docentric setup (e.g., functional consultants, power users, administrators, etc.).
  • Custom AOT fonts – Custom fonts deployed via deployable packages or models, which were stored as AOT resources by developers.
  • System fonts – The pre-installed fonts in the D365FO environment.

Upload custom fonts to Azure blob storage

When we detected which fonts are missing in our environment, we can collect the corresponding font files, zip them into a single ZIP package and upload them to Azure blob storage by clicking Upload custom fonts. The Docentric rendering engine will automatically load the newly uploaded fonts and use them for the first next PDF document generation/creation.

From here on, you will be able to use all the installed fonts with all Docentric generated reports.


In this article, we addressed the font-related problems for those of you who are using Docentric to generate your reports.Up to Docentric version 3.3.8, you could use custom fonts by embedding them in Docentric templates or storing them as AOT resources. From 3.3.8 on, you can upload your custom fonts via special setup in D365FO without any coding, deploying or changing your templates.

Leave a Reply

Your email address will not be published. Required fields are marked *


Docentric respects your privacy. Learn how your comment data is processed >>

Docentric respects your privacy. Learn how your comment data is processed >>