fixes #2097, pgf: get scalable system-fonts from fontconfig, rely on builtin fonts for tests

[pwuertz]

Within the pgf backend, find scalable system-fonts by calling fc-list from fontconfig instead of using matplotlib.font_manager.
When performing tests, rely on the default built-in fonts instead of Bitstream Vera Sans.

[pwuertz]

This probably requires some more testing. I'm halfway convinced that fontconfig is a requirement for a TeX installation, which means that one could base font-finding solely on fc-list (even on win32). In the end fc-list should be the preferred option for XeLaTeX since it can filter out bitmap fonts and returns non-ttf fonts as well.

It would be nice if this output could be checked by a few OSX users:

import matplotlib.backends.backend_pgf as pgf
print pgf.system_fonts

[jenshnielsen]

I'm not sure about fc-list on OSX. I have macTeX installed which does not seem to require fontconfig. But I have 3 fc-list binaries installed by other programs. 1 using homebrew package manager as a pango dependency. Xquarts also installes it's own and further more the julia dmg image also installed one. But none of these are TeX dependencies as far as I know.

[pwuertz]

This is indeed puzzling. After reading a few http://tex.stackexchange.com posts I'm getting the impression that XeTeX is based on fontconfig, LuaTex on the other hand uses its own lua-based solution.

http://tex.stackexchange.com/questions/12881/how-to-get-a-list-of-all-available-ttf-fonts-with-xetex
http://tex.stackexchange.com/questions/14162/how-do-i-get-a-list-of-all-available-fonts-for-luaotfload

[mdboom]

@pwuertz: How would you evaluate the status of this vis-a-vis putting another release candidate out?

[pwuertz]

I'm not comfortable with this at all. To get this right, this needs a lot more work and organized testing across multiple systems.

I'd put this issue to the list of known bugs and fix it once I figured out which TeX engine supports which fonts on which OS and how.

[mdboom]

Ok, fair enough. Just wanted to get your take on this before proceeding. Thanks.

[dmcdougall]

Given @pwuertz is uncomfortable with this solution, should we punt this to a v1.3 bugfix release rather than keeping it a blocker?

[mdboom]

Yes, let's do that. We can just use the pre-existing 1.3.x label.

[dmcdougall]

Releasing magical Github ponies: this PR is attempting to fix #2097.

[NelleV]

Small nitpick: the second line is not well align with the first line of the dict.

[pwuertz]

I'm confused.. did I close this one?

[mdboom]

It appears so -- it's awfully easy to do by accident. If this isn't resolved, we should also reopen #2097.

[NelleV]

This is due to the commit message of
#2117

fixes #id or closes #id in a commit message will close the ticket, once the
PR is merged.

On 17 September 2013 22:01, Michael Droettboom notifications@github.comwrote:

It appears so -- it's awfully easy to do by accident. If this isn't
resolved, we should also reopen #2097#2097
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2117#issuecomment-24617593
.

[pwuertz]

Hm, but the PR was not merged. Also, it seems that I cannot open the PR anymore.