PAC Display Configurator font display issues in Windows 11

I recently loaded PAC Project 10.3 onto a new development laptop that came bundled with Windows 11. Spent most of the week coding in PAC Control with no issues whatsoever. Finally went to start on some PAC Display tasks and found the following annoying display glitch with the Edit Graphic Dynamic Attributes dialog box:

Firstly noted the font looked a bit suss but then noticed the Tag selection box (and the little question mark button used to open it) had been pushed into unreachable territory off the right edge of the fixed-size dialog box. Didn’t find any useful solutions on the web so I ran through a .exe resource decompiler to look for clues on what was messing things up.

Solution 1: Resize the Graphic Dynamic Attributes dialog box and recompile Not ideal but this at least gained some space and allowed me to get at the tag selection window. Added 100px width to the main DialogEx Box object so it was 568px(W) wide instead of 468px(W). Then added 100px to the embedded Dialog Box that holds the various attributes that can be edited taking it from 122px(W) to 222px(W). Perhaps enabling resize on this dialog box would be an easy fix in the next version of PAC Config.

Then looking closer at the fonts and styles it looks like the main GraphicDynamicAttributesDlg object uses DS_SHELLFONT style with the standard “MS Shell Dlg” logical-font which Windows 11 has assigned to “Microsoft Sans Serif” in the Windows Registry. This font displays correctly in all areas outside the green box shown below:

The area inside the green box is the embedded Button Control containing each of the editable controls for the individual attributes in the dropdown lists on the left. Looking further through each of these resource files, each of their respective Dialog Boxes are set to style DS_SETFONT with font either set to “Helv” or “MS Sans Serif”. All of these items do not display correctly and have the dodgy font that pushes everything outside the window.

Solution 2: Edit the Operating System Logical Font allocations in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes holds the following assignments by default on this Windows 11 build:
“Helv” = “MS Sans Serif” … [doesn’t display correctly]
“MS Shell Dlg” = “Microsoft Sans Serif” … [does display correctly]

Simply change the value assigned to the “Helv” registry entry to be “Microsoft Sans Serif” instead of “MS Sans Serif”, reboot and all is well and the fonts are displayed correctly throughout the whole GraphicDynamicAttribute popup. MS Sans Serif seems to be the problem.

Before Registry Change:

After Registry Change:

I don’t know enough about Windows API programming so I may be talking complete BS but I am guessing that it is some legacy thing from old versions of Windows and early Factory Floor etc where MS Sans Serif is bitmap based and Microsoft Sans Serif is a scalable true type. Also not sure why this was never an issue on my other Windows 10 machines either as the registry entries are the same. Could this be a strange setting that has only emerged in Windows 11 because I have my Windows language set to English (Australia) instead of English (US) and Windows 11 is handling unicode fonts differently?

Anyone got any better solutions to this? If not, is this something that the team at Opto have encountered during Windows 11 testing?

Edit: I have also tried PAC Project Professional 10.4 and the most recent 10.5 builds and they give the same results. Preference to stay with 10.3 for now as it is tried and true with currently deployed assets.



Hi Sean.

I see you’re a long-time contributor to the OptoForums. One of my roles at the company is maintaining PAC Display. Thank you very much for digging into this issue so thoroughly. You really did a fantastic job.

I’m aware of at least one other user’s laptop that displays the Graphic Dynamic Attributes improperly, as you’ve experienced. They were using a ThinkPad MT-20TD, with an Intel Iris Xe integrated graphics chip, on Windows 10. I’ve been unable to reproduce the rendering issue on Windows 10, or 11 myself with the hardware I’m using. If you don’t mind, could you tell us what kind of laptop you have?

I’ll dig into your findings, and see if I can at least attempt a benign, font-related, solution.

Thanks again for your work here.


G’day Chris

Yes a big fan of the forum here. Great community of others living and breathing opto. I have found many weird and wonderful bits of info on here that have helped me greatly over the years.

This Windows 11 machine is a Lenovo Legion 7 Pro 7i with RTX 4080 GPU. I’m not really up with the details on latest chips etc but the additional on-board GPU info is found in processor specs:

Interesting that it may be some sort of bizarre edge-case. Thinkpad/Lenovo common element?

I have dozens of machines (mostly Stealth industrial rackmounts, Razer Blade Pro laptops, Microsoft Surface Pros, some Alienware M17 laptops, Dell Desktops and more) all running Windows 10 and PAC Project Pro 10.3 with zero issues. I have never encountered this font thing until this week when it stopped me in my tracks. Unfortunately this is the only Windows 11 device I have so I naturally opted for blaming it and have nothing else to run comparisons on. Some of these machines are running Home Edition too, despite it not being recommended.

For now, the registry edit solution will suffice so I can get on with things as I will continue most my dev work on this machine and push out to the working systems. ie no rushed upgrades to 10.4 or 10.5 for all the field systems just yet…

Keen to hear if anyone else encounters the same thing.



Hello again, Sean.

Thank you again for going above and beyond digging into this bug.

And thank you for providing the type of laptop you’re using. Nice 4080!

With all the information you’ve provided, I’ve gone ahead and replaced all “Helv” and “MS Sans Serif” font references throughout PAC Display with the “Microsoft Sans Serif” font. This fix will be in PAC Display 10.6. I think you’re right, and Microsoft Sans Serif is a TrueType, vector font, whereas MS Sans Serif is a legacy rasterized font from the early days of Windows and that’s throwing off the dimensions of the dialog.

Thank you again for sharing all the legwork you put into this so we could get it addressed.



I’ve had this issue for months now. I tried changing the registry and also have had luck with that window. Are you also having issues with the Runtime Setup window (Configure > Runtime)? After changing the registry that window is still pushed off the right side of the window.

Hi @vmsMark
I’ve also since found that the issue extends throughout other dialog boxes within the Display Configurator program, beyond the specific Dynamic Attributes issues detailed above. It turns out there are many other windows that don’t actually use the ‘logical’ fonts which can be corrected with the registry edits suggested above but in fact call for using the problem font explicitly, namely “MS Sans Serif”. The only way I could resolve it was to decompile the executable again, find the rest of the 70-odd instances of “MS Sans Serif” and replace them with “Microsoft Sans Serif” and recompile. This resolved the issue for every case of what your screen shot shows above but was quite time consuming…

Then as I was typing this I realised how convoluted that is and tried the following fix:

(1) Open regedit and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes\

(2) Right click and add a new “String Value” key in with all the other font substitute keys.

(3) Name it “MS Sans Serif” and give it the string data value “Microsoft Sans Serif”

(4) Restart Windows

To my surprise this simple solution solves the issue for all windows in Configurator and requires no fussing about with decompilers. Basically we have “font-substituted” MS Sans Serif completely out of the picture, perhaps back to the swamp of Windows 3.1 where it probably first emerged. Who knows what havoc this will wreak with other legacy windows apps but who cares right…

And as Chris mentioned in the previous post, we can expect the issue will be resolved with the release of PAC Project v10.6


Thank you very much @seanMacRae

1 Like