René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Rely on OS-level tools for building the font cache","articleBody":"The root issue of #10201 appears to be that in some OSX systems, /FontCollections is included in the font paths searched by the system, but not listed in the hardcoded paths in font_manager.py.  While this could be fixed in a piecemeal fashion, I would like to propose instead to strictly rely on OS-level tools to list fonts instead.\r\n\r\nThis means:\r\n- on Linux, `fc-list --format='%{file}\\n'`\r\n- on OSX, `system_profiler SPFontsDataType` (whose output can trivially be parsed by the stdlib plistlib module) (and fc-list too, if it is present).\r\n\r\nOn Linux, Xorg relies on fontconfig for font selection since at least X11R6.9 (2005; https://www.x.org/archive/X11R6.9.0/doc/html/fonts2.html#3 -- oldest doc on x.org).  On OSX, system_profiler appears to be available since at least OSX 10.0 (2001; https://en.wikipedia.org/wiki/System_Information_(Mac)).\r\n\r\nOn Windows, we are already reading the fonts and font paths from the registry, which appears to be the \"correct\" place where the info is stored (https://msdn.microsoft.com/en-us/library/windows/desktop/dd144833(v=vs.85).aspx).\r\n\r\nThis means that on (rare) systems where fontconfig is not present, we'll only find the fonts shipped with Matplotlib (dejavu, etc.).  To work around this, we can allow the user to run `python -mmatplotlib.font_manager recache --add-font-path foo --add-font-path bar`, with the expected effect (in fact there's already the (undocumented) `TTFPATH` and `AFMPATH` environment variables which have the same effect).\r\n\r\nThoughts?","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2018-03-31T23:45:20.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/10932/matplotlib/issues/10932"}