Skip to content

[Bug]: findSystemFonts should not look in subdirectories of C:\Windows\Fonts\ #22859

Description

@moi15moi

Bug summary

findSystemFonts takes the font in the directory: C:\Windows\Fonts\Deleted

It should not take them. They are supposedly deleted. It is better to ignore them.

Code for reproduction

matplotlib.font_manager.findSystemFonts

Actual outcome


Expected outcome


Additional information

No response

Operating system

Windows

Matplotlib Version

3.5.1

Matplotlib Backend

No response

Python version

No response

Jupyter version

No response

Installation

pip

Activity

  1. anntzer commented on Apr 18, 2022

    @anntzer
    Contributor

    Do you have a reference documenting this directory? Thanks.

  2. moi15moi commented on Apr 18, 2022

    @moi15moi
    Author

    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.

  3. anntzer commented on Apr 18, 2022

    @anntzer
    Contributor

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

  4. moi15moi commented on Apr 18, 2022

    @moi15moi
    Author

    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

  5. anntzer commented on Apr 18, 2022

    @anntzer
    Contributor

    Can you try to ask them for a reference?

  6. tacaswell commented on Apr 18, 2022

    @tacaswell
    Member

    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 ;).

  7. moi15moi commented on Apr 19, 2022

    @moi15moi
    Author

    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 ?

  8. tacaswell commented on Apr 20, 2022

    @tacaswell
    Member

    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!

  9. anntzer commented on Apr 23, 2022

    @anntzer
    Contributor

    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 :-)

  10. tacaswell commented on Apr 23, 2022

    @tacaswell
    Member

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

  11. jklymak commented on Apr 23, 2022

    @jklymak
    Member

    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.

  12. timhoffm commented on Apr 24, 2022

    @timhoffm
    Member

    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.

  13. anntzer commented on Apr 24, 2022

    @anntzer
    Contributor

    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 :)

  14. timhoffm commented on Apr 25, 2022

    @timhoffm
    Member

    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.

  15. 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
  16. added
    🌱 Good first issueOpen a pull request against these issues if there are no active ones!
    on Apr 26, 2022
  17. anntzer commented on Apr 26, 2022

    @anntzer
    Contributor

    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).

  18. added this to the v3.6.0 milestone on Apr 28, 2022
  19. moi15moi commented on Apr 29, 2022

    @moi15moi
    Author

    Thanks !

  20. added a commit that references this issue on Apr 19, 2026
    580f77e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions