Inconsistent Incorrect Font in PDF Output

1

Hi there,

I’ve been working on a custom theme lately, doing a lot of reading of the various guide pages and I don’t know how many forum posts (though many seem to have been from prior to some major changes made last year in relation to fonts). In the process I’ve run into an interesting and apparently previously unquestioned issue with using custom font families.

Whilst many issues I’ve read about seem to have been from broken custom themes people have produced, this issue is reproducible with the default “Plain” theme, and any theme I’ve tested.

I understand that the “font-family: NAME” style attribute requires that the font family be installed on the system. So, whilst I’d normally use a font manager (which every other program has no issue with, including within the ‘View’ of the theme in Manager) I figured hard-installing one family the old way isn’t going to cause major drama. I’m using Windows 10 (v2004, b19041.388), so installed the font by the standard method of ‘Right Click’ > ‘Install for all users’, which results in a UAC elevation and the font being installed alongside all other system fonts in C:\Windows\Fonts .

During testing this, I isolated the issue so it is reproducible with the default “Plain” theme by only adding “font-family: xx” in one specific location, in this case line 6 (i.e. the document title):
<td style="font-weight: bold; font-size: 32px">{{ title }}</td>
became:
<td style="font-family: Jost; font-weight: bold; font-size: 32px">{{ title }}</td>

In this example I’m using Jost (Jost - Google Fonts); for branding reasons it’s what I hope to use in the end. What results from this is:

Font Wrong Substitution
Font Wrong Substitution610×560 26 KB

You can see that for some reason the PDF export substituted Jost for OCRAStd, which is some other font within C:\Windows\Fonts (it’s licensed from Adobe, so I assume was installed with some adobe software).
Now if I pick another font family which I know comes with Windows itself, say Arial (or Agency FB, as in the guide example), it works as expected:

Font Correct Substitution
Font Correct Substitution610×560 22.2 KB

My first suspicion was that for some reason user (even admin) installed fonts would fail for some reason and be substituted in the same way, however that OCRAStd font itself was most likely installed by the admin user (i.e. what occurs when elevating a software installer via the UAC prompt). To test this more specifically I found some other font families installed by/with 3rd party software and they all work correctly in the PDF output if they were installed to C:\Windows\Fonts. If they’re “installed” to another location the same substitution with OCRAStd occurs. In this case by “installed” I mean visible in the font list in Windwos 10 Settings > Personalisation > Fonts, and/or Control Panel > Fonts, but located in an unusual location such as some application’s Program Files folder.

My next suspicion was (and still is) that it’s something to do with the Windows font cache service. All I’ve done to test that so far was closing manager, installing the font to C:\Windows\Fonts as above, restarting the computer, and re-opening manager; unfortunately the results were the same, so I’m stuck.
Any ideas what might be happening?

Manager v20.8.23

edit after solution:
I didn’t notice until now that even when the correct font carries through to the PDF the font weight is wrong (i.e. the font-weight style attribute seems to be ignored in PDF output). See posts 6 and 7 below for the combined solution

2

Manager uses a third party program for the pdf creation so it may be a bug with the pdf addon.

One thing that I can think of that there might be some issue with the font that you are installing - eg it might not be truetype for example and the pdf program won’t support the font.

Try using the font in word and see if that works, but try another font from another website. I don’t think being user installed is the issue, but a compatibility issue with the font you are installing. Hard to say.

1 Like
3

You may be right about it being an issue with the third party. I guess that’ll be something for the devs to fully determine.

I’ve just tried with a few other custom fonts installed for the purpose of testing, both OpenType and TrueType spanning relatively new to ~20 years old, from various sources. None of them worked unfortunately. However, it at least doesn’t appear to be specifically related to font type, as OCRAStd is OpenType, as is Caslon (another one I tested originally which worked). Arial, Agency FB, and Jost are all TrueType, but Jost doesn’t work.

In the interest of sharing the info, every font I’ve tested has worked with every other program I’ve tested it in (including Word, and within Manager itself in the ‘View’ previews).

4

Then it would be something that @lubos would have to answer. I don’t know what 3rd party program is being used and what could be causing the problem. The program may be looking for a registry entry for that font which is not being installed when you install it as a user? Hard to say. The developer will have to look into it.

5

There was a discussion 2 years ago about Microsoft’s unwillingness to use 3rd-party fonts: Font type and size - #15 by Tut. But it did not extend to the entire operating system. Maybe that has been tightened up.

6

@hijomojo try something like this:

font-family: ‘Jost Regular’, Jost

This could make it work both in View and PDF at the same time.

However, this is really a workaround. I need to implement ability to upload custom fonts to themes directly. This way Manager won’t be relying on operating system for fonts. This will also solve issue where transferring business file between computers - the fonts won’t need to reinstalled as they would be bundled within the custom theme.

2 Likes
7

I agree, it would be great for custom fonts to be added into the business such that they become portable.
For the mean time though, I’m happy to use that naming syntax as it does solve it and shouldn’t be too much work to adapt to a potential future font method.
Thanks very much for the help!

In case others run into the issue, using this workaround you have to set the font weight in the name used in font-family, as well as within the font-weight style attribute. So for me, starting from:
<td style="font-family: Jost; font-weight: bold; font-size: 32px">{{ title }}</td>
you can see I was aiming to use the Bold weight, so the new line used is:
<td style="font-family: 'Jost Bold', Jost; font-weight:bold; font-size: 32px">{{ title }}</td>
Without that font-weight style attribute also set to ‘bold’, the preview View uses the Regular weight font, whilst the PDF output uses the Bold weight.

8

I’m removing this topic from ideas category on the basis that this issue is in internal PDF generator which is now obsolete.

There is now new approach which doesn’t have this issue.