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.

This means:

• on Linux,fc-list --format='%{file}\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).

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

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

This 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 runpython -mmatplotlib.font_manager recache --add-font-path foo --add-font-path bar, with the expected effect (in fact there's already the (undocumented)TTFPATH andAFMPATH environment variables which have the same effect).

Thoughts?