matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> Ahhh - Thanks! I was wondering if both axes would scale when
 Ted> doing a zooming operation but I hadn't had time to try it
 Ted> out. Thanks for the example, that's exactly what I was
 Ted> looking for.
 >> On the contrary, you should use twinx for that, as follows:
Baptiste, this is an exceedingly clever solution which wouldn't have
occurred to me, but I suspect it is a clever hack designed to work
around a design flaw. One shouldn't have to be so clever to do
something so simply stated as Ted's original request. Would it not be
better to support (optionally) a different tick labeler and formatter
for bottom/top and left/right?
But this too is the wrong question....
In truth, what we want is to be able to have an arbitrary number of
Axis lines, each with their own tick locator and formatter, which can
be placed at an arbitrary location (arbitrary for an x-axis means a
horizontal line at an arbitrary y-location which spans the x data
range). In this view, the current y=0 for bottom and y=1 for top are
just two special cases for the x-axis; in general we want to be able
to place these suckers anywhere and to control their tick locating and
formatting independently.
This raises the question of how we should specify the location of the
axis line. For concreteness, let's just consider the x axis line and
how we should specify its y location. In the current implementation,
there are only two possible y locations, at 0 and 1 for bottom and
top. Most of the time, this is just what you want, eg, you want the
axis line to remain fixed at the bottom when changing the y pan or
zoom. But it seems that sometimes you also want the y location of the
x axis to be placed in data coords, and sometimes you want it in
places other than the top and bottom. 
Several use cases point to the need to make the axis line (and it's
associated ticks and labels) independent objects that can be
customized. In particular, I have seen Eric Jones demonstrate in
Chaco several times the ability to have multiple y axis objects --
apparently this is something frequently needed in the petroleum
industry. Also, Andrew Straw has posted examples in which he wants to
decouple the axis line from the rectangular box defining the data
clipping box.
When this issue came up previously, I've noted that this is a good use
for traits. But lazy values, properly utilized, could serve as well.
The basic problem to be solved is that we need to have a mechanism so
that when an axis line is moved, eg by a set call at the user level,
the associated ticks and labels move with it. Whether this is done
with traits observer/delegation or shared lazy values is not too
important. 
But a refactoring of axis, tick and labeling is long overdue...
JDH

John Hunter wrote:
>In honor of Darren trying to get his thesis printed using mpl figures,
>and encountering a lot of pain with fonts and mathtext, I added a
>psfrag latex backend today.
>
John, this is incredible. For those of you who haven't tried the demo 
from CVS yet, it looks to naive me like John's achieved the Holy Grail 
of putting arbitrary TeX into labels in matplotlib. MATLAB doesn't do 
this, probably never will. Wow.
OK, enough groveling.

Ahhh - Thanks! I was wondering if both axes would scale when doing a=20
zooming operation but I hadn't had time to try it out. Thanks for the=20
example, that's exactly what I was looking for.
Ted
ps: I too am on the list.
At 03:12 PM 5/20/2005, Baptiste Carvello wrote:
>Ted Drain a =E9crit :
>>I was playing with twinx() a little tonight from the pylab.py file and=20
>>have a small suggestion. I think twinx() should call (before creating=20
>>the new axes):
>>gca().yaxis.tick_left()
>>Currently, after calling twinx(), then new axis tick marks correctly=20
>>appear on the right side of the plot. However, the major tick marks from=
=20
>>the left hand side Y axis also appear on the right side of the plot which=
=20
>>is a little confusing.
>indeed, this should be fixed.
>
>>Also, since we have twinx(), it would be nice to have twiny():
>>def twiny(ax=3DNone):
>> """
>> Make a second axes overlay ax (or the current axes if ax is None)
>> sharing the yaxis. The ticks for ax2 will be placed on the top,
>> and the ax2 instance is returned. See examples/two_scales.py
>> """
>> if ax is None:
>> ax=3Dgca()
>> ax.xaxis.tick_bottom()
>>
>> ax2 =3D gcf().add_axes(ax.get_position(), sharey=3Dax, frameon=3DFals=
e)
>> ax2.xaxis.tick_top()
>> ax2.xaxis.set_label_position('top')
>> draw_if_interactive()
>> return ax2
>We could do that. The only reason we didn't yet is because nobody thought=
=20
>of a clear use case. If you have one, it can be done. However, see below.
>
>>The case I'm thinking of where twiny() would would be useful is one that=
=20
>>we hit a lot at work. Time is represented on the X axis and we want=20
>>multiple label types. So we'd like to have the bottom axis be time in=20
>>UTC and the upper axis to be PST or some other local time frame. I'm not=
=20
>>sure whether or not it would be best to replot the data using twiny() or=
=20
>>to try and set up a custom formatter on the second X scale since in my=20
>>scenario there aren't two sets of data.
>I wouldn't do that. The 2 x axes won't stay in sync if you do a zoom or a=
=20
>rescale. What twiny is for would be if you need a different scale.
>
>On the contrary, you should use twinx for that, as follows:
>
> >>> from pylab import *
> >>> from pytz import timezone
> >>> from datetime import datetime
> >>> from matplotlib.dates import DateFormatter, HourLocator, DayLocator,=
=20
> date2num
> >>> from matplotlib.axis import Ticker
>
> >>> tz=3Dtimezone('US/Pacific')
> >>> utc=3Dtimezone('UTC')
> >>> start=3Ddate2num(datetime( 2005, 05, 20, 21, 12 ,tzinfo=3Dtz))
> >>> T=3Darange(0,1.5,0.01)
> >>> V=3Drand(len(T))
>
> >>> plot(start+T,V)
> >>> ax=3Dgca()
> >>> ax2=3Dtwinx()
> >>> gcf().sca(ax)
>
> >>> ax2.yaxis.set_visible(False)
>
> >>> ax.xaxis.set_major_locator(DayLocator(tz=3Dtz))
> >>> ax.xaxis.set_major_formatter(DateFormatter('%d %b',tz=3Dtz))
> >>> ax.xaxis.set_minor_locator(HourLocator(range(0,25,6), tz=3Dtz))
> >>> ax.xaxis.set_minor_formatter(DateFormatter('%H:%M',tz=3Dtz))
> >>> ax.xaxis.tick_bottom()
> >>> ax.set_xlabel('US/Pacific')
>
>
> >>> ax2.xaxis.major=3DTicker()
> >>> ax2.xaxis.minor=3DTicker()
> >>> ax2.xaxis.set_major_locator(DayLocator(tz=3Dutc))
> >>> ax2.xaxis.set_major_formatter(DateFormatter('%d %b',tz=3Dutc))
> >>> ax2.xaxis.set_minor_locator(HourLocator(range(0,25,6), tz=3Dutc))
> >>> ax2.xaxis.set_minor_formatter(DateFormatter('%H:%M',tz=3Dutc))
> >>> ax2.xaxis.tick_top()
> >>> ax2.set_xlabel('UTC')
> >>> ax2.xaxis.set_label_position('top')
>
> >>> draw_if_interactive()
> >>> show()
>
>note that if you do not track cvs, the minor tick labels on the top axis=20
>will not print, due to a known bug, fixed in cvs.
>
>Cheers,
>Baptiste
>
>PS: don't CC me in replies, I'm subscribed to the list. If you also are,=20
>please say so.

I was playing with twinx() a little tonight from the pylab.py file and have 
a small suggestion. I think twinx() should call (before creating the new 
axes):
gca().yaxis.tick_left()
Currently, after calling twinx(), then new axis tick marks correctly appear 
on the right side of the plot. However, the major tick marks from the left 
hand side Y axis also appear on the right side of the plot which is a 
little confusing.
Also, since we have twinx(), it would be nice to have twiny():
def twiny(ax=None):
 """
 Make a second axes overlay ax (or the current axes if ax is None)
 sharing the yaxis. The ticks for ax2 will be placed on the top,
 and the ax2 instance is returned. See examples/two_scales.py
 """
 if ax is None:
 ax=gca()
 ax.xaxis.tick_bottom()
	
 ax2 = gcf().add_axes(ax.get_position(), sharey=ax, frameon=False)
 ax2.xaxis.tick_top()
 ax2.xaxis.set_label_position('top')
 draw_if_interactive()
 return ax2
The case I'm thinking of where twiny() would would be useful is one that we 
hit a lot at work. Time is represented on the X axis and we want multiple 
label types. So we'd like to have the bottom axis be time in UTC and the 
upper axis to be PST or some other local time frame. I'm not sure whether 
or not it would be best to replot the data using twiny() or to try and set 
up a custom formatter on the second X scale since in my scenario there 
aren't two sets of data.
Ted

If you are using python for high performance or scientific computing,
could I ask you to send me a blurb (one or two sentences) on what you
are using it for and if you have any publications or references
related to this work (the refs don't have to be specifically about the
python stuff) please include them (extra points for bibtex).
I am writing some grant text justifying python in scientific computing
and would like to have a range of examples across disciplines to
provide. 
If I could get these today or tomorrow that would be very helpful!
Please send these to me off list.
Thanks!
JDH

John,
Sorry about that - you didn't miss any emails. I put it on my to-do list 
and then it got swamped w/ other work and I sort of forgot about it.
We've made a few bug fixes w/ regard to keyboard focus so I incorporated 
those into the Fernando's version of the backend. Attached is the file 
that contains Fernando's mod's for ipython and those bug fixes. Everything 
seems to be working fine w/ his changes.
Ted
At 09:40 PM 5/17/2005, you wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
> Ted> Sounds good. I'll take a look at it tomorrow (Thursday).
>
> Fernando> With these changes and the corresponding ones to ipython
> Fernando> (not in CVS yet, give me a day or two), it becomes
> Fernando> possible to use ipython to interactively drive Qt
> Fernando> applications, including matplotlib interactive plotting
> Fernando> with the QtAgg backend.
>
> >> Hey guys thanks for working on this -- Ted and colleagues at
> >> JPL, if you haven't used ipython for interactive plotting with
> >> mpl, it is very nice, and I definitely recommend giving it a
> >> try when Fernando gets his changes in CVS. Could you all look
> >> over this patch and make sure it doesn't conflict with anything
> >> your group is doing with the qt backend and if it looks good to
> >> you I'll merge it in.
> >>
> >> JDH
>
>Hi Ted,
>
>Any word on this patch? (did I mess an email?)
>
>JDH

On Tue, 2005年05月17日 at 10:55 -0500, John Hunter wrote:
> >>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:
> 
> Patrik> # Should show orange bars, but shows white, grey, and
> Patrik> black bars. from matplotlib.pylab import * figure() t =
> Patrik> [1,2,3] bar(t, t, color=(1.0, 0.5, 0.0)) show()
> Patrik> Is this surprising behavior really what you want?
> 
> This is a corner case. matplotlib is pretty friendly when you set
> colors. In particular, it allows you to use a float and it interprets
> it as grayscale or an rgb tuple. What you are bumping into is the
> unusual case when the length of your data is exactly three, and it is
> ambiguous whether you want three grayscale values, different for each
> bar, or a single rgb value for all three bars. It wouldn't happen
> with 10 bars because a 10 length tuple of grayscale floats is not
> ambiguous.
> 
> You can disambiguate by using hex strings or colorname strings
Yes, and that is what I had to do with the colors I got from a
colormap:
 color = rgb2hex(colormap(x)[:3])
However, what I really would have hoped for is a color class so that I
wouldn't have to worry about rgb versus rgba and the problem above. For
instance, colormap(x) would return a color instance that I can pass to
bar(), and bar() would also understand rgba automatically.
Something like:
import colors
class Color:
 def __init__(self, color):
 self.color = colors.colorConverter.to_rgba(color)
 def __getitem__(self, i):
 return self.color[i]
 def to_hex(self):
 return colors.rgb2hex(self.color[:3])
 def to_rgb(self):
 return self.color[:3]
 def to_rgba(self):
 return self.color
 etc.
-- 
Patrik

On Tuesday 17 May 2005 6:44 pm, John Hunter wrote:
> In honor of Darren trying to get his thesis printed using mpl figures,
> and encountering a lot of pain with fonts and mathtext, I added a
> psfrag latex backend today. psfrag is a latex package that enables
> you to substitute sentinel strings in an eps figure with latex
> expressions (eg as in xfig). You create an eps with a bunch of marker
> strings like "psmarker0" or "psmarker1" and then write a latex file
> that does the substitutions
>
> \psfrag{psmarker0}[bl][bl][2.000000][0.000000]{\TeX\ is Number
> $e^{-i\pi}$!} \psfrag{psmarker1}[bl][bl][1.000000][0.000000]{0}
>
> The LaTeX backend generates a *.eps file and a *.tex file. You can
> then latex and dvips the tex file to get a true ps, or just embed the
> generated latex commands directly into your document. This uses latex
> for all text elements, giving a unified font look and feel.
I don't know what to say, except, Thank you.
> Here is an example
>
> > python examples/tex_demo.py -dLaTeX
> > latex tex_demo.tex
> > dvips -o tex_demo.ps tex_demo.dvi
> > ggv tex_demo.ps
>
> There are a few problems
>
> * the page width and figure placement in the latex document are off
> center
>
> * the text color is not being respected
>
> * to get the width and height of the string, I tex the individual
> strings separately, run dvips on them, and get the bounding box
> from the generated file. This all happens with caching in
> matplotlib.texmanager. Right now the fontsize is being ignored in
> this process so the layout will be off for nonstandard font sizes
> -- anything other than the default design size of latex which
> defaults to 10pt I think.
>
> * the text doesn't scale right if you provide a size arg to
> includegraphics, eg [width=3D4.in]
>
> I'm sure these details can be worked out by someone who has the
> patience to read the psfrag manual closely and knows a bit about tex
> and dvips -- the backend is only 180 lines of code. I'm kind of busy
> right now with other work, so I was hoping some enterprising soul
> would like to take this and run with it, polish it, fix it and test
> it.... Darren? If not, I'll get to it as I can.
>
> Changes in CVS
I'll be on a bus 24 of the next 60 hours, to get to my brother's graduation=
=2E=20
I'll print out what is in cvs and the psfrag manual for the trip, and can't=
=20
wait to get my hands on the code when I get back.
Darren

In honor of Darren trying to get his thesis printed using mpl figures,
and encountering a lot of pain with fonts and mathtext, I added a
psfrag latex backend today. psfrag is a latex package that enables
you to substitute sentinel strings in an eps figure with latex
expressions (eg as in xfig). You create an eps with a bunch of marker
strings like "psmarker0" or "psmarker1" and then write a latex file
that does the substitutions
\psfrag{psmarker0}[bl][bl][2.000000][0.000000]{\TeX\ is Number $e^{-i\pi}$!}
\psfrag{psmarker1}[bl][bl][1.000000][0.000000]{0}
The LaTeX backend generates a *.eps file and a *.tex file. You can
then latex and dvips the tex file to get a true ps, or just embed the
generated latex commands directly into your document. This uses latex
for all text elements, giving a unified font look and feel.
Here is an example
 > python examples/tex_demo.py -dLaTeX
 > latex tex_demo.tex
 > dvips -o tex_demo.ps tex_demo.dvi
 > ggv tex_demo.ps
There are a few problems
 * the page width and figure placement in the latex document are off
 center
 * the text color is not being respected
 * to get the width and height of the string, I tex the individual
 strings separately, run dvips on them, and get the bounding box
 from the generated file. This all happens with caching in
 matplotlib.texmanager. Right now the fontsize is being ignored in
 this process so the layout will be off for nonstandard font sizes
 -- anything other than the default design size of latex which
 defaults to 10pt I think.
 * the text doesn't scale right if you provide a size arg to
 includegraphics, eg [width=4.in]
I'm sure these details can be worked out by someone who has the
patience to read the psfrag manual closely and knows a bit about tex
and dvips -- the backend is only 180 lines of code. I'm kind of busy
right now with other work, so I was hoping some enterprising soul
would like to take this and run with it, polish it, fix it and test
it.... Darren? If not, I'll get to it as I can.
Changes in CVS
JDH

>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:
 Patrik> # Should show orange bars, but shows white, grey, and
 Patrik> black bars. from matplotlib.pylab import * figure() t =
 Patrik> [1,2,3] bar(t, t, color=(1.0, 0.5, 0.0)) show()
 Patrik> The culprit is len(left)!=3 in bar() and barh():
 Patrik> if (is_string_like(color) or (iterable(color) and
 Patrik> len(color)==3 and len(left)!=3) or not iterable(color)):
 Patrik> color = [color]*len(left)
 Patrik> Is this surprising behavior really what you want?
This is a corner case. matplotlib is pretty friendly when you set
colors. In particular, it allows you to use a float and it interprets
it as grayscale or an rgb tuple. What you are bumping into is the
unusual case when the length of your data is exactly three, and it is
ambiguous whether you want three grayscale values, different for each
bar, or a single rgb value for all three bars. It wouldn't happen
with 10 bars because a 10 length tuple of grayscale floats is not
ambiguous.
You can disambiguate by using hex strings or colorname strings
 colors = 'white', 'gray', 'black'
 bar(t,t,color=colors)
Hope this helps,
JDH

The function set_ticklabels() breaks if given unicode labels. Calling
str() on a unicode string doesn't always work.
--- axis.py.orig	2005年03月28日 06:29:11.000000000 +0300
+++ axis.py	2005年05月17日 15:01:48.000000000 +0300
@@ -734,7 +734,13 @@
 instances.
 
 ACCEPTS: sequence of strings"""
- ticklabels = [str(l) for l in ticklabels]
+ tl = []
+ for l in ticklabels:
+ if isinstance(l, basestring):
+ tl.append(l)
+ else:
+ tl.append(str(l))
+ ticklables = tl
 
 self.set_major_formatter( FixedFormatter(ticklabels) )
-- 
Patrik

# Should show orange bars, but shows white, grey, and black bars.
from matplotlib.pylab import *
figure()
t = [1,2,3]
bar(t, t, color=(1.0, 0.5, 0.0))
show()
The culprit is len(left)!=3 in bar() and barh():
 if (is_string_like(color) or
 (iterable(color) and len(color)==3 and len(left)!=3) or
 not iterable(color)):
 color = [color]*len(left)
Is this surprising behavior really what you want?
-- 
Patrik

Hi Ken,
Thanks for the report. It seems sort of odd that this
doesn't show up on Windows or Mac, but it does seem like 
a fine idea to force the args of SetWidth, etc to be 
integers.
I'll change this in cvs. Thanks!!
--Matt
On 2005年5月16日, Ken McIvor wrote:
> While trying out the new printing support in matplotlib 0.80's WxAgg backend, 
> I encountered the following DeprecationWarning when calling 
> FigureCanvasWxAgg.Printer_Preview().
> 
> /usr/lib/python2.3/site-packages/wxPython/gdi.py:77: DeprecationWarning:
> integer argument expected, got float
> val = gdic.wxBitmap_SetWidth(self, *_args, **_kwargs)
> /usr/lib/python2.3/site-packages/wxPython/gdi.py:80: DeprecationWarning:
> integer argument expected, got float
> val = gdic.wxBitmap_SetHeight(self, *_args, **_kwargs)
> 
> A little digging located the problem in backend_wx.PrintoutWx.OnPrintPage() on 
> lines 1906 and 1907. Wrapping a call to int() around the arguments of 
> SetWidth() and SetHeight() there solves this problem.
> 
> I'm not sure that a two line change warrents a patch, but I'll happily submit 
> one if asked.
> 
> Ken
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

While trying out the new printing support in matplotlib 0.80's WxAgg backend, 
I encountered the following DeprecationWarning when calling 
FigureCanvasWxAgg.Printer_Preview().
 /usr/lib/python2.3/site-packages/wxPython/gdi.py:77: DeprecationWarning:
 integer argument expected, got float
 val = gdic.wxBitmap_SetWidth(self, *_args, **_kwargs)
 /usr/lib/python2.3/site-packages/wxPython/gdi.py:80: DeprecationWarning:
 integer argument expected, got float
 val = gdic.wxBitmap_SetHeight(self, *_args, **_kwargs)
A little digging located the problem in backend_wx.PrintoutWx.OnPrintPage() on 
lines 1906 and 1907. Wrapping a call to int() around the arguments of 
SetWidth() and SetHeight() there solves this problem.
I'm not sure that a two line change warrents a patch, but I'll happily submit 
one if asked.
Ken

On Sat, 2005年05月14日 at 15:42 -0500, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> - consistency with other applications - if you are using
> Steve> gtk+/GNOME, Qt/KDE, Mozilla or other applications that use
> Steve> fontconfig then using fontconfig from matplotlib means you
> Steve> are using the same font-matching library and have access to
> Steve> exactly the same font files as your other applications.
> 
> This looked to me to be a heavily UNIX oriented system. Eg, one thing
> the font_manager does is query the win32 registry for font location
> information. All of the examples I saw on the fontconfig page seemed
> to assume /etc and a unix like file system. I didn't look too deep,
> though.
> 
> Is this portable?
Fontconfig was developed to work with FreeType, Xft and Unix X-Windows.
However its an independent utility/library, does not require an X
server, and (like GTK+ and GIMP) has since been ported to other systems.
I found this page
http://www.gimp.org/~tml/gimp/win32/downloads.html
which lists fontconfig for Windows.
Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> - consistency with other applications - if you are using
 Steve> gtk+/GNOME, Qt/KDE, Mozilla or other applications that use
 Steve> fontconfig then using fontconfig from matplotlib means you
 Steve> are using the same font-matching library and have access to
 Steve> exactly the same font files as your other applications.
This looked to me to be a heavily UNIX oriented system. Eg, one thing
the font_manager does is query the win32 registry for font location
information. All of the examples I saw on the fontconfig page seemed
to assume /etc and a unix like file system. I didn't look too deep,
though.
Is this portable?
JDH

On Fri, 2005年05月13日 at 20:46 -0400, Paul Barrett wrote:
> I guess that I wasn't aware of it at the time. I believe (John may want 
> to correct me if I'm wrong) that there was also a desire to have it 
> coded in Python for reasons of simplicity and portability, since in 
> early 2004 MPL was not as mature as it is now and did not contain as 
> much C/C++ code. I see no reason not to use fontconfig if it provides 
> the same functionality as the current font_manager and the wrapper 
> software can be easily done.
> 
> What obvious benefits do you see to using fontconfig instead of 
> font_manager? 
- speed from being coded in C.
- speed from caching font info, and avoiding the need to traverse the
filesystem reading font filenames and directories.
- fontconfig is widely used, so its code has become well tested and
mature.
- integration with freetype
You could say that fontconfig is a utility designed to help you use
freetype, so if you require freetype (as mpl does) why not use
fontconfig too? Many systems that have freetype installed will already
have fontconfig installed as well. 
- consistency with other applications - if you are using gtk+/GNOME,
Qt/KDE, Mozilla or other applications that use fontconfig then using
fontconfig from matplotlib means you are using the same font-matching
library and have access to exactly the same font files as your other
applications.
> Does it provide access to individual font glyphs? This 
> feature would allow embedded fonts and mathtext to be included in the 
> SVG backend. I guessing that it almost certainly provides unicode 
> support. Anything else?
Fontconfig does the font-matching and font configuration, to access to
individual font glyphs I think you use freetype directly (after
fontconfig has selected the desired font).
"Font Configuration and Customization for Open Source Systems" written
in 2002 describes the origial design of fontconfig -
http://keithp.com/~keithp/talks/guadec2002/
This is the main fontconfig site http://www.fontconfig.org/wiki/
Steve

Steve Chaplin wrote:
>I took a look at font_manager.py today and can see that John and Paul have 
>done a good job but I wonder - is it a case of reinventing the wheel, or 
>perhaps parallel development?
>
>There is the fontconfig library (written in C) which has very similar 
>functionality. It works with FreeType, supports W3C CSS2, is used by 
>Mozilla, pango/gtk+, Qt and is available for Windows, and provides
>caching of font information.
>
>Was fontconfig considered when font_manager was written and a decision 
>made not to use it?
>
>fontconfig seems to have become the standard font config and font matching 
>method for many systems and applications, should matplotlib consider
>using it?
>(It would involve creating a Python binding for it, but that should be
>possible)
> 
>
I guess that I wasn't aware of it at the time. I believe (John may want 
to correct me if I'm wrong) that there was also a desire to have it 
coded in Python for reasons of simplicity and portability, since in 
early 2004 MPL was not as mature as it is now and did not contain as 
much C/C++ code. I see no reason not to use fontconfig if it provides 
the same functionality as the current font_manager and the wrapper 
software can be easily done.
What obvious benefits do you see to using fontconfig instead of 
font_manager? Does it provide access to individual font glyphs? This 
feature would allow embedded fonts and mathtext to be included in the 
SVG backend. I guessing that it almost certainly provides unicode 
support. Anything else?
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Hi, Florent! ;-)
Florent Rougon <f.r...@fr...> wrote:
[...]
> This causes minor tick labels not to be drawn when using tick_top(), as
> shown in the attached example (+ two lines patch).
This part of my mail still applies, AFAICT.
> Note: I stumbled accross this because I draw a few vlines on a plot to
> mark specific values and I wanted a label indicating what each
> vline means. I managed to add these labels with minor ticks using
> a FixedLocator and a FixedFormatter, but the minor tick labels
> where colliding with the major ones. Therefore, I tried to move
> them to the top.
For this one, however, I have found a better solution. FixedLocator and
FixedFormatter are easy to use, but:
 1. They replace one of your two major/minor ticks&ticklabels sets.
 2. They don't allow you (AFAIK) do draw the labels on the other side
 of the axis line (i.e., above the axis line when using
 tick_bottom(), below the axis line when using tick_top()), which
 caused ugly overlaps with major tick labels in my case.
The better solution simply consists in mimicking what is done in axis.py
to place tick labels. A small loop over the positions and label strings,
mixed with a transformation, and voilà! The labels are placed just as
they should, offset a bit to the left (to avoid clashing with the vline
they correspond to) and top from the position on the x axis, with the
offsets given in dpi, and therefore correct whatever resolution is
chosen to render the figure.
Special congrats for having included this dpi setting as lazy value in
the core design, despite the usual habit of working directly in pixels.
For the curious, here is the relevant part of code:
 pos = [ self.mean, self.d1, self.q1, self.median, self.q3, self.d9 ]
 labels = [ u"mo", u"d1", u"q1", u"md", u"q3", u"d9" ]
 colors = [ 'r', '#6b8e23', '#cc5522', 'b', 'c', 'm']
 # We are going to draw a vertical line at each position with a label
 # nearby.
 #
 # Bad method for the label placement: using minor ticks. The biggest
 # problem is that it doesn't allow drawing the labels above the x axis
 # line; consequently, they often collide with the major tick labels,
 # which looks quite ugly:
 #
 # self.axes.xaxis.set_minor_locator(FixedLocator(pos))
 # self.axes.xaxis.set_minor_formatter(FixedFormatter(labels))
 #
 # Good method: place the labels by hand, just the way it is done in
 # matplotlib/axis.py for tick labels. For this, we use a transform
 # that will be passed to self.axes.text() and will translate each
 # label by the following offset, in PostScript points (1/72 inch):
 xoffset, yoffset = -3., 2.
 # The same offset in pixels, based on the figure's dpi value
 xo_pixels = Value(xoffset)*self.axes.figure.dpi*Value(1/72.)
 yo_pixels = Value(yoffset)*self.axes.figure.dpi*Value(1/72.)
 # We are going to transform x data coordinates and y Axes coordinates
 # into backend coordinates (pixels).
 trans = blend_xy_sep_transform(self.axes.transData,
 self.axes.transAxes)
 # The label text will be offset with a post-transformation
 transOffset = translation_transform(xo_pixels, yo_pixels)
 trans.set_offset((0,0), transOffset)
 for i in xrange(len(pos)):
 # Draw the line
 self.axes.axvline(x=pos[i], ymin=0., ymax=1., color=colors[i])
 # Place the corresponding label; x is in data coordinates and y in
 # Axes coordinates.
 self.axes.text(x=pos[i], y=0., s=labels[i],
 fontsize=rcParams["tick.labelsize"],
 verticalalignment='bottom',
 horizontalalignment='right', transform=trans)
-- 
Florent

I took a look at font_manager.py today and can see that John and Paul have 
done a good job but I wonder - is it a case of reinventing the wheel, or 
perhaps parallel development?
There is the fontconfig library (written in C) which has very similar 
functionality. It works with FreeType, supports W3C CSS2, is used by 
Mozilla, pango/gtk+, Qt and is available for Windows, and provides
caching of font information.
Was fontconfig considered when font_manager was written and a decision 
made not to use it?
fontconfig seems to have become the standard font config and font matching 
method for many systems and applications, should matplotlib consider
using it?
(It would involve creating a Python binding for it, but that should be
possible)
Steve

>Thanks for the references. I decided to go for the second approach (it 
>seems maybe more sane, and it doesn't seem like their are any major 
>benefits to using the glyphs made..) The SVG code outputs a tuple of:
>basename, fontsize, unicode, ox, oy, metrics
>
>I go through the list, and output that. I'm not sure if I'm doing 
>everything correctly. For example, I have no clue what 'metrics' 
>contains (e.g. what advance, width, etc. will do, and if I need it or 
>not). I'm also not sure if things like hinting work using this method 
>either (esp. since I render each character seperately -- I'm not sure
I 
>see any other method of doing it, however).
>
>Any of this look sane?
>
>ctx = cairo.Context()
>file = open('test.ps', 'wb')
>ctx.set_target_ps(file, 4.3, 4.3, 300, 300)
>
>width, height, fonts = math_parse_s_ft2font_svg(r'$x^y * \pi$', 96, 50)
>
>for f in fonts:
> basename, fontsize, num, ox, oy, metrics = f
> ctx.select_font(basename)
> ctx.scale_font(fontsize)
> ctx.move_to(ox, 100 - oy)
> ctx.show_text(unichr(num).encode('utf8'))
>
>ctx.stroke()
>
>ctx.show_page()
Looks OK as far as I can tell, did you run it and check the image?
The PS output produced by cairo is currently an image but eventually
the cairo PS backend will be updated to produce native PS.
Cairo itself has changed a lot since the last 0.4.0 snapshot, mostly
function name changes rather than new features. A new release should 
happen in a few weeks.
Steve

Hi all:
Here's a patch for axes.py that adds masked array support for pcolor. 
If either C[i,j], or any of the vertices surrounding it (X,Y at i,j 
i+1,j i+1,j+1 or i,j+1) are masked, the polygon is not filled. 
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Here's an attempt at adding a method to allow controlling of the maximum 
radial value displayed in a polar plot. In axes.py, I added the following 
method to the PolarAxes class. I basically copied the code from 
autoscale_view() and made some minor changes. If I can figure out what 
each step actually does I'll add some comments.
 def set_rmax( self, rmax ):
 rmin, oldrmax = self.rlocator.autoscale()
 self.rintv.set_bounds(rmin, rmax)
 self.axesPatch.xy = zip(self.thetas, rmax*ones(self.RESOLUTION))
 val = rmax*math.sqrt(2)
 self.viewLim.intervaly().set_bounds(val, val)
 # Re-create the radial ticks and labels.
 ticks = self.rlocator()
 self.set_rgrids(ticks)
 for t in self.thetagridlabels:
 t.set_y(1.05*rmax)
 r = linspace(0, rmax, self.RESOLUTION)
 for l in self.thetagridlines:
 l.set_ydata(r)
It sorta works but it definitely has a lot of problems. Here's a sample 
script:
from pylab import *
figure( figsize=( 5, 5 ) )
theta = arange( 1, 6, .1 )
r = 10 * theta
polar( theta, r )
show()
Then try:
gca().set_rmax( 30 )
show()
1) I don't really want to call set_rgrids() because you lose any 
modifications the user has made to the radial grid. If I don't call this, 
the radial grid doesn't update though so it looks crazy. What would be 
nice is to duplicate the behavior of X/Y plots. For example, if I set x 
ticks to be at 1,2,3 and then set the x limit to be 1->2, I don't see the 3 
tick somewhere off to the right of the plot.
2) There seems to be some kind of update problem w/ the theta labels. Even 
though they're locations are being reset in the set_y() call, they don't 
appear. However, if I use the pan button in the GUI and lightly tap the 
screen, they'll show up in the right locations (forget for a moment that 
panning is kind of a stupid thing to do in polar plots).
3) There is definitely some kind of data clipping problem. The curve is 
not being properly clipped at the plot boundaries after calling set_rmax().
I'm sure all of these are problems w/ my set_rmax() routine but I'm not 
sure where to start with them. Does anyone have any pointers for me to 
start with?
Thanks,
Ted

Hi,
It seems there is a little bug in axis.py, line 543 (in Axis.draw()).
The legacy Tick.set_label() is used instead of set_label1 and
set_label2 (a few lines above, the analogous code for major ticks uses
set_label1 and set_label2).
This causes minor tick labels not to be drawn when using tick_top(), as
shown in the attached example (+ two lines patch).

Thanks for the references. I decided to go for the second approach (it=20
seems maybe more sane, and it doesn't seem like their are any major=20
benefits to using the glyphs made..) The SVG code outputs a tuple of:
basename, fontsize, unicode, ox, oy, metrics
I go through the list, and output that. I'm not sure if I'm doing=20
everything correctly. For example, I have no clue what 'metrics'=20
contains (e.g. what advance, width, etc. will do, and if I need it or=20
not). I'm also not sure if things like hinting work using this method=20
either (esp. since I render each character seperately -- I'm not sure I=20
see any other method of doing it, however).
Any of this look sane?
ctx =3D cairo.Context()
file =3D open('test.ps', 'wb')
ctx.set_target_ps(file, 4.3, 4.3, 300, 300)
width, height, fonts =3D math_parse_s_ft2font_svg(r'$x^y * \pi$', 96, 50)
for f in fonts:
 basename, fontsize, num, ox, oy, metrics =3D f
 ctx.select_font(basename)
 ctx.scale_font(fontsize)
 ctx.move_to(ox, 100 - oy)
 ctx.show_text(unichr(num).encode('utf8'))
ctx.stroke()
ctx.show_page()
John Hunter wrote:
>>>>>>"Abraham" =3D=3D Abraham Schneider <ab...@cn...> writes:
>>>>>> =20
>>>>>>
>
> Abraham> When looking through the backend_cairo.py code, I
> Abraham> realized that it currently renders the mathtext as
> Abraham> images. While this is currently fine, as cairo's export
> Abraham> of PS is really just an image, it would be better in the
> Abraham> future to actually have it draw the fonts as paths.
>
> Abraham> My first approach was to hack 'draw_mathtext.py', and to
> Abraham> go and draw the strokes for the glyph's paths. The
> Abraham> commands that the glyphs allow are (according to
> Abraham> ft2font.cpp) are: MOVETO=3D0, LINETO=3D1, CURVE3=3D2, CURVE=
4=3D3,
> Abraham> ENDPOLY=3D4. It seemed fairly simple, as cairo has the
> Abraham> commands: 'move_to(x, y)', 'line_to(x, y)', and
> Abraham> 'close_path()'. I wasn't sure if move_to and line_to were
> Abraham> the equivalents of this, or actually 'rel_move_to' and
> Abraham> 'rel_line_to'. Also, I wasn't sure how to map CURVE3 onto
> Abraham> cairo's 'curve_to' (admittedly I know very little about
> Abraham> these types of curves).
>
> Abraham> If anyone has any suggestions on how to do this, it would
> Abraham> be greatly appreciated. I also realized halfway through
> Abraham> that perhaps it was a better idea to instead use cairo's
> Abraham> truetype font ability, and if there weren't a simpler
> Abraham> method to do this..
>
>I don't know much about cairo, but I can fill in a little detail about
>the font paths. From
>http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-6.html
>
> An outline is described as a series of closed contours in the 2D
> plane. Each contour is made of a series of line segments and B=E9zier
> arcs. Depending on the file format, these can be second-order or
> third-order polynomials. The former are also called quadratic or
> conic arcs, and they are used in the TrueType format. The latter are
> called cubic arcs and are mostly used in the Type 1 format.
>
>
>The CURVE3 code is a conic arc and the tuple that represents that
>curve in the glyph.path sequence is
>
> CURVE3, xctl, yctl, xto, yto
>
>and for cubic arcs is=20
>
> CURVE4, xctl1, yctl1, xctl2, yctl2, xto, yto
>
>
>The code to extra path from a glyph was lifted from agg, but I put the
>data structures in a list rather than an agg path to decouple agg form
>the freetype module. I'm still deliberating about whether this is a
>good idea or not.
>
>Like you, I am not sure how to best handle conic arcs in cairo, but
>Steve may know. Note that if you go the route you are considering,
>you will lose hinting information, so figuring out a way to use
>cairo's native truetype support may be preferable.
>
>So I can't really answer any of your questions .... but I'll post a
>conversion function from the ft2font path to an agg path in case it's
>of any use
>
>
>import os
>import matplotlib
>from matplotlib.ft2font import FT2Font
>import matplotlib.agg as agg
>
>MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY =3D range(5)
>
>def glyph_to_agg_path(glyph):
> path =3D agg.path_storage()
> for tup in glyph.path:
> print tup
> code =3D tup[0]
> if code =3D=3D MOVETO:
> x,y =3D tup[1:]
> path.move_to(x,y)
> elif code =3D=3D LINETO:
> x,y =3D tup[1:]
> path.line_to(x,y)
> elif code =3D=3D CURVE3:
> xctl, yctl, xto, yto=3D tup[1:]
> path.curve3(xctl, yctl, xto, yto)
>
> elif code =3D=3D CURVE4:
> xctl1, yctl1, xctl2, yctl2, xto, yto=3D tup[1:]
> path.curve4(xctl1, yct1, xctl2, yctl2, xto, yto)
> elif code =3D=3D ENDPOLY:
> path.end_poly()
>
> return path
>
>fname =3D os.path.join(matplotlib.get_data_path(), 'Vera.ttf')
>font =3D FT2Font(fname)
>glyph =3D font.load_char(ord('a'))
>path =3D glyph_to_agg_path(glyph)
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_ids93&alloc_id=16281&op=3Dclick
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20
>