BUG: Font names in Dorico generated PDFs are incorrect

Dorico 2.2.20 on Windows 10 creates PDFs where the font descriptors use the path and file name of the font, e.g. C:\WINDOWS\FONTS\BRAVURA.OTF. Dorico declares the file to be PDF 1.4, but table 5.18 in the PDF 1.4 specification says that FontName in the font descriptor should be the PostScript name of the font, i.e. Bravura. The same problem is replicated for all fonts in the file.

One easy way to display these font names in a PDF is to use the Properties panel, Fonts tab of Acrobat - I think the functionality is there is Acrobat Reader also.


This problem messes up import of Dorico generated PDFs into Adobe Illustrator, also it might impact on rendering optimisation by PostScript printers.

Dorico uses the Qt application framework to handle things like PDF export, and Qt generates a unique font name for each font subset that it embeds (and does so in a slightly different way on Windows and macOS). I believe this is a legitimate way for the font to be named when it is embedded, but I will raise this with their developers and see if they can provide any further rationale.

If you backtrack through the PDF spec, the “Postscript name for the font” is syntactically just a “name” (and its value is defined elsewhere in the PDF data structure, of course).

The only restriction is that it can’t contain whitespace or delimiter characters. The delimiter characters are () <> {} / % but not .

If this is a bug in Adobe software cause by not understanding their own file specification (well, it’s not their specification any more, it’s now owned by ISO) it wouldn’t be the first time.

Thank you both for your input. Rob - there is one and only one correct naming of a TrueType font according to section 5.5.2 of the PDF 1.4 specification. The correct naming of subsets is dealt with in section 5.5.3 of the specification.

Dorico’s behaviour looks non-compliant to me.

This has come up before, and it seems like the fix is to make sure that the fonts are installed for all users, not just for the current one.

I’ll admit I was surprised at seeing fonts listed with their pathname, as an old PDF (and PostScript) hound.

The font has been installed for all users on my system. Dorico 2.2.20 was installed whilst logged on as a user with administrator privileges but is run as as an unprivileged user. 2.2.20 is the only version of Dorico that has been installed on the system in question. The full installer from Steinberg Download Manager was used.

%LOCALAPPDATA%\Microsoft\Windows\Fonts (the user specific font folder) is empty. The font is in %SYSTEMROOT%\Fonts (C:\Windows\Fonts - the system font folder) as expected.


I’ll happily try any reasonable suggestions to diagnose the issue if it cannot be readily reproduced.

Looking at a Dorico PDF written from Windows, the fonts are not embedded as TrueType fonts, but CIDFontType2 fonts.

The difference being that CIDFontType2 is “a CID font whose glyph descriptions are based on a TrueType font.” (my emphasis). See Table 5.7 in your reference.

FWIW Bravura is not TrueType but OpenType, which was not supported at all by PDF until version 1.6 - which is why the Dorico PDFs, which state they are V1.4, don’t embed it directly but convert it to the older Type 2 format.

On macOS, the FontName entry for the subsetted fonts embedded in the PDFs exported by Dorico is set by Qt’s PDF export exactly as specified in section 5.5.3 of the PDF specification, i.e. the font’s name is prefixed with a six-letter sequence followed by a plus sign. On Windows, this same prefix is applied, but then the complete path to the font is given. As I said earlier, I’m not sure of the exact reason for this choice of value for the name field, but I’m reasonably sure it’s intentional. I’ll report back as and when I hear anything from the Qt developers about this choice.

Possibly, because one half of Microsoft isn’t talking to the other half, and Windows apps from the Microsoft app store install their fonts in a different place from \Windows\Fonts, which some parts of the Windows OS (e.g. the font manager!!!) don’t know about.

So theoretically you could have two different versions of “myfont.otf” embedded in the same PDF, one from Windows itself, the other from an app :frowning: