Experiencing problems with custom fonts when designing or printing reports is a common issue often stemming from a lack of understanding of the printing process in D365FO and how it relates to custom fonts.
In this forum post, we provide a comprehensive overview of the potential root causes of custom fonts not displaying correctly in your report designer live preview or report printout, along with their respective solutions.
How Standard SSRS Reports Use Fonts
When you print a report to the Printer print destination in D365FO, the SSRS report execution process follows these steps:
- The SSRS service generates a document in the EMF format.
- The AOS (Application Object Server) service sends the EMF file to a specific Azure Storage Queue.
- The DRA (Document Routing Agent) downloads the EMF files, which essentially represent report pages, and sends them to the designated printer.
All fonts used in an SSRS report design must be installed on the server where SSRS runs, as well as on all computers where the DRA service is running.
If you would like to use a custom font that is not available on the SSRS server, then you’ll need to install these fonts on the server where the SSRS runs, as well as on DRA computers.
How Docentric Implemented Custom Fonts
Docentric AX report execution follows the same Document Routing mechanism as SSRS when sending a report to a printer. Unlike the SSRS report engine, however, Docentric’s engine operates within the AOS process. As a result, Docentric AX rendering is not restricted to system-installed fonts, but it can also load fonts from alternative sources:
- The report template.
- AOT (Application Object Tree) resources.
- Azure storage blob container.
Embedding Custom Fonts In The Template
One of these alternative locations for custom fonts is the report template itself. Docentric report templates are essentially Word documents, allowing you to use Microsoft Word’s standard features to embed fonts directly into the document.
The font needs to be installed for all users, otherwise, the custom font will not be applied when viewing the report in the Docentric AX Designer and printing the report.
It’s important to keep in mind that Word will not embed a font into a template if the font’s license does not permit font embedding and distribution. Consequently, these fonts cannot be included in Docentric designs either.
Files with embedded fonts are also much larger as each embedded font adds 3-5 MB to the file size which is why embedding fonts is generally not recommended.
Storing Custom Fonts As AOT Resources
The second option to add custom fonts is to store them as AOT resources. During report execution, when the AOS process starts, the Docentric AX engine scans for all AOT fonts and loads them, making them available for all subsequent report executions. To embed fonts to the AOT resources, you will need a developer.
Storing Custom Fonts To Azure Storage Blob Containers
Using Docentric AX Parameters you can upload custom fonts to an Azure storage blob container, where AOS can access them. To upload your custom fonts, zip all of the missing .ttf font files and upload the file using the font upload feature in Docentric AX Parameters.
Troubleshooting Custom Fonts That Don’t Render As Expected
Knowing that it can be confusing to identify where to start troubleshooting the problem, we prepared some guidelines to point you in the right direction.
1. The custom font was installed in MS Word, but it is not visible in the Live Preview
A common mistake is installing the font in Word for a specific user only. To resolve this, ensure that the custom font is installed for all users.
2. The font is installed on the DRA and stored on AOT/Azure/embedded in the template but still doesn’t work
If everything looks fine when printing to the screen and in the report template, and you have the font installed on the DRA, we recommend using Tracing with the DRADocument parameter for troubleshooting.
This step allows you to download the EMF file of the report, which represents the file to be printed.
If the EMF file renders as expected, the issue lies with the DRA. In this case:
- Double-check if the font is installed on the DRA machine.
- Uninstall the problematic font(s) on the computer where the DRA service runs (be mindful if you have multiple computers with DRA services).
- Reinstall the problematic font(s) for all users on the computer(s) where the DRA service runs (if you have multiple DRAs, repeat this process for each).
- Restart the DRA service after font installation.
However, if the EMF file doesn’t render as expected, the problem likely resides within D365FO. In this scenario, check the fonts in D365FO under Docentric AX parameters > Templates > Show installed fonts.
If the font is not shown there, your developer will need to properly store it as an AOT resource or you will need to upload it to Azure storage using the upload feature marked in the screenshot above.
3. Font works with the Screen print destination, but not when printing to the Printer print destination
The problem is most probably the DRA, so we recommend starting there. Check the steps explained in the 2. The font is installed on the DRA and stored on AOT/Azure/embedded in the template but still doesn’t work section and if needed, use Tracing to identify where in the pipeline the problem happens.
Bonus Tip: The Easiest Way to Add a MICR Font to Checks
We recommend using the IDAutomation MICR font because it is already installed on the AOS servers during the installation of Docentric.
You just need to ensure that the font is installed also on the computers where the DRA service runs. The font needs to be installed for all users on the DRA computers. The font also needs to be installed for all users on user machines where the reports are being designed.
Since SSRS check designs are using this font as well, the font may have been installed on the DRA at the time when the system was set up.
Closing Words
The key to successful troubleshooting of custom fonts lies in understanding where the issue occurs. Here are summarized tips for addressing font-related issues:
- Ensure that the custom font is installed on computers where report design takes place. When installing the font choose to install it for all users.
- Ensure that the custom font is listed under installed fonts in Docentric AX parameters > Templates > Template fonts. If it is not found there, you will need to provide it by adding it to the AOT, Azure storage, or by embedding it into the Microsoft Word template.
- Ensure that the custom font is installed on the DRA for all users.
- If the fonts work in the template and when printing to the screen but not when printing to the printer, the issue most probably lies in the DRA.
- When in doubt, use Tracing to identify whether the issue occurs on the DRA or in D365FO. If the issue is with the DRA, the EMF file will be as expected. Otherwise, you will see the EMF file without the custom font.
If, after following these steps, you cannot pinpoint the source of the issue, please submit a support ticket to support@docentric.com and detail the troubleshooting steps you’ve taken. We are here to help out.