Font installation stuff

Just wanted to link up this thread with a question I posed on the cairo mailing list.

http://lists.cairographics.org/archives/cairo/2007-August/011201.html

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:
[...]

One middle ground I thought of since my first message is to use fc-list to get a list of all the fonts on the system, and continue to use font_manager.py for the font matching. If "fc-list" is not available, it could fall back to the hard-coded paths it uses now. Of course, the matching in font_manager.py would still need to be improved.

Sounds reasonable.

While you are poking around in font_manager: this is one of the biggest chunks of mpl script startup time, even with the present caching. I haven't looked very closely or done any testing, but I suspect more extensive caching could work fine. Specifically, can the entire fontManager instance be pickled, and loaded if it exists?

Eric

Cheers,
Mike

Quick status update --

I've committed code to font_manager that will retrieve the list of all installed fonts from fontconfig if available (using making a shell call to fc-list). This will handle the cases where users want to use fonts that have been installed in non-standard places or their distributions do something different.

I've decided to put off making other improvements to font_manager for the time being. I'm somewhat torn between adding a dependency on fontconfig and having all those issues taken care of by others, or adding incremental fixes to font_manager, but maintaining easy Python-level portability.

A new thing that makes fontconfig particularly compelling is looking up fonts based on the character sets they contain. This would be very useful for mathtext when using non-Computer Modern (Bakoma) fonts, for instance. It could all be done without fontconfig, of course, but it would be reinventing a rather large wheel.

My original impetus to support fontconfig, to help the Cairo backend behave more like our other backends, is less important, IMHO. It seems unlikely, from my response on the cairo mailing list, that pycairo will grow an API to load fonts directly from a file.

Some more information --

- I've successfully built it on Mac and Windows (with Mingw32) and it seems to be doing the right things there, without any post-install configuration work.

- The API allows applications to add their own font directories on the fly, so everything could continue work the way it does now (by looking in the mpl-data directory for fonts).

- The Python wrappers for the parts we need would be quite minimal. (Probably only two functions FcFontMatch and FcConfigAppFontAddDir.)

- fontconfig depends on expat for XML reading.

- It appears that both the fontconfig and expat licenses would permit us to distribute them with matplotlib if we chose to. We would probably only want to use the embedded versions when the OS doesn't provide it (OS-X and Windows).

In any case, I'm just putting this on the table. It's always hard to weigh those tradeoffs.

Cheers,
Mike

Michael Droettboom wrote:

···

Just wanted to link up this thread with a question I posed on the cairo mailing list.

http://lists.cairographics.org/archives/cairo/2007-August/011201.html

Cheers,
Mike

Eric Firing wrote:

Michael Droettboom wrote:
[...]

One middle ground I thought of since my first message is to use fc-list to get a list of all the fonts on the system, and continue to use font_manager.py for the font matching. If "fc-list" is not available, it could fall back to the hard-coded paths it uses now. Of course, the matching in font_manager.py would still need to be improved.

Sounds reasonable.

While you are poking around in font_manager: this is one of the biggest chunks of mpl script startup time, even with the present caching. I haven't looked very closely or done any testing, but I suspect more extensive caching could work fine. Specifically, can the entire fontManager instance be pickled, and loaded if it exists?

Eric

Cheers,
Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom wrote:

Just wanted to link up this thread with a question I posed on the cairo mailing list.

http://lists.cairographics.org/archives/cairo/2007-August/011201.html

Cheers,
Mike

Eric Firing wrote:

Michael Droettboom wrote:
[...]

One middle ground I thought of since my first message is to use fc-list to get a list of all the fonts on the system, and continue to use font_manager.py for the font matching. If "fc-list" is not available, it could fall back to the hard-coded paths it uses now. Of course, the matching in font_manager.py would still need to be improved.

Sounds reasonable.

Your change to use fontconfig slightly raised the time for backend_driver.py Template: 0.50 -> 0.53 minutes.

While you are poking around in font_manager: this is one of the biggest chunks of mpl script startup time, even with the present caching. I haven't looked very closely or done any testing, but I suspect more extensive caching could work fine. Specifically, can the entire fontManager instance be pickled, and loaded if it exists?

I tried this (svn diff is attached), and it cut the time above to 0.43 minutes. I have not committed it; I very much like doing what we can to reduce startup time (which is important for applications that run simple plots as standalone scripts), but perhaps the approach here will cause too much trouble, or will require better error trapping downstream to handle the case where the fontManager actually needs to be rebuilt.

Eric

font_manager.diff (1.1 KB)

···

Eric

Cheers,
Mike