Do you have a reference documenting this directory? Thanks.

No, I don't have any reference. I actually search on the web and I was surprised to find nothing about that.

If you want to access to the folder, write \\localhost\c$\Windows\Fonts in your Windows File Explorer.

My point is that if there is no documentation stating that we should ignore this directory, then we shouldn't ignore it.

I see.
I can only say that when you delete a font, it goes in that folder and want you reboot, this folder seems to become empty.

Someone would need to open ask the question on Microsoft Q&A

Can you try to ask them for a reference?

I have a suspicion that this is due to not being able to delete an open file on windows but being able to move it. Thus when you delete a font, they can not be sure no one is using it / detect if someone is using it, move the file to a well-known to be deleted on reboot location, and then on the way up or on the way down (when they are sure no user program is running) they actually delete it.

This is something we should try to nerd-snipe Raymond Chen (https://devblogs.microsoft.com/oldnewthing/ /@oldnewthing) into explaining for real ;).

Can you try to ask them for a reference?

Since @tacaswell want to contact Raymond Chen, do you still want me to open a thread on Microsoft Q&A ?

That was (mostly) a joke, but yes reaching out through Microsoft's support channels to get a definitive answer to this would be greatly appreciated!

Here you go: https://docs.microsoft.com/en-us/answers/questions/823422/what-is-exactly-cwindowsfontsdeleted.html?childToView=823435#answer-823435

The suggested solution of using EnumFontFamiliesEx doesn't really work for us, as we need an actual filename, not just a win32 LOGFONT structure (as we rely on FreeType for rendering, not on the Windows API). A quick googling suggests that 1) many people want to go from LOGFONT to filename and 2) they are always told that this is not possible.
The best I found was https://stackoverflow.com/a/11623081/378080 which uses DirectWrite and would probably require quite a bit of engineering to set up.

Perhaps a much simpler point is to ask whether Windows actually searches for font files in subdirectories of c:/windows/fonts (this is not clear to me from the docs, and could easily be tested if you have a windows machine available, e.g. by temporarily moving a font to a subdirectory and check (perhaps after reboot) if Windows detects it. If it doesn't, then we just need to change the search algorithm to ignore subdirectories :-)

I am not convinced to that we should take that answer as authoritative.

The other simple check is to delete a font, open an app like Word before rebooting and see if it is there or not. Someone with a Windows machine will just have to do a bit of experimentation for us.

The other simple check is to delete a font, open an app like Word before rebooting and see if it is there or not. Someone with a Windows machine will just have to do a bit of experimentation for us.

When I delete a font on windows, it's not available anymore in Word. OTOH I also do not get a "Deleted" folder (not even if I open Word, create a document using that font and then deleting it).

The "Deleted" folder seems like an implementation detail of windows, which might change over time.

For me both variants would be ok:

• Don't special-handle \fonts\deleted as this seems some internal logic we don't want to get involved to. This would mean we close this as "won't fix" - it's quite a special case and not the end of the world (one could have started matplotlib first and then deleted the font, which would bring us into the same situation). - Semi-OT does anybody know whether the c:\Windows\Fonts can regularly have subfolders or should we only look in that folder without subfolders anyway?
• Just ignore c:\Windows\Fonts\Deleted. Even if we don't exactly know its semantics, intuition suggests that fonts in that folder should not exist semantically. The risk that it contains fonts a user legitimately wants to use is negligible.

Either way, I think it's not work spending much time on this. Let's just go one way or the other and move on.

does anybody know whether the c:\Windows\Fonts can regularly have subfolders or should we only look in that folder without subfolders anyway?

That's what I suggested in #22859 (comment): can you quickly try if moving a font to a subdirectory (e.g. c:\windows\fonts\whatever) (perhaps rebooting after that in case there's any caching) makes it invisible e.g. to word? Thanks :)

I tested the reverse: Adding a font in a subfolder (with reboot). That font is not visible. Also, you need admin rights to do so since the font folder is protected, and the GUI-Font installation always goes to c:\windows\fonts. So I guess we should not check any subdirectories.

Marked as good first issue, as this is now reasonably easily actionable with no API design questions (you may need to wade a bit in the waters of font_manager.py, though).

Very good first issue :)
Going to take care of it if you don't mind

Thanks !