I've committed a new font manager to CVS. It is based on the W3C Cascading Style Sheet, Level 1 (CSS1) design. It is still rather basic, but does seem to work for most of the backends. Therefore, FontTools, ttfquery, and ttf_font_manager are no longer needed by matplotlib. The font manager currently handle only TrueType fonts, but should be generalizable to other font types. The text object now has a fontproperties attribute which describes the basic aspects of the font, such as family, style, weight and size. This attribute replaces the fontname, fontangle, fontweight, and fontsize attributes. In future, I would suggest using font name sizes, such as small, medium, and large, to specify font sizes, instead of point sizes. This should make it easier for font sizes to be consistent across backends. It will also make it easier to change all the fonts just by changing the default font size that is associated with the medium font name. The default value for this is 12. The other interface issue to be aware of is the font family. This is a list of font names in order of decreasing priority. This should make it easier to match similar fonts across the various platforms. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: First of all, amazing work. It's very impressive that you made so many changes from the frontend to the backend to the config file and everything still works! Paul> I've committed a new font manager to CVS. It is based on Paul> the W3C Cascading Style Sheet, Level 1 (CSS1) design. It is Paul> still rather basic, but does seem to work for most of the Paul> backends. Therefore, FontTools, ttfquery, and Paul> ttf_font_manager are no longer needed by matplotlib. Excellent to hear - that was a maintenance nightmare. I'll put in an admin request to finally get those dir trees purged from CVS. BTW, I added the agg2 tree to CVS so you should be able to build matplotlib cleanly with a CVS checkout. No need to copy files and dirs anymore. I also remove gtkgd, which was never more than a proof-of-concept backend. Paul> The font manager currently handle only TrueType fonts, but Paul> should be generalizable to other font types. Paul> The text object now has a fontproperties attribute which Paul> describes the basic aspects of the font, such as family, Paul> style, weight and size. This attribute replaces the Paul> fontname, fontangle, fontweight, and fontsize attributes. Paul> In future, I would suggest using font name sizes, such as Paul> small, medium, and large, to specify font sizes, instead of Paul> point sizes. This should make it easier for font sizes to Paul> be consistent across backends. It will also make it easier Paul> to change all the fonts just by changing the default font Paul> size that is associated with the medium font name. The Paul> default value for this is 12. Paul> The other interface issue to be aware of is the font family. Paul> This is a list of font names in order of decreasing Paul> priority. This should make it easier to match similar fonts Paul> across the various platforms. I printed out the code so I'll take it home and give it a close reading tonight. Here are a few things I noticed while poking around * we should cite the ttfquery license since some of font_manager code appears to be borrowed from it. I added license/LICENSE_TTFQUERY to CVS so you can just refer to that file in the font_manager header * the default file .matplotlibrc in the matplotlib root dir needs to be updated with the properties you added to rcParams. With comments and commented examples would be most useful. I noticed that in the rc params in matplotlib.__init__.py you specify default sizes in points rather than relative sizes - what's the logic here? * Could you write some tutorial and/or user documentation? The two most important files are htdocs/fonts.html.template and htdocs/backends.html.template. Also, a blurb for "what's new" for the next release would be great. It might also be nice to have something along the lines of a FAQ "Hey my fonts have changed, how can I get the old ones back?" in htdocs/faqs.html.template * It does not appear you are cacheing the results anywhere. On my modern linux system with not so many fonts, I don't notice any performance hit. I wonder if this might be a problem for a win32 user with lots of ttf files and a not so speedy computer. * I have some concern about the finder algorithm, at least in combination with setting a default font in matplotlibrc. Eg, if I untar the following dir on my linux system (which contains a lot of ttf fonts) http://nitace.bsd.uchicago.edu:8080/files/share/ttf.tar and then point to them with my TTFPATH, and set text.fontname : Vera in matplotlibrc, I don't get Vera. This may be answered by the FAQ above :-) Many thanks! John Hunter
John Hunter wrote: > > I printed out the code so I'll take it home and give it a close > reading tonight. Here are a few things I noticed while poking around > > * we should cite the ttfquery license since some of font_manager code > appears to be borrowed from it. I added license/LICENSE_TTFQUERY > to CVS so you can just refer to that file in the font_manager > header I had thought about this and will add it to my to-do list. > * the default file .matplotlibrc in the matplotlib root dir needs to > be updated with the properties you added to rcParams. With > comments and commented examples would be most useful. I noticed > that in the rc params in matplotlib.__init__.py you specify default > sizes in points rather than relative sizes - what's the logic here? In my previous message, the active word is 'basic'. I just wanted to get some code in that worked, so you could evaluate and comment on it. Also, I thought it best to make a minimal set of changes initially, since this module affects so many other modules. A large set of changes might have caused lots of problems. In future, I should be able to make more modifications to one or two files at a time. I haven't had a chance to go through all the code yet to make sure it is all consistent. So the short answer is: I left it as is, because it worked. :) This is on my list of things to-do. > * Could you write some tutorial and/or user documentation? The two > most important files are htdocs/fonts.html.template and > htdocs/backends.html.template. Also, a blurb for "what's new" for > the next release would be great. It might also be nice to have > something along the lines of a FAQ "Hey my fonts have changed, how > can I get the old ones back?" in htdocs/faqs.html.template Yes, the user docs are also on my to-do list, but I'll also add the tutorial and FAQ documentation. > * It does not appear you are cacheing the results anywhere. On my > modern linux system with not so many fonts, I don't notice any > performance hit. I wonder if this might be a problem for a win32 > user with lots of ttf files and a not so speedy computer. The issue of cacheing the most recently used fonts had crossed my mind. I'll look into it, particularly for Windows systems. > * I have some concern about the finder algorithm, at least in > combination with setting a default font in matplotlibrc. Eg, if I > untar the following dir on my linux system (which contains a lot of > ttf fonts) http://nitace.bsd.uchicago.edu:8080/files/share/ttf.tar > and then point to them with my TTFPATH, and set > text.fontname : Vera in matplotlibrc, I don't get Vera. > This may be answered by the FAQ above :-) I'll make sure to describe this issue in the documentation. However, in reply to your comment, it is my opinion that the fontname attribute should be depricated in favor of fontfamily, which is a list of named fonts. The font manager has a preliminary list of recommended font families that the user can use. Vera is one of the named fonts in the 'sans' family, though not high on the list, since there are potentlially nicer fonts that can be used. The font manager prepends the list of fonts indicated by TTFPATH to the list of system fonts that it finds. So if Vera is in TTFPATH, then it should be available. If not, then I'll look into it. Please let me know what changes you would like to this module. In the mean time, I'll continue to make modifications. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> I'll make sure to describe this issue in the documentation. Paul> However, in reply to your comment, it is my opinion that the Paul> fontname attribute should be depricated in favor of Paul> fontfamily, which is a list of named fonts. The font Paul> manager has a preliminary list of recommended font families Paul> that the user can use. Vera is one of the named fonts in Paul> the 'sans' family, though not high on the list, since there Paul> are potentlially nicer fonts that can be used. Paul> The font manager prepends the list of fonts indicated by Paul> TTFPATH to the list of system fonts that it finds. So if Paul> Vera is in TTFPATH, then it should be available. If not, Paul> then I'll look into it. Vera is in the path since it's in my matplotlib data dir. Paul> Please let me know what changes you would like to this Paul> module. In the mean time, I'll continue to make Paul> modifications. I did a little more experimenting; I think some of the problems I was having yesterday were from residual effects of text.fontname. To clarify and simplify, I removed text.fontname from matplotlibrc and matplotlib.__init__ rcParams. The ttf_microsoft fonts referred to below are in the ttf.tar file referred to earlier; the results below show my matplotlibrc entry and the filename returned by findfont # ok, verdana san serif font.family : san-serif /home/jdhunter/src/ttf_microsoft/verdana.ttf # ok this is a serif font font.family : serif /usr/X11R6/lib/X11/fonts/TTF/luxirr.ttf # what's happening here? fail silently? cour.ttf is in ttf_microsoft font.family : Courier /home/jdhunter/src/ttf_microsoft/verdana.ttf I think the ability to define a family and let the system choose the best match is good, but there are cases where this may not be desirable. * If you are an application developer and want your app to look just the same across platforms, you may distribute it with a font file and you want to make sure that file is chosen. * The majority of users will probably be more familiar with the names Courier and Times than with font families monospace and serif. Should we provide a mechanism so that users can specify fonts this way? Eg, you may know you have Courier on your system and you don't care about portability. Is there a way in the current setup, for example, a user who wants to specify Courier? For the first of these two cases, one idea is to allow a user to specify a filename font.family = Vera.ttf # search path for Vera.ttf Users who distribute apps with matplotlib and want a guaranteed font (such as myself!) can use one of the fonts that are distributed with matplotlib and rely on the normal environment vars (MATPLOTLIBDATA and TTFPATH) to provide the dirs those fonts will reside in. Since no legitimate family name or font name will match the pattern *.ttf, we can safely do this. What do you think? If this is not sufficiently elegant, we could consider font.file as an additional attribute which defaults to None. For the second of the two cases, I'm not sure.... So fontname plays no legitimate role anymore? On an unrelated note, I don't think we need any of fontname, fontstyle, fontangle, fontvariant or fontweight in the Text __init__ method, but we should preserve the getters and setters as discussed earlier for user interface compatibity (the __init__ function is not in the user interface but the text methods are). JDH
John Hunter wrote: > > I did a little more experimenting; I think some of the problems I was > having yesterday were from residual effects of text.fontname. To > clarify and simplify, I removed text.fontname from matplotlibrc and > matplotlib.__init__ rcParams. The ttf_microsoft fonts referred to > below are in the ttf.tar file referred to earlier; the results below > show my matplotlibrc entry and the filename returned by findfont > > # ok, verdana san serif > font.family : san-serif /home/jdhunter/src/ttf_microsoft/verdana.ttf > > # ok this is a serif font > font.family : serif /usr/X11R6/lib/X11/fonts/TTF/luxirr.ttf > > # what's happening here? fail silently? cour.ttf is in ttf_microsoft > font.family : Courier /home/jdhunter/src/ttf_microsoft/verdana.ttf Yes, the current behaviour is to fail silently. Let me know if you want this changed. You are correct that Courier is one of the available fonts. However, the actual font name (from the font file) is 'Courier New'. The list of fonts that I have suggested for font family has both names listed, 'Courier New' and 'Courier', for this reason. From my reading of the CSS1 document there is no easy way to distinguish between different font families, except by an explicit list of font names. > I think the ability to define a family and let the system choose the > best match is good, but there are cases where this may not be > desirable. > > * If you are an application developer and want your app to look just > the same across platforms, you may distribute it with a font file > and you want to make sure that file is chosen. In this case the user or developer should provide his own font family list, e.g. ['Vera', 'sans-serif']. If Vera is always supplied with the application, then it will be found first, before the default 'sans-serif'. However, in the case where, for some reason, it could not be found, the default font will be used. > * The majority of users will probably be more familiar with the names > Courier and Times than with font families monospace and serif. > Should we provide a mechanism so that users can specify fonts this > way? Eg, you may know you have Courier on your system and you > don't care about portability. Is there a way in the current setup, > for example, a user who wants to specify Courier? Courier and Times are listed in the sans-serif font family. However, they are currently not very high on the list though. I suppose there are two ways to handle this. One is to expose the font families that comes with matplotlib. The user can then just say use the 'sans-serif' font family for my text. The second way is to use set_fontname() to prepend the specified font to the font family, so that it is always found first during the search. > For the first of these two cases, one idea is to allow a user to > specify a filename > > font.family = Vera.ttf # search path for Vera.ttf > > Users who distribute apps with matplotlib and want a guaranteed font > (such as myself!) can use one of the fonts that are distributed with > matplotlib and rely on the normal environment vars (MATPLOTLIBDATA and > TTFPATH) to provide the dirs those fonts will reside in. Since no > legitimate family name or font name will match the pattern *.ttf, we > can safely do this. What do you think? If this is not sufficiently > elegant, we could consider font.file as an additional attribute which > defaults to None. As previously noted all files found in TTFPATH are prepended to the list of system fonts, so they should be accessible. I think that the issue is the use of a personal version of the font family that specifies your prefered fonts, so that they are searched first. I would think that the font.family variable in matplotlibrc could be used to override those supplied by the application at start-up. Interactively, font family can be changed by supplying a list of font names to FontProperties.set_fontfamily(). The font family list that I have supplied is only a suggestion, so you may want to change it at this point. > For the second of the two cases, I'm not sure.... > > So fontname plays no legitimate role anymore? Not currently, but it can, as I suggest above. > On an unrelated note, I don't think we need any of fontname, > fontstyle, fontangle, fontvariant or fontweight in the Text __init__ > method, but we should preserve the getters and setters as discussed > earlier for user interface compatibity (the __init__ function is not > in the user interface but the text methods are). Good, I change that. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> Yes, the current behaviour is to fail silently. Let me know Paul> if you want this changed. Let's just put a debug flag in the file so that when we get a user question about "why isn't my font being found?" on matplotlib-users, we can advise them to set that flag. At a couple of critical points (eg the return value of findfont and any failure point), we can print if debug. Paul> In this case the user or developer should provide his own Paul> font family list, e.g. ['Vera', 'sans-serif']. If Vera is Paul> always supplied with the application, then it will be found Paul> first, before the default 'sans-serif'. However, in the Paul> case where, for some reason, it could not be found, the Paul> default font will be used. I think you are finally getting through my skull :-). How about this: What if all the family lists from font_manager are moved to matplotlib.__init__.defaultParams and hence .matplotlibrc font.family : sans-serif font.style : normal font.variant : normal font.weight : normal font.size : small font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, Arial, Helvetica, Bitstream Vera Sans, sans-serif font.monospace : Andale Mono, Bitstream Vera Sans Mono, Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace and so on (we'll need a new converter func in matplotlib.__init__: comma_sep_strs) Users can then order them as they see fit. We *require* that font.family be one of serif, sans_serif, cursive, fantasy, or monospace. (Is this overly restrictive?) Thus users who want courier move courier up higher in font.monospace in their rc file; ditto for vera. Does this work? I think I was a little slow to catch on because you intended font family lists to be user configurable but the configuration interface doesn't exist yet - it's essentially hardcoded in font_manager (is this right, or am I still confused?) As for deprecation, we can build a reverse dictionary mapping names to one of the allowed font families. On calls to text.set_fontname, we issue a deprecation warning and then set the appropriate font family where possible. In due time, we remove fontname. Am I starting to get on the right track here? JDH
John Hunter writes: > What if all the family lists from font_manager are moved to > matplotlib.__init__.defaultParams and hence .matplotlibrc > > > font.family : sans-serif > font.style : normal > font.variant : normal > font.weight : normal > font.size : small > font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, > Arial, Helvetica, Bitstream Vera Sans, sans-serif > font.monospace : Andale Mono, Bitstream Vera Sans Mono, > Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace > and so on > > (we'll need a new converter func in matplotlib.__init__: comma_sep_strs) > > Users can then order them as they see fit. > > We *require* that font.family be one of serif, sans_serif, cursive, > fantasy, or monospace. (Is this overly restrictive?) > > Thus users who want courier move courier up higher in font.monospace > in their rc file; ditto for vera. > My 2 cents: I like requiring the choices to be restricted to those you've mentioned (or some differently named equivalent), but I don't know if I would force changing the configuration file as being the only way to change the search order. I like the restriction since it enforces a normally very portable approach that will prevent the user from being burned on platform dependencies. On the other hand, it would be nice to give them some means in their code of bypassing that. How about providing a different interface (perhaps a bit awkward to use to discourage its casual use) to allow selection of fonts by specific name. But the normal means of selecting fonts would only accept the standard supported family names. Is there any problem in taking this approach? The more specific approach should be something that is very clear that is not portable (grepping on a file for any such instances of the keyword or method, depending on how it is implemented, will show if any such nonportable uses exist. There may be times that someone wants to use a special font for a very specific location on the plot and they don't care if isn't available everywhere (at least, not for the deadline they need to get this plot ready for--they are willing to suffer later for their sin). But maybe I misunderstand the issue. Perry
John Hunter wrote: > > How about this: > > What if all the family lists from font_manager are moved to > matplotlib.__init__.defaultParams and hence .matplotlibrc > > > font.family : sans-serif > font.style : normal > font.variant : normal > font.weight : normal > font.size : small > font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, Arial, Helvetica, Bitstream Vera Sans, sans-serif > font.monospace : Andale Mono, Bitstream Vera Sans Mono, Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace > and so on > > (we'll need a new converter func in matplotlib.__init__: comma_sep_strs) > > Users can then order them as they see fit. > > We *require* that font.family be one of serif, sans_serif, cursive, > fantasy, or monospace. (Is this overly restrictive?) Seems reasonable to me. > Thus users who want courier move courier up higher in font.monospace > in their rc file; ditto for vera. > > Does this work? I think I was a little slow to catch on because you > intended font family lists to be user configurable but the > configuration interface doesn't exist yet - it's essentially hardcoded > in font_manager (is this right, or am I still confused?) Yes, that's correct. You can modify the family lists via text.set_font_properties(), but that's probably not very easy for a user to do at this point. > As for deprecation, we can build a reverse dictionary mapping names to > one of the allowed font families. On calls to text.set_fontname, we > issue a deprecation warning and then set the appropriate font family > where possible. In due time, we remove fontname. I was thinking that we might want to use set_fontname() to find the font family and also add the specified font to the beginning of the list, so that it will all certainly be used. Otherwise, that font may be near the bottom of the list and not actually get used. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> I was thinking that we might want to use set_fontname() to Paul> find the font family and also add the specified font to the Paul> beginning of the list, so that it will all certainly be Paul> used. Otherwise, that font may be near the bottom of the Paul> list and not actually get used. Just to summarize then to make sure we're all on the same page * family lists will be moved to matplotlibrc and so will be user configurable. This list can be overriden on a per-script basis using the method in http://matplotlib.sourceforge.net/faq.html#CUSTOM * text.fontname and the other text.font* attributes in the config file and in matplotlib.__init__ are deprecated and should warn. The warning should point to the appropriate web page for instruction. You should use family lists rather than fontnames for general/global preferences. However, Text.set_fontname is preserved and moves the named font to the head of the list appropriate list using some kind of dictionary that maps names to families. This should satisfy Perry's concern about specifying a specific font for use in a specific place. If the font is in your system path and the finder algorithm is working properly this font will be used. There is one significant caveat to this, which is that it may be difficult or impossible to specify a complete dictionary from names to families. Or, are you reasonably certain you can build this on the fly Paul using font properties from FT2Font? * font.family must be one of sans-serif, serif, monospace, cursive or fantasy. Anything else should raise * Paul, I think when you do the documentation, some discussion of what the different families look like, what the classic examples of each are Eg "Courier is an example of Monospace", and a text screenshot along the lines of examples/alignment_test.py showing an example from each of the families would be very helpful to users. All of this could go into htdocs/fonts.html.template and/or tutorial.html.template. Remaining question: * Should we add a fontfile attribute to FontProperties which defaults to None but if not None but can be a string like 'somefile.ttf'. FontManager.findfont would do something like if prop.fontfile is not None: for path in fontPaths: fullpath = os.path.join(path, prop.fontfile): if os.path.exists(fullpath): return fullpath raise something # somefile.ttf is not on system This would be for users who absolutely positively want a font from some ttf file and don't want to mess with the rest. If we really trust the mechanisms in set_fontname, the finder algorithm and the name->family dictionary, this shouldn't be necessary. But we may not fully trust all of these mechanisms and it might be nice for people who don't want to mess with understanding fonts, families, and the rest. Anything else? JDH
John Hunter writes: > Just to summarize then to make sure we're all on the same page > > * family lists will be moved to matplotlibrc and so will be user > configurable. This list can be overriden on a per-script basis > using the method in > http://matplotlib.sourceforge.net/faq.html#CUSTOM > > * text.fontname and the other text.font* attributes in the config > file and in matplotlib.__init__ are deprecated and should warn. > The warning should point to the appropriate web page for > instruction. You should use family lists rather than fontnames for > general/global preferences. However, Text.set_fontname is > preserved and moves the named font to the head of the list > appropriate list using some kind of dictionary that maps names to > families. > > This should satisfy Perry's concern about specifying a specific > font for use in a specific place. If the font is in your system > path and the finder algorithm is working properly this font will be > used. There is one significant caveat to this, which is that it > may be difficult or impossible to specify a complete dictionary > from names to families. Or, are you reasonably certain you can > build this on the fly Paul using font properties from FT2Font? > > * font.family must be one of sans-serif, serif, monospace, cursive or > fantasy. Anything else should raise > > * Paul, I think when you do the documentation, some discussion of > what the different families look like, what the classic examples of > each are Eg "Courier is an example of Monospace", and a text > screenshot along the lines of examples/alignment_test.py showing an > example from each of the families would be very helpful to users. > All of this could go into htdocs/fonts.html.template and/or > tutorial.html.template. > All the above sounds good to me. Perry