small bugfix in font_manager.py

MPL 1.0.0, OSX

If USE_FONTCONFIG is turned on, the function FontProperties.get_size_in_points will sometimes fail, because it is wanting to use “fontManager”, which is still ‘None’ if USE_FONTCONFIG is on. I’m not sure if it’s the proper way to fix it, but here is a small patch that works (meaning that at least the code doesn’t die; I can’t vouch for much else):

ORIGINAL:

def get_size_in_points(self):

if self._size is not None:

try:

return float(self._size)

except ValueError:

pass

default_size = fontManager.get_default_size()

return default_size * font_scalings.get(self._size)

NEW:

def get_size_in_points(self):

if self._size is not None:

try:

return float(self._size)

except ValueError:

pass

if fontManager:

default_size = fontManager.get_default_size()

else:

default_size = rcParams[‘font.size’]

return default_size * font_scalings.get(self._size)

···


Daniel Hyams
dhyams@…287…

I personally think that this is reasonable, as it guarantees a size
value to come from somewhere. However, I am concerned about
fontManager being None. If it isn't a bug for it to be None at this
point, then I have to wonder where-else in the code needs a check for
None? If it is a bug, then what should it be when USE_FONTCONFIG is
true?

Good catch Daniel.

Ben Root

···

On Wednesday, November 24, 2010, Daniel Hyams <dhyams@...287...> wrote:

MPL 1.0.0, OSX
If USE_FONTCONFIG is turned on, the function FontProperties.get_size_in_points will sometimes fail, because it is wanting to use "fontManager", which is still 'None' if USE_FONTCONFIG is on. I'm not sure if it's the proper way to fix it, but here is a small patch that works (meaning that at least the code doesn't die; I can't vouch for much else):

ORIGINAL:
def get_size_in_points(self): if self._size is not None: try: return float(self._size)

        except ValueError:                pass        default\_size = fontManager\.get\_default\_size\(\)        return default\_size \* font\_scalings\.get\(self\.\_size\)

NEW:
def get_size_in_points(self): if self._size is not None: try: return float(self._size) except ValueError:

            pass        if fontManager:            default\_size = fontManager\.get\_default\_size\(\)        else:           default\_size = rcParams\[&#39;font\.size&#39;\]

    return default\_size \* font\_scalings\.get\(self\.\_size\)

--
Daniel Hyams
dhyams@...287...

The fontManager is essentially a replacement for what fontconfig provides on many platforms -- so it's intended that the fontManager doesn't exist if the user opts to use fontconfig. However, that's still an "experimental" option because it hasn't been formally tested on many platforms, and, as you point out, there may still be code paths that aren't coded correctly for that option.

Mike

···

On 11/25/2010 10:34 AM, Benjamin Root wrote:

On Wednesday, November 24, 2010, Daniel Hyams<dhyams@...287...> wrote:

MPL 1.0.0, OSX
If USE_FONTCONFIG is turned on, the function FontProperties.get_size_in_points will sometimes fail, because it is wanting to use "fontManager", which is still 'None' if USE_FONTCONFIG is on. I'm not sure if it's the proper way to fix it, but here is a small patch that works (meaning that at least the code doesn't die; I can't vouch for much else):

ORIGINAL:
     def get_size_in_points(self): if self._size is not None: try: return float(self._size)

             except ValueError: pass default_size = fontManager.get_default_size() return default_size * font_scalings.get(self._size)

NEW:
     def get_size_in_points(self): if self._size is not None: try: return float(self._size) except ValueError:

                 pass if fontManager: default_size = fontManager.get_default_size() else: default_size = rcParams['font.size']

         return default_size * font_scalings.get(self._size)

--
Daniel Hyams
dhyams@...287...

I personally think that this is reasonable, as it guarantees a size
value to come from somewhere. However, I am concerned about
fontManager being None. If it isn't a bug for it to be None at this
point, then I have to wonder where-else in the code needs a check for
None? If it is a bug, then what should it be when USE_FONTCONFIG is
true?

Good catch Daniel.

Ben Root

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App& Earn a Chance To Win $500!
Tap into the largest installed PC base& get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Just out of curiosity, is anyone using the fontconfig way of mapping fonts? I turned it on one day, but the immediate problem was that no mathtext worked any more; so I turned it back off. Any mathtext in titles, labels, etc. just rendered as a much of seemingly random letters.

And I’ll tack a second question in here as well; the reason that I was playing with fontconfig is that the font cache takes a really long time to build in certain circumstances (I’m having trouble identifying exactly when)…so I guess the question is…has anyone else seen this? For example, on my (2008 vintage) mac mini, a complete rebuild of the font cache takes around 3 seconds, which is fine. On a macbook pro (tested on three different machines so far), it takes 30 seconds. This makes no sense at all to me, so any insights welcome :slight_smile:

I initially thought that perhaps the other users had a ton more fonts than I, but I don’t think so…if I remember correctly, their font cache on the macbook pro ended up being smaller than mine on the mini.

···

On Mon, Nov 29, 2010 at 10:10 AM, Michael Droettboom <mdroe@…86…> wrote:

The fontManager is essentially a replacement for what fontconfig

provides on many platforms – so it’s intended that the fontManager

doesn’t exist if the user opts to use fontconfig. However, that’s still

an “experimental” option because it hasn’t been formally tested on many

platforms, and, as you point out, there may still be code paths that

aren’t coded correctly for that option.

Mike

On 11/25/2010 10:34 AM, Benjamin Root wrote:

On Wednesday, November 24, 2010, Daniel Hyams<dhyams@…287…> wrote:

MPL 1.0.0, OSX

If USE_FONTCONFIG is turned on, the function FontProperties.get_size_in_points will sometimes fail, because it is wanting to use “fontManager”, which is still ‘None’ if USE_FONTCONFIG is on. I’m not sure if it’s the proper way to fix it, but here is a small patch that works (meaning that at least the code doesn’t die; I can’t vouch for much else):

ORIGINAL:

 def get_size_in_points(self):        if self._size is not None:            try:                return float(self._size)
         except ValueError:                pass        default_size = fontManager.get_default_size()        return default_size * font_scalings.get(self._size)

NEW:

 def get_size_in_points(self):        if self._size is not None:            try:                return float(self._size)            except ValueError:
             pass        if fontManager:            default_size = fontManager.get_default_size()        else:           default_size = rcParams['font.size']
     return default_size * font_scalings.get(self._size)

Daniel Hyams

dhyams@…287…

I personally think that this is reasonable, as it guarantees a size

value to come from somewhere. However, I am concerned about

fontManager being None. If it isn’t a bug for it to be None at this

point, then I have to wonder where-else in the code needs a check for

None? If it is a bug, then what should it be when USE_FONTCONFIG is

true?

Good catch Daniel.

Ben Root


Increase Visibility of Your 3D Game App& Earn a Chance To Win $500!

Tap into the largest installed PC base& get more eyes on your game by

optimizing for Intel(R) Graphics Technology. Get started today with the

Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.

http://p.sf.net/sfu/intelisp-dev2dev


Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!

Tap into the largest installed PC base & get more eyes on your game by

optimizing for Intel(R) Graphics Technology. Get started today with the

Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.

http://p.sf.net/sfu/intelisp-dev2dev


Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Daniel Hyams
dhyams@…287…

  Just out of curiosity, is anyone using the fontconfig

way of mapping fonts? I turned it on one day, but the immediate
problem was that no mathtext worked any more; so I turned it back
off. Any mathtext in titles, labels, etc. just rendered as a much
of seemingly random letters.
That’s one of the drawbacks of the fontconfig mode – probably the
main reason it isn’t turned on by default. fontconfig only looks in
system-standard locations for fonts (by default), and matplotlib
installs its special math fonts in a different place. fontconfig
provides a C-level API to add another search directory, but it would
have to be wrapped for Python.

    And I'll tack a second question in here as well; the reason

that I was playing with fontconfig is that the font cache takes
a really long time to build in certain circumstances (I’m having
trouble identifying exactly when)…so I guess the question
is…has anyone else seen this? For example, on my (2008
vintage) mac mini, a complete rebuild of the font cache takes
around 3 seconds, which is fine. On a macbook pro (tested on
three different machines so far), it takes 30 seconds. This
makes no sense at all to me, so any insights welcome :slight_smile:

It's dependent on a) how many fonts you have installed and b) the

performance of the file system they are on. On my Linux machine
with a number of network shares involved, it can take a very long
time.

        I initially thought that perhaps the other users had a

ton more fonts than I, but I don’t think so…if I remember
correctly, their font cache on the macbook pro ended up
being smaller than mine on the mini.

It’s hard to say what might be causing this.

However, why are you concerned about it, since the cache only has to

be built once? (After all, that is the point of an on-disk font
cache in the first place…)

Mike
···

http://p.sf.net/sfu/intelisp-dev2dev


Matplotlib-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-users