In this article we will explain how to use custom fonts in Dynamics 365 for Finance and Operations reports when printing them on physical printers. By “custom fonts” we mean fonts that are not installed in a D365FO environment.

Printing using Document Routing

Technically speaking, printing process in D365FO is a bit more complicated, at least this is true for D365FO running on Azure in the cloud. The reason is that AOS machines that are hosted on Azure are running outside a company’s local network and do not “see” printers hidden behind a company’s firewall. And hence, when a D365FO user executes a report (e.g. invoice) and sends it to printer (e.g. by selecting the printer print destination), the AOS service cannot simply send the generated report directly to the printer. It is rather done indirectly.

The printing technique that D365FO employs is called Document Routing and involves the following steps:

1. First SSRS service generates a document in the form of EMF format. More specifically, SSRS uses GDI+ APIs to create an EMF image for each report page. (EMF is one of the Windows print spooler files and is most commonly used by various applications that support printing)
2. When the SSRS service returns the generated report (in EMF format), AOS service sends it along some other print job information to a specific Azure Storage Queue.
3. On the other side, behind the company’s firewall, an instance of Document Routing Agent constantly polls for any new print jobs in that specific Azure Storage Queue. And when a new item appears in the queue, it downloads the package and prints all EMF images (i.e. report pages).

The Problem

Fonts that are used by a SSRS report design need to be installed in two places. The first one is the SSRS machine. SSRS rendering engine needs font information in order to generate those EMF images. The second place those same report design fonts need to be installed is the Document Routing Agent machine. Document Routing Agent also uses GDI+ APIs to print EMF files and GDI+ requires availability of fonts.

So, there is no problem if you are using standard fonts that are by default installed on these machines. But as soon as you use a custom font, you need to make sure that that font is installed on the SSRS machine and the machine where Document routing Agent is running. The later machine should normally not be a problem since an administrator can always install additional fonts as needed. The problem is the SSRS machine because you cannot just simply connect with RDP and do the same. All machines running on Azure are managed, and interfacing can only be done via LCS. So there is no way to put those additional fonts on the SSRS machine.

The Solution

Sadly, but it seems like there is nothing that can be done for SSRS reports, since SSRS can only use system-installed fonts and there is no way to install them.

The rest of this article will focus on how we solved this problem for Docentric AX reports. Docentric AX report execution also uses exactly the same Document Routing mechanism when sending a report to a printer. And hence, Docentric AX report execution engine also needs to generate reports in the EMF format, just like SSRS. One difference is that, unlike SSRS report engine, Docentric AX engine runs inside an AOS process. But this doesn’t help much since we also do not have RDP access to AOS virtual machines in Azure.

The difference is in the rendering engine of Docentric AX. We implemented the rendering engine in the way that it is not limited to only system-installed fonts but can load fonts provided from elsewhere. The only question that now remains is what would be a good option to store custom fonts so that Docentric AX engine could access and use them.

We decided to provide two options for storing custom fonts. The first is to store (embed) them within your templates (aka Docentric designs). Alternatively, you can store them as AOT resources.
Learn more in detail >>

What about the on-premises version of D365FO?

D365FO on-premises doesn’t use Document Routing because it doesn’t have to. It is normally part of the company’s local network and can have direct access to printers. Since D365FO on-premises prints directly from within AOS nodes (Service Fabric environment), the situation changes slightly. You still need to install custom fonts on a SSRS machine (for the same reason as before), but instead of the Document Routing Agent machine (on-premises doesn’t need it) you will need to install custom fonts on all AOS nodes in the Service Fabric cluster.

Regarding SSRS reports, we have a similar problem that we have with D365FO running in the cloud. Service Fabric nodes are managed VMs and it is unlikely that manually tweaking them and installing fonts would be a viable option, even though you can RDP to them.