Darn, you’re right. Hoped this was the answer to your conundrum…
You do have a strange font manager. Is it caching fonts? Maybe?
If you look at my screenshot link you’ll see that the top one is definitely the same 
I have not examined the properties yet thought so I will absolutely check to see if it has been modified when I get home from work
Unfortunately I don’t think that’s it either, I’ve reset the windows font cache a few times now 
And these are also just the default windows 11 font manager/font viewer applications haha.
Here is the properties, everything looks correct, never modified or anything.
1 Like
I finally fixed it!! Thank you so much @AmberV and @AntoniDol for all your help! The fix came down to this (without uninstalling 
):
- Using the startup log I saw that after all the other fonts had loaded, two other fonts ended up being loaded at the very end from ‘C:\Users<username>\AppData\Local\Microsoft\Windows\Fonts’
- Located here was a collection of fonts I have never seen before and a draft copy of the custom font (This draft copy that held the half-filled out glyphset that was being read by scrivener as Times New Roman) as well as a second Times New Roman font that was also uncorrupted.
- I uninstalled the font draft (which does NOT show up in any font lists anywhere, so thank you microsoft for that) and then reinstalled my custom font. NOTE: I did not touch the second copy of Times New Roman
- Restarting scrivener, both Times New Roman and my custom font now work correctly.
So for some reason, scrivener read the C:\Windows\Fonts version of both the fonts correctly the first time it loads them, it then loads each a second time from the C:\Users<username>\AppData\Local\Microsoft\Windows\Fonts folder but confuses the draft of the custom font with the second copy of Times New Roman which appears in Scrivener as a corrupted Times New Roman font.
Without knowing more about how scrivener works internally I can’t begin to guess why scrivener would confuse the second version of the custom font (which had the name halrian0_0.ttf) with Times New Roman but not override TNR again when the second Times New Roman was loaded. As a software engineer myself I think this might warrant at least a little investigation from the dev team. While I most likely screwed up the initial install when first testing my font it wouldn’t hurt to investigate at least a litte and this didn’t cause problems in any other text-editing software.
Thank you all so much again for your help, scrivener is already everything I always wished word and google docs were!
3 Likes
Also thanks to @r6d2! I got a warning saying I can only mention two people in a post haha, but thank you just as much!
1 Like
Whew! Glad to hear you got it figured out. I had completely forgotten about you could install fonts into the AppData folder like that.
We’d be happy to take a look at the specific conditions, as it does seem off to me, but it might have something to with how you created the custom font. Assuming for example you started off by duplicating TNR and then going from there, perhaps the font editor you used doesn’t reveal all the internal handles by which a font is declared, and that one just so happens to be the one the Qt frameworks use to identify fonts internally—because then that would make sense, that a user level font would override a system level font. I think that in and of itself is typical, it’s the identification of it ending up overriding a “different” system font that is a bit odd.
What might work best is if you send us the TTF file(s) that were in the AppData folder, so we can try to replicate the scenario.
1 Like
Same, I was so confused when I saw it loading those paths. And I would believe it has something to do with how I created the font, I used FontLab 8 to make it and I definitely started with the Times New Roman glyphset, and it’s possible I didn’t override some default somewhere with the first draft that I did override in the final draft. That would explain the fact I can have the final custom font coexist with Times New Roman but not the original draft. I will send over the fonts from the AppData folder when I get back from work tonight.
1 Like
I have a few fonts on that folder as well, although they come mostly from chocolatey. I guess ubuntu font came from WSL install.
I went ahead and found the font drafts in my recycling bin and can confirm I did not override the name in the font metadata, so when the ttf file for the draft font gets read, Qt can only see that the metadata name which is ‘Times New Roman’ 
So not a bug, just Qt doing something reasonable. I would be curious to find out how the microsoft programs handle this collision gracefully. I suspect they compare all the versions of similarly named fonts and use the newer version, the official Times New Roman version number is 7.05 and my font is version 1.0 in the misnamed draft so if word chooses the ‘newer’ version based of version it would avoid this issue. Not sure if Qt allows this sort of customization easily, but might be worth a look.