You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: findSystemFonts should not look in subdirectories of C:\Windows\Fonts\ #22859
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.
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 :-)
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.
changed the title [-][Bug]: findSystemFonts should not look in C:\Windows\Fonts\Deleted[/-][+][Bug]: findSystemFonts should not look in subdirectories of C:\Windows\Fonts\[/+]on Apr 26, 2022
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).
Activity
anntzer commentedon Apr 18, 2022
Do you have a reference documenting this directory? Thanks.
moi15moi commentedon Apr 18, 2022
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\Fontsin your Windows File Explorer.anntzer commentedon Apr 18, 2022
My point is that if there is no documentation stating that we should ignore this directory, then we shouldn't ignore it.
moi15moi commentedon Apr 18, 2022
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
anntzer commentedon Apr 18, 2022
Can you try to ask them for a reference?
tacaswell commentedon Apr 18, 2022
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 ;).
moi15moi commentedon Apr 19, 2022
Since @tacaswell want to contact Raymond Chen, do you still want me to open a thread on Microsoft Q&A ?
tacaswell commentedon Apr 20, 2022
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!
moi15moi commentedon Apr 23, 2022
Here you go: https://docs.microsoft.com/en-us/answers/questions/823422/what-is-exactly-cwindowsfontsdeleted.html?childToView=823435#answer-823435
anntzer commentedon Apr 23, 2022
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 :-)
tacaswell commentedon Apr 23, 2022
I am not convinced to that we should take that answer as authoritative.
jklymak commentedon Apr 23, 2022
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.
timhoffm commentedon Apr 24, 2022
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:
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.
anntzer commentedon Apr 24, 2022
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 :)
timhoffm commentedon Apr 25, 2022
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.
[-][Bug]: findSystemFonts should not look in C:\Windows\Fonts\Deleted[/-][+][Bug]: findSystemFonts should not look in subdirectories of C:\Windows\Fonts\[/+]anntzer commentedon Apr 26, 2022
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).
moi15moi commentedon Apr 29, 2022
Thanks !
skip sub directories when finding fonts on windows