How to delete Windows 10 system fonts for real, not just remove registry references to them

My last post implied that I ego-surfed and found a Wikipedia chat entry about me, but that’s not the case. I was searching for information on how to remove a system-protected font from Windows 10, and seeing as I often post solutions to obscure technical issues on here, I had hoped I recorded my how-to last time. The libel posted by some Australian Wikipedia editor came up during that search.
   Once upon a time, Microsoft didn’t care if you removed system fonts, but at some point, it began protecting Arial, whose design, for reasons I’ve gone into elsewhere, I’ve always considered compromised. There was one stage where you could replace Arial with something else called Arial, and as I had a licence for a very, very old Agfa version of Helvetica (do people remember CG Triumvirate?!), I decided to modify its file name to fool Windows into thinking all was well.
   The last time Windows did an update—version 1909—I had to resort to a safe-mode boot and taking control of the font files as admin, but I really could not remember the specifics. The problem is that when you install the “new” Arial, the existing roman one is used by quite a few applications, and you don’t really replace it—your only solution is to delete it.
   With version 2004, safe mode is quite different, and the command prompt and Powershell commands I knew just didn’t cut it. I realize the usual solution is to go into the registry keys—I’ve used this one for a long, long time—and to remove or modify the references to the offending fonts at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. I’ve also used the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes key to make sure that Helvetica does not map on to Arial (in fact, I make sure Arial maps on to Helvetica). Neither actually works in this case; they are ignored, even bypassed by certain programs. And, really, neither deletes the file; they just attempt to have Windows not load them, something which, as I discovered, doesn’t prevent Windows from loading them.
   By all means, use these methods, but be prepared for the exception where it doesn’t work. The claim that the methods ‘delete’ the fonts is actually untrue: they remain in C:\Windows\Fonts.
   The other methods that do not work are altering the equivalent keys under WOW6432node (which get intercepted and directed from the 32-bit keys anyway), using an elevated command prompt to delete the files (at least not initially), or doing the same from safe mode (which is very different now, as safe mode is in the same resolution and the Windows\Fonts folder displays as it does in the regular mode—so you cannot see the files you have to remove). You cannot take ownership of the font files through an elevated Powershell (errors result), nor can you do this from safe mode. Nothing happens if you delete FNTCACHE.DAT from the system32 directory, and nothing happens if you delete ~fontcache files from the Local directory.
   What was interesting was what kept calling arial.ttf in the fonts’ directory even after “my” Arial was loaded up. The imposter Arial loaded in most programs, but for the Chromium-based browsers (Vivaldi, Edge), somehow these knew to avoid the font registry and access the font directly. This was confirmed by analysing the processes under Process Monitor: sure enough, something had called up and used arial.ttf.
   This Wikihow article was a useful lead, getting us to delete the fonts under the Windows\WinSxS folder, and showing how to take ownership of them. I don’t know if altering these ultimately affected the ones inside Windows\Fonts, but I followed the instructions, to find that the original Arial was being accessed by three programs: Vivaldi, Keybase, and Qt Qtwebengineprocess. I shut each one of these down and removed the Arial family.
   Reboot: it was still there. Then it hit me, and I posted the solution in the Microsoft Answers forum (perhaps inadvertently prompting a Microsoft programmer to make things even harder in future!). Another user had told me it was impossible, but I knew that to be untrue, since it had been possible every other time.
   The solution is pretty simple: since you can’t see the full Windows\Fonts directory with Windows Explorer, then I needed another file manager.
   Luckily, I had 7zip, which I opened as an administrator. It allowed me to go into the folder and view all its contents, not just the fonts called up under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts, which we know is not an accurate representation of the fonts being used by the system. From there I could finally delete the offending four fonts without changing the ownership (which makes me wonder if the Wikihow advice of changing the owner under Windows\WinSxS wound up affecting the Windows\Fonts files). Once again, I had to close Keybase, Vivaldi and Qt Qtwebengineprocess.
   It took from c. 4 p.m., when my desktop PC updated to v. 2004 (my laptop had been on it for many weeks; soon after its release, in fact) to 2 a.m., with a break in between to cook and eat dinner. I’m hoping those hours of having typographic OCD helps others who want to have a font menu where they determine what they should have. Also, user beware: don’t delete stuff that the system really, really needs, including an icon font that Windows uses for rendering its GUI.

Using Google as a last resort—except this search, which I did again as an illustration, now displays in CG Triumvirate rather than Arial. Normally, Google is a big Arial user (Arial and sans-serif are in the CSS specs) and Chromium browsers are all too happy to circumvent the registry-registered fonts and go straight into your hard drive.