matplotlib-users Mailing List for matplotlib (Page 2)

Darran Edmundson wrote:
> Two simple questions:
> 
> 1) How does one create a simple xy plot with a user-specified y-axis 
> range? Combination of setting kwargs ylim and autoscale_on doesn't seem 
> to do it ...
pylab.ylim( (ymin, ymax) )
or
pylab.gca().set_ylim( (ymin, ymax) )
?
> 2) If I want to regenerate this plot with revised y data (but same 
> axes), what is the quickest option? At the moment I'm doing an 
> ax.clear(), presumably tossing out everything and starting from scratch.
I do it this way - just replot everthing ...
> As always, any help is much appreciated.
> 
> Cheers,
> Darran.
> 

Two simple questions:
1) How does one create a simple xy plot with a user-specified y-axis 
range? Combination of setting kwargs ylim and autoscale_on doesn't seem 
to do it ...
2) If I want to regenerate this plot with revised y data (but same 
axes), what is the quickest option? At the moment I'm doing an 
ax.clear(), presumably tossing out everything and starting from scratch.
As always, any help is much appreciated.
Cheers,
Darran.
-- 
Darran Edmundson [da...@ed...]
http://www.edmstudio.com

Michael Droettboom wrote:
> I'm assuming you're using the Agg backend. If so, you can get the raw 
> memory wrapped in a Python buffer object as follows:
> figureCanvas.get_renderer().buffer_rgba(x, y)
> (where x, y is the upper left corner in the plot of the area you want to 
> get.) It should be possible in C side to then get the address out of 
> that using the Python/C API.
Hi Mike. I am using the above API call. What I'm hoping to avoid is 
having to copy this buffer to a ctypes buffer.
buff = figureCanvas.buffer_rgba(0,0)
cbuffer[:] = buff[:] ## would prefer to eliminate this step
address = ctypes.addressof(cbuffer)
ptr = ogre.CastVoidPtr(address)
This question probably belongs on the pythonOgre mailing list. Thanks 
though.
Cheers,
Darran.
-- 
Darran Edmundson [da...@ed...]
http://www.edmstudio.com

Sorry for the double sending, Giorgio. I got bitten by the Reply-To
bug for this list.
---------- Forwarded message ----------
From: Angus McMorland <am...@gm...>
Date: 30 Oct 2007 09:27
Subject: Re: [Matplotlib-users] (no subject)
To: "Gio...@ma..." <Gio...@ma...>
On 23/10/2007, Gio...@ma... <Gio...@ma...> wrote:
> Dear all,
> is there the possiblity in matplolib to buind dendograms ?
> I've searched a bit bout found no examples of it it seems not implemented
> is there a plan for doing it ?
There was some progress made on this a while back, starting with
PyCluster'ed data, for plotting the results of clustering analysis:
http://www.mail-archive.com/mat...@li.../msg00964.html
Alternatively, if you're after real dendrograms (i.e. for dendrites),
which follow slightly different rules, then I have some code based on
PyX (http://pyx.sourceforge.net/) which you may be able to adapt to
your needs.
Angus.
--
AJC McMorland, PhD Student
Physiology, University of Auckland

>> And the harder question. I need access to the address of the raw image
>> buffer. (I assume this is a contiguous block of c-allocated memory?)
>> Presently, I copy into a ctypes buffer but this slows things down
>> significantly. Is there an alternative approach?
I'm assuming you're using the Agg backend. If so, you can get the raw 
memory wrapped in a Python buffer object as follows:
 figureCanvas.get_renderer().buffer_rgba(x, y)
(where x, y is the upper left corner in the plot of the area you want to 
get.) It should be possible in C side to then get the address out of 
that using the Python/C API.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
2007年10月29日, Darran Edmundson <da...@ed...>:
>
> I'm trying to generate plots as textures for use within a real-time
> graphics application (written using the pythonOgre graphics engine).
> I'm brand new to matplotlib so please bear with me. Two questions, one
> easy, one possibly hard.
>
> In the following code snippet, I create and draw a pie chart, do some
> intermediate work, update the pie fractions, and redraw. I end up with
> the second version superimposed on the first. Initially I thought it
> was simply a matter of clearing the canvas, but as I repeat this test
> with more and more updates, the redraw seems to slow down - this makes
> me think that each redraw is actually rerendering all the layers. Is
> this the case? If so, how do I avoid it?
>
> # create matplotlib figure
> figure = Figure(figsize=(4,3), dpi=200, frameon=True)
> figureCanvas = FigureCanvas(figure)
>
> # unchanging details of pie chart
> ax = figure.add_subplot(111) # pie plot
> labels = 'Frogs', 'Hogs', 'Dogs', 'Logs'
> ax.set_title('Example pyOgre Pie Chart')
> ax.grid(True)
> ax.pie([25,25,30,20], labels=labels)
> figureCanvas.draw()
>
> # ....
>
> # update pie chart
At this point I guess you can do ax.clear() to clear the axis and
delete all the old plots.
> ax.pie([30,25,25,20], labels=labels)
>
> # matplotlib draw
> figureCanvas.draw()
>
>
>
> And the harder question. I need access to the address of the raw image
> buffer. (I assume this is a contiguous block of c-allocated memory?)
> Presently, I copy into a ctypes buffer but this slows things down
> significantly. Is there an alternative approach?
Sorry I can't help with this :-/.
Regards,
 ~ Antonio

I'm trying to generate plots as textures for use within a real-time 
graphics application (written using the pythonOgre graphics engine). 
I'm brand new to matplotlib so please bear with me. Two questions, one 
easy, one possibly hard.
In the following code snippet, I create and draw a pie chart, do some 
intermediate work, update the pie fractions, and redraw. I end up with 
the second version superimposed on the first. Initially I thought it 
was simply a matter of clearing the canvas, but as I repeat this test 
with more and more updates, the redraw seems to slow down - this makes 
me think that each redraw is actually rerendering all the layers. Is 
this the case? If so, how do I avoid it?
# create matplotlib figure
figure = Figure(figsize=(4,3), dpi=200, frameon=True)
figureCanvas = FigureCanvas(figure)
# unchanging details of pie chart
ax = figure.add_subplot(111) # pie plot
labels = 'Frogs', 'Hogs', 'Dogs', 'Logs'
ax.set_title('Example pyOgre Pie Chart')
ax.grid(True)
ax.pie([25,25,30,20], labels=labels)
figureCanvas.draw()
# ....
# update pie chart
ax.pie([30,25,25,20], labels=labels)
# matplotlib draw
figureCanvas.draw()
And the harder question. I need access to the address of the raw image 
buffer. (I assume this is a contiguous block of c-allocated memory?) 
Presently, I copy into a ctypes buffer but this slows things down 
significantly. Is there an alternative approach?
# retrieve buffer from matplotlib
height = int( figureCanvas.get_renderer().height )
width = int( figureCanvas.get_renderer().width )
# extract image buffer (need as void ptr to contiguous byte array)
buff = figureCanvas.buffer_rgba(0,0)
cbuffer[:] = buff[:] ## would prefer to eliminate this step
address = ctypes.addressof(cbuffer)
Any help is much appreciated ...
Cheers,
Darran.
-- 
Darran Edmundson [da...@ed...]
http://www.edmstudio.com

On 10/29/07, Michael Droettboom <md...@st...> wrote:
> I submitted a fix for this in matplotlib SVN r4047. Freetype takes a
> FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode
> hinter at runtime (even if it was compiled in). This appears to fix the
> problem, and doesn't force people to recompile their freetype -- they
> should now get identical results regardless.
Andrew Straw and I taught a workshop at the Claremont Colleges this
weekend and I was running mpl from svn. When I brought up the 1st
figure in ipython -pylab mode running GTKAgg, the fonts were totally
whacked (see attached) and I was reminded of why they call it "the
bleeding edge". Fortunately, it only affected the first draw of an
ipython session. For example, a figure resize, which triggers the
draw, made the problem go away, and subsequent figures were fine.
Odd. I just updated from svn and it looks like the problem is gone on
that machine, so I hope this was the source of the problem (the
workshop machine was running open-suse)
In [2]: !uname -a
Linux ns3 2.6.18.8-0.5-bigsmp #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686
i686 i386 GNU/Linux
In other news, TkAgg is segfaulting in that environment, but I haven't
had time to track it down since I was busy preparing the course
material.
JDH

Le Monday 29 October 2007 10:57:52 Darren Dale, vous avez =C3=A9crit=C2=A0:
> On Monday 29 October 2007 10:45:22 am Michael Droettboom wrote:
> > Darren Dale wrote:
> > > On Monday 29 October 2007 10:09:21 am Michael Droettboom wrote:
> > >> Michael Droettboom wrote:
> > >>> Darren Dale wrote:
> > >>>> I think the problem is related to autohinting. When I compile
> > >>>> freetype, the patented bytecode and subpixel hinting support is
> > >>>> disabled, I am using freetype's autohinting instead. I recompiled
> > >>>> freetype with the support for the patented hinting instead of
> > >>>> autohinting, and reran the test on cmmi.ttf. The result is
> > >>>> cmmi10_p.txt.
> > >>>
> > >>> That seems like a likely explanation... Exactly, which #defines did
> > >>> you change to make it work again? The vanilla freetype tarball wor=
ks
> > >>> for me...
> > >>
> > >> I seem to have the reversed behavior. On my machine, if I have the
> > >> patented bytecodes disabled (which is the default when you download
> > >> the vanilla freetype tarball from freetype.sf.net), everything works=
=2E=20
> > >> When I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in
> > >> ftoption.h, things break. (And great news, I'm finally able to
> > >> reproduce this problem.) Is that not what you see?
> > >
> > > Crap. I looked right over the "!" in "if ! use bindist". So you are
> > > correct, the problem occurs when support for patented hinting is
> > > enabled and autohinting is disabled. Did I get it right this time? (I=
'm
> > > running on very little sleep. Sorry for the confusion.)
> >
> > No worries. Grad to see we're at least seeing the same thing (this has
> > been a very elusive bug...)
> >
> > I submitted a fix for this in matplotlib SVN r4047. Freetype takes a
> > FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode
> > hinter at runtime (even if it was compiled in). This appears to fix the
> > problem, and doesn't force people to recompile their freetype -- they
> > should now get identical results regardless.
>
> Works here, thank you very much for your hard work!
>
> Darren
Oups I just come back and I was unable to do test but fortunatly Dave seem =
to=20
have been able to manage it, thank you. The fix is working here too, thank=
=20
you very much. Great work!=20
Nicolas

On 10/21/07, nitriles <jo...@gm...> wrote:
>
> Hey, Ive got 10 strings of data that i plot into 1 big window, but somehow
> matplotlib gives me a very strange set-up. I am rather new to matplotlib and
> python so im kinda stuck now!
> heres an image of what i get and part of my code:
>
> http://www.nabble.com/file/p13290670/Bildschirmphoto1.png
>
> ###############################################
> from scipy import *
> import pylab
> from scipy.optimize import leastsq
> import sys
>
> #Functions
>
> def pload(filename):
> """function for loading special Mira data"""
>
> def residuals(p, y, x):
> A,k,theta,C = p
> err = y - (A*sin(k*x+theta)**2+C)
> return err
>
> def peval(x,p):
> A,k,theta,C = p
> return A*sin(k*x+theta)**2+C
>
>
> for i in range(len(data)):
> dat = data[i,:]
> x=arange(1,17,1)
> y_meas = dat[2:]
> freq1=dat[0]
> freq2=dat[1]
>
> #Plotting
>
> min=x.min()
> max=x.max()
> step=(max-min)/100.
> xfine=arange(min,max,step)
> subnr=250+i+1
> pylab.subplot(subnr)
Try
 pylab.subplot(2,5,i+1)
Once you get past 9, you cannot use the subplot number w/o commas.
The format is
 subplot(numrows, numcols, plotnum)
so you can write
 subplot(211) or or subplot(2,1,1) which mean the same thing, bug
the version w/o commas only works if the plotnum<10
> pylab.plot(xfine,peval(xfine,plsq[0]), 'r')
> pylab.errorbar(x,y_meas,yerr=sqrt(y_meas),fmt='bo')
> pylab.xlabel('Number [...]')
> pylab.ylabel('Value [...]')
> pylab.grid(True)
>
> pylab.legend(('Fitting', 'Measured Data'),
> 'upper right', shadow=True)
> pylab.title('Least square fit for Mira')
> pylab.show()
>
> ##############################################
>
> I just want the graph to be arranged properly into the window.
> Later i need to add a main title, a title for each graph and return the
> values that the computer used to fit the graph (meaning A, k, theta and C)
> Thanks a lot!
> -Julia-
> --
> View this message in context: http://www.nabble.com/sub-plotting-10-into-the-window-tf4651852.html#a13290670
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Monday 29 October 2007 10:45:22 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Monday 29 October 2007 10:09:21 am Michael Droettboom wrote:
> >> Michael Droettboom wrote:
> >>> Darren Dale wrote:
> >>>> I think the problem is related to autohinting. When I compile
> >>>> freetype, the patented bytecode and subpixel hinting support is
> >>>> disabled, I am using freetype's autohinting instead. I recompiled
> >>>> freetype with the support for the patented hinting instead of
> >>>> autohinting, and reran the test on cmmi.ttf. The result is
> >>>> cmmi10_p.txt.
> >>>
> >>> That seems like a likely explanation... Exactly, which #defines did
> >>> you change to make it work again? The vanilla freetype tarball works
> >>> for me...
> >>
> >> I seem to have the reversed behavior. On my machine, if I have the
> >> patented bytecodes disabled (which is the default when you download the
> >> vanilla freetype tarball from freetype.sf.net), everything works. When
> >> I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in
> >> ftoption.h, things break. (And great news, I'm finally able to
> >> reproduce this problem.) Is that not what you see?
> >
> > Crap. I looked right over the "!" in "if ! use bindist". So you are
> > correct, the problem occurs when support for patented hinting is enabled
> > and autohinting is disabled. Did I get it right this time? (I'm running
> > on very little sleep. Sorry for the confusion.)
>
> No worries. Grad to see we're at least seeing the same thing (this has
> been a very elusive bug...)
>
> I submitted a fix for this in matplotlib SVN r4047. Freetype takes a
> FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode
> hinter at runtime (even if it was compiled in). This appears to fix the
> problem, and doesn't force people to recompile their freetype -- they
> should now get identical results regardless.
Works here, thank you very much for your hard work!
Darren

Darren Dale wrote:
> On Monday 29 October 2007 10:09:21 am Michael Droettboom wrote:
>> Michael Droettboom wrote:
>>> Darren Dale wrote:
>>>> I think the problem is related to autohinting. When I compile freetype,
>>>> the patented bytecode and subpixel hinting support is disabled, I am
>>>> using freetype's autohinting instead. I recompiled freetype with the
>>>> support for the patented hinting instead of autohinting, and reran the
>>>> test on cmmi.ttf. The result is cmmi10_p.txt.
>>> That seems like a likely explanation... Exactly, which #defines did you
>>> change to make it work again? The vanilla freetype tarball works for
>>> me...
>> I seem to have the reversed behavior. On my machine, if I have the
>> patented bytecodes disabled (which is the default when you download the
>> vanilla freetype tarball from freetype.sf.net), everything works. When
>> I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in
>> ftoption.h, things break. (And great news, I'm finally able to
>> reproduce this problem.) Is that not what you see?
 >
> Crap. I looked right over the "!" in "if ! use bindist". So you are correct, 
> the problem occurs when support for patented hinting is enabled and 
> autohinting is disabled. Did I get it right this time? (I'm running on very 
> little sleep. Sorry for the confusion.)
No worries. Grad to see we're at least seeing the same thing (this has 
been a very elusive bug...)
I submitted a fix for this in matplotlib SVN r4047. Freetype takes a 
FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode 
hinter at runtime (even if it was compiled in). This appears to fix the 
problem, and doesn't force people to recompile their freetype -- they 
should now get identical results regardless.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

[My original response to the list got bounced because it included zip files=
=2E I=20
am posting again without the attachments.]
I attached the results (_b is with BROKEN =3D 0). I didn't notice any probl=
ems=20
in the Vera test, but in cmmi, Delta has problems when BROKEN is 1, it look=
s=20
better when BROKEN is 0.
I think the problem is related to autohinting. When I compile freetype, the=
=20
patented bytecode and subpixel hinting support is disabled, I am using=20
freetype's autohinting instead. I recompiled freetype with the support for=
=20
the patented hinting instead of autohinting, and reran the test on cmmi.ttf=
=2E=20
The result is cmmi10_p.txt.
Darren
On Monday 29 October 2007 08:57:42 am Michael Droettboom wrote:
> I should also mention -- please let me know if setting BROKEN to 0 fixes
> any rendering problems.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > Forgot to attach the program.
> >
> > Michael Droettboom wrote:
> >> Nicolas, Darren,
> >>
> >> I have created a minimal program that hopefully will exercise the
> >> problem. If it breaks for either of you, I'll take this to the
> >> freetype mailing list for further clarification... If it doesn't
> >> break for you, my theory about the cause is still incorrect.
> >>
> >> I have attached a small C program. You can build it as follows,
> >> assuming freetype is installed in the usual place:
> >>
> >> gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o
> >> test_hinting_stretch
> >>
> >> Then you can run it by providing a .ttf fontname on the path. The one
> >> that seems to trip up so far is
> >> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source
> >> tree), but I'm curious to know if it also breaks for other more
> >> popular fonts like vera.ttf.
> >>
> >> ./test_hinting_stretch path_to_font
> >>
> >> It will render and print out all the glyphs in the font on stdout.
> >> Please send me the output (offlist, since it will be quite long).
> >>
> >> Thanks for helping me solve this problem,
> >> Mike
> >>
> >> hu...@ya... wrote:
> >>> I tried to change the value and the highest one I can use is 2 so
> >>> it's not a big improvement for what I understand.
> >>>
> >>> You can contact me if you need other test naturally
> >>>
> >>> N.
> >>>
> >>> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez =C3=
=A9crit :
> >>>> It's great to have narrowed this down! Unfortunately, with that
> >>>> #define
> >>>> removed, you will get lower quality fonts (the hinting will be more
> >>>> extreme, which causes the glyphs to often look too thin, or
> >>>> inconsistent.) See this thread for more information --
> >>>>
> >>>> http://www.mail-archive.com/mat...@li.../m=
sg
> >>>>01480
> >>>>
> >>>> .html
> >>>>
> >>>> I'd hate to turn off this improvement because it doesn't work in some
> >>>> environments.
> >>>>
> >>>> I wonder if you wouldn't mind performing one more experiment... The=
re
> >>>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
> >>>> controls the amount of hinting subsampling. Currently it is set to =
8,
> >>>> but I wonder if a lower value would work. Ideally, we want to set
> >>>> this as high as we can get away with.
> >>>>
> >>>> #define VERTICAL_HINTING
> >>>> #ifdef VERTICAL_HINTING
> >>>> #define HORIZ_HINTING 8
> >>>> #else
> >>>> #define HORIZ_HINTING 1
> >>>> #endif
> >>>>
> >>>> Would you mind trying other values and seeing if any work? If not,
> >>>> I'll
> >>>> probably take this question to the freetype mailing list now that
> >>>> we've narrowed the cause down to only a three line difference in the
> >>>> code.
> >>>>
> >>>> Cheers,
> >>>> Mike
> >>>>
> >>>> hu...@ya... wrote:
> >>>>> Le Friday 26 October 2007 11:22:06, vous avez =C3=A9crit :
> >>>>>> Thanks for this information. It looks like the font outline data =
is
> >>>>>> somehow getting corrupted before freetype renders it. Again,
> >>>>>> however, I
> >>>>>> can't reproduce it on my machine (I've attached a copy of what it
> >>>>>> looks
> >>>>>> like for me), so I'm still pretty stumped. My suspicion is that
> >>>>>> it's a
> >>>>>> 64-bit vs. 32-bit problem since both people known to have trouble
> >>>>>> are on
> >>>>>> 64-bit platforms, and I am not. I have tried recompiling with
> >>>>>> gcc-4.2.2
> >>>>>> and I still wasn't able to reproduce.
> >>>>>
> >>>>> I can imagine that it's difficult for you to debug something you
> >>>>> cannot
> >>>>> reproduce. Just a remark I don't have 64-bits but a 32 so the
> >>>>> problem is
> >>>>> not comming because of the plateforme.
> >>>>>
> >>>>>> One thing you could *try*, to rule out any recent changes to the
> >>>>>> glyph
> >>>>>> rendering, is to comment out this line near the top of
> >>>>>> src/ft2font.cpp:
> >>>>>>
> >>>>>> #define VERTICAL_HINTING
> >>>>>>
> >>>>>> as follows
> >>>>>>
> >>>>>> //#define VERTICAL_HINTING
> >>>>>
> >>>>> Yes it's doing the trick., I don't have anymore the problem. Thank
> >>>>> you very much. I have now the same result than you with the test I
> >>>>> produce before.
> >>>>>
> >>>>>> Additional information: Are there any warnings produced when
> >>>>>> compiling
> >>>>>> ft2font.cpp? Can you send me your matplotlibrc file?
> >>>>>
> >>>>> just the classic one:
> >>>>>
> >>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is
> >>>>> valid for
> >>>>> Ada/C/ObjC but not for C++
> >>>>>
> >>>>> Thank you very much.
> >>>>>
> >>>>> N.
> >>>>>
> >>>>>> Cheers,
> >>>>>> Mike
> >>>>>>
> >>>>>> hu...@ya... wrote:
> >>>>>>> Yep that can be a good idea. I don't know anything on how
> >>>>>>> mathtext is
> >>>>>>> working but I'm not completely sure that the problem is with
> >>>>>>> freetype
> >>>>>>> because sometime that can work. In reality every character I test=
ed
> >>>>>>> worked but you have to put in a certain order. To understand a
> >>>>>>> little
> >>>>>>> bit more what I try to say (very badly) see the script join and t=
he
> >>>>>>> figure.
> >>>>>>>
> >>>>>>> I hope that can help a little bit to try to find the reason of th=
is
> >>>>>>> behaviour.
> >>>>>>>
> >>>>>>> N
> >>>>>>>
> >>>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez
> >>>
> >>> =C3=A9crit :
> >>>>>>>> Darren Dale wrote:
> >>>>>>>>> Hi Mike,
> >>>>>>>>>
> >>>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
> >>>>>>>>>> Unfortunately, I can't reproduce this on my machine even with
> >>>>>>>>>> the latest stable version of freetype-2.5.3 (which is the same
> >>>>>>>>>> version
> >>>>>>>>>> in Ubuntu Gutsy).
> >>>>>>>>>
> >>>>>>>>> I think you mean freetype-2.3.5. I also have that version
> >>>>>>>>> installed,
> >>>>>>>>> although the mpl setup script is reporting 9.16.3.
> >>>>>>>>
> >>>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don=
't
> >>>>>>>> fully comprehend why the pkgconfig version doesn't match the
> >>>>>>>> release
> >>>>>>>> version (and why freetype2 is called freetype6 on Debian and
> >>>>>>>> derivatives)... but my numbers do match yours.
> >>>>>>>>
> >>>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
> >>>>>>>>>> applied, and I don't know if they are causing this (but from t=
he
> >>>>>>>>>> looks of them, I doubt it).
> >>>>>>>>>>
> >>>>>>>>>> Can you set debug.verbose to "annoying" and send me the output
> >>>>>>>>>> of your matplotlib run? I want to rule out any font-loading
> >>>>>>>>>> problems.
> >>>>>>>>>
> >>>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled wi=
th
> >>>>>>>>> gcc-4.2.2, in case its relevent.
> >>>>>>>>
> >>>>>>>> Always good to have more details, but I'm sort of at a loss on
> >>>>>>>> this one, especially since I can't reproduce it.
> >>>>>>>>
> >>>>>>>> Maybe we need to take a poll on this list of who is working and
> >>>>>>>> who isn't to see what the source of the breakage may be...
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Mike
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------------=
=2D-
> >>>>>>>>----
> >>>>>>>>
> >>>>>>>> --
> >
> > ------------------------------------------------------------------------
> >
> > -----------------------------------------------------------------------=
=2D-
> > 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-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
=2D-=20
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

On Monday 29 October 2007 10:09:21 am Michael Droettboom wrote:
> Michael Droettboom wrote:
> > Darren Dale wrote:
> >> I think the problem is related to autohinting. When I compile freetype,
> >> the patented bytecode and subpixel hinting support is disabled, I am
> >> using freetype's autohinting instead. I recompiled freetype with the
> >> support for the patented hinting instead of autohinting, and reran the
> >> test on cmmi.ttf. The result is cmmi10_p.txt.
> >
> > That seems like a likely explanation... Exactly, which #defines did you
> > change to make it work again? The vanilla freetype tarball works for
> > me...
>
> I seem to have the reversed behavior. On my machine, if I have the
> patented bytecodes disabled (which is the default when you download the
> vanilla freetype tarball from freetype.sf.net), everything works. When
> I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in
> ftoption.h, things break. (And great news, I'm finally able to
> reproduce this problem.) Is that not what you see?
Gentoo's ebuild has a bindist use flag:
 enable_option() {
 sed -i -e "/#define 1ドル/a #define 1ドル" \
 include/freetype/config/ftoption.h \
 || die "unable to enable option 1ドル"
 }
 disable_option() {
 sed -i -e "/#define 1ドル/ { s:^:/*:; s:$:*/: }" \
 include/freetype/config/ftoption.h \
 || die "unable to disable option 1ドル"
 }
 if ! use bindist; then
 # Bytecodes and subpixel hinting supports are patented
 # in United States; for safety, disable them while building
 # binaries, so that no risky code is distributed.
 # See http://freetype.org/patents.html
 enable_option FT_CONFIG_OPTION_SUBPIXEL_RENDERING
 enable_option TT_CONFIG_OPTION_BYTECODE_INTERPRETER
 disable_option TT_CONFIG_OPTION_UNPATENTED_HINTING
 fi
Crap. I looked right over the "!" in "if ! use bindist". So you are correct, 
the problem occurs when support for patented hinting is enabled and 
autohinting is disabled. Did I get it right this time? (I'm running on very 
little sleep. Sorry for the confusion.)
Darren

Michael Droettboom wrote:
> Darren Dale wrote:
>> I think the problem is related to autohinting. When I compile freetype, the 
>> patented bytecode and subpixel hinting support is disabled, I am using 
>> freetype's autohinting instead. I recompiled freetype with the support for 
>> the patented hinting instead of autohinting, and reran the test on cmmi.ttf. 
>> The result is cmmi10_p.txt.
> 
> That seems like a likely explanation... Exactly, which #defines did you 
> change to make it work again? The vanilla freetype tarball works for me...
I seem to have the reversed behavior. On my machine, if I have the 
patented bytecodes disabled (which is the default when you download the 
vanilla freetype tarball from freetype.sf.net), everything works. When 
I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in 
ftoption.h, things break. (And great news, I'm finally able to 
reproduce this problem.) Is that not what you see?
Cheers,
Mike
>> On Monday 29 October 2007 08:57:42 am Michael Droettboom wrote:
>>> I should also mention -- please let me know if setting BROKEN to 0 fixes
>>> any rendering problems.
>>>
>>> Cheers,
>>> Mike
>>>
>>> Michael Droettboom wrote:
>>>> Forgot to attach the program.
>>>>
>>>> Michael Droettboom wrote:
>>>>> Nicolas, Darren,
>>>>>
>>>>> I have created a minimal program that hopefully will exercise the
>>>>> problem. If it breaks for either of you, I'll take this to the
>>>>> freetype mailing list for further clarification... If it doesn't
>>>>> break for you, my theory about the cause is still incorrect.
>>>>>
>>>>> I have attached a small C program. You can build it as follows,
>>>>> assuming freetype is installed in the usual place:
>>>>>
>>>>> gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o
>>>>> test_hinting_stretch
>>>>>
>>>>> Then you can run it by providing a .ttf fontname on the path. The one
>>>>> that seems to trip up so far is
>>>>> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source
>>>>> tree), but I'm curious to know if it also breaks for other more
>>>>> popular fonts like vera.ttf.
>>>>>
>>>>> ./test_hinting_stretch path_to_font
>>>>>
>>>>> It will render and print out all the glyphs in the font on stdout.
>>>>> Please send me the output (offlist, since it will be quite long).
>>>>>
>>>>> Thanks for helping me solve this problem,
>>>>> Mike
>>>>>
>>>>> hu...@ya... wrote:
>>>>>> I tried to change the value and the highest one I can use is 2 so
>>>>>> it's not a big improvement for what I understand.
>>>>>>
>>>>>> You can contact me if you need other test naturally
>>>>>>
>>>>>> N.
>>>>>>
>>>>>> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez écrit :
>>>>>>> It's great to have narrowed this down! Unfortunately, with that
>>>>>>> #define
>>>>>>> removed, you will get lower quality fonts (the hinting will be more
>>>>>>> extreme, which causes the glyphs to often look too thin, or
>>>>>>> inconsistent.) See this thread for more information --
>>>>>>>
>>>>>>> http://www.mail-archive.com/mat...@li.../msg
>>>>>>> 01480
>>>>>>>
>>>>>>> .html
>>>>>>>
>>>>>>> I'd hate to turn off this improvement because it doesn't work in some
>>>>>>> environments.
>>>>>>>
>>>>>>> I wonder if you wouldn't mind performing one more experiment... There
>>>>>>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
>>>>>>> controls the amount of hinting subsampling. Currently it is set to 8,
>>>>>>> but I wonder if a lower value would work. Ideally, we want to set
>>>>>>> this as high as we can get away with.
>>>>>>>
>>>>>>> #define VERTICAL_HINTING
>>>>>>> #ifdef VERTICAL_HINTING
>>>>>>> #define HORIZ_HINTING 8
>>>>>>> #else
>>>>>>> #define HORIZ_HINTING 1
>>>>>>> #endif
>>>>>>>
>>>>>>> Would you mind trying other values and seeing if any work? If not,
>>>>>>> I'll
>>>>>>> probably take this question to the freetype mailing list now that
>>>>>>> we've narrowed the cause down to only a three line difference in the
>>>>>>> code.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mike
>>>>>>>
>>>>>>> hu...@ya... wrote:
>>>>>>>> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>>>>>>>>> Thanks for this information. It looks like the font outline data is
>>>>>>>>> somehow getting corrupted before freetype renders it. Again,
>>>>>>>>> however, I
>>>>>>>>> can't reproduce it on my machine (I've attached a copy of what it
>>>>>>>>> looks
>>>>>>>>> like for me), so I'm still pretty stumped. My suspicion is that
>>>>>>>>> it's a
>>>>>>>>> 64-bit vs. 32-bit problem since both people known to have trouble
>>>>>>>>> are on
>>>>>>>>> 64-bit platforms, and I am not. I have tried recompiling with
>>>>>>>>> gcc-4.2.2
>>>>>>>>> and I still wasn't able to reproduce.
>>>>>>>> I can imagine that it's difficult for you to debug something you
>>>>>>>> cannot
>>>>>>>> reproduce. Just a remark I don't have 64-bits but a 32 so the
>>>>>>>> problem is
>>>>>>>> not comming because of the plateforme.
>>>>>>>>
>>>>>>>>> One thing you could *try*, to rule out any recent changes to the
>>>>>>>>> glyph
>>>>>>>>> rendering, is to comment out this line near the top of
>>>>>>>>> src/ft2font.cpp:
>>>>>>>>>
>>>>>>>>> #define VERTICAL_HINTING
>>>>>>>>>
>>>>>>>>> as follows
>>>>>>>>>
>>>>>>>>> //#define VERTICAL_HINTING
>>>>>>>> Yes it's doing the trick., I don't have anymore the problem. Thank
>>>>>>>> you very much. I have now the same result than you with the test I
>>>>>>>> produce before.
>>>>>>>>
>>>>>>>>> Additional information: Are there any warnings produced when
>>>>>>>>> compiling
>>>>>>>>> ft2font.cpp? Can you send me your matplotlibrc file?
>>>>>>>> just the classic one:
>>>>>>>>
>>>>>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is
>>>>>>>> valid for
>>>>>>>> Ada/C/ObjC but not for C++
>>>>>>>>
>>>>>>>> Thank you very much.
>>>>>>>>
>>>>>>>> N.
>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> hu...@ya... wrote:
>>>>>>>>>> Yep that can be a good idea. I don't know anything on how
>>>>>>>>>> mathtext is
>>>>>>>>>> working but I'm not completely sure that the problem is with
>>>>>>>>>> freetype
>>>>>>>>>> because sometime that can work. In reality every character I tested
>>>>>>>>>> worked but you have to put in a certain order. To understand a
>>>>>>>>>> little
>>>>>>>>>> bit more what I try to say (very badly) see the script join and the
>>>>>>>>>> figure.
>>>>>>>>>>
>>>>>>>>>> I hope that can help a little bit to try to find the reason of this
>>>>>>>>>> behaviour.
>>>>>>>>>>
>>>>>>>>>> N
>>>>>>>>>>
>>>>>>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez
>>>>>> écrit :
>>>>>>>>>>> Darren Dale wrote:
>>>>>>>>>>>> Hi Mike,
>>>>>>>>>>>>
>>>>>>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>>>>>>>>> Unfortunately, I can't reproduce this on my machine even with
>>>>>>>>>>>>> the latest stable version of freetype-2.5.3 (which is the same
>>>>>>>>>>>>> version
>>>>>>>>>>>>> in Ubuntu Gutsy).
>>>>>>>>>>>> I think you mean freetype-2.3.5. I also have that version
>>>>>>>>>>>> installed,
>>>>>>>>>>>> although the mpl setup script is reporting 9.16.3.
>>>>>>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
>>>>>>>>>>> fully comprehend why the pkgconfig version doesn't match the
>>>>>>>>>>> release
>>>>>>>>>>> version (and why freetype2 is called freetype6 on Debian and
>>>>>>>>>>> derivatives)... but my numbers do match yours.
>>>>>>>>>>>
>>>>>>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>>>>>>>>> applied, and I don't know if they are causing this (but from the
>>>>>>>>>>>>> looks of them, I doubt it).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you set debug.verbose to "annoying" and send me the output
>>>>>>>>>>>>> of your matplotlib run? I want to rule out any font-loading
>>>>>>>>>>>>> problems.
>>>>>>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>>>>>>>>> gcc-4.2.2, in case its relevent.
>>>>>>>>>>> Always good to have more details, but I'm sort of at a loss on
>>>>>>>>>>> this one, especially since I can't reproduce it.
>>>>>>>>>>>
>>>>>>>>>>> Maybe we need to take a poll on this list of who is working and
>>>>>>>>>>> who isn't to see what the source of the breakage may be...
>>>>>>>>>>>
>>>>>>>>>>> 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-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks for that. You really downplayed the problems when BROKEN is 1. 
It seems to me that most of the glyphs are very bad -- the 'e', for 
instance, is filled in the middle.
Darren Dale wrote:
> I think the problem is related to autohinting. When I compile freetype, the 
> patented bytecode and subpixel hinting support is disabled, I am using 
> freetype's autohinting instead. I recompiled freetype with the support for 
> the patented hinting instead of autohinting, and reran the test on cmmi.ttf. 
> The result is cmmi10_p.txt.
That seems like a likely explanation... Exactly, which #defines did you 
change to make it work again? The vanilla freetype tarball works for me...
Cheers,
Mike
> On Monday 29 October 2007 08:57:42 am Michael Droettboom wrote:
>> I should also mention -- please let me know if setting BROKEN to 0 fixes
>> any rendering problems.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>>> Forgot to attach the program.
>>>
>>> Michael Droettboom wrote:
>>>> Nicolas, Darren,
>>>>
>>>> I have created a minimal program that hopefully will exercise the
>>>> problem. If it breaks for either of you, I'll take this to the
>>>> freetype mailing list for further clarification... If it doesn't
>>>> break for you, my theory about the cause is still incorrect.
>>>>
>>>> I have attached a small C program. You can build it as follows,
>>>> assuming freetype is installed in the usual place:
>>>>
>>>> gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o
>>>> test_hinting_stretch
>>>>
>>>> Then you can run it by providing a .ttf fontname on the path. The one
>>>> that seems to trip up so far is
>>>> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source
>>>> tree), but I'm curious to know if it also breaks for other more
>>>> popular fonts like vera.ttf.
>>>>
>>>> ./test_hinting_stretch path_to_font
>>>>
>>>> It will render and print out all the glyphs in the font on stdout.
>>>> Please send me the output (offlist, since it will be quite long).
>>>>
>>>> Thanks for helping me solve this problem,
>>>> Mike
>>>>
>>>> hu...@ya... wrote:
>>>>> I tried to change the value and the highest one I can use is 2 so
>>>>> it's not a big improvement for what I understand.
>>>>>
>>>>> You can contact me if you need other test naturally
>>>>>
>>>>> N.
>>>>>
>>>>> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez écrit :
>>>>>> It's great to have narrowed this down! Unfortunately, with that
>>>>>> #define
>>>>>> removed, you will get lower quality fonts (the hinting will be more
>>>>>> extreme, which causes the glyphs to often look too thin, or
>>>>>> inconsistent.) See this thread for more information --
>>>>>>
>>>>>> http://www.mail-archive.com/mat...@li.../msg
>>>>>> 01480
>>>>>>
>>>>>> .html
>>>>>>
>>>>>> I'd hate to turn off this improvement because it doesn't work in some
>>>>>> environments.
>>>>>>
>>>>>> I wonder if you wouldn't mind performing one more experiment... There
>>>>>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
>>>>>> controls the amount of hinting subsampling. Currently it is set to 8,
>>>>>> but I wonder if a lower value would work. Ideally, we want to set
>>>>>> this as high as we can get away with.
>>>>>>
>>>>>> #define VERTICAL_HINTING
>>>>>> #ifdef VERTICAL_HINTING
>>>>>> #define HORIZ_HINTING 8
>>>>>> #else
>>>>>> #define HORIZ_HINTING 1
>>>>>> #endif
>>>>>>
>>>>>> Would you mind trying other values and seeing if any work? If not,
>>>>>> I'll
>>>>>> probably take this question to the freetype mailing list now that
>>>>>> we've narrowed the cause down to only a three line difference in the
>>>>>> code.
>>>>>>
>>>>>> Cheers,
>>>>>> Mike
>>>>>>
>>>>>> hu...@ya... wrote:
>>>>>>> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>>>>>>>> Thanks for this information. It looks like the font outline data is
>>>>>>>> somehow getting corrupted before freetype renders it. Again,
>>>>>>>> however, I
>>>>>>>> can't reproduce it on my machine (I've attached a copy of what it
>>>>>>>> looks
>>>>>>>> like for me), so I'm still pretty stumped. My suspicion is that
>>>>>>>> it's a
>>>>>>>> 64-bit vs. 32-bit problem since both people known to have trouble
>>>>>>>> are on
>>>>>>>> 64-bit platforms, and I am not. I have tried recompiling with
>>>>>>>> gcc-4.2.2
>>>>>>>> and I still wasn't able to reproduce.
>>>>>>> I can imagine that it's difficult for you to debug something you
>>>>>>> cannot
>>>>>>> reproduce. Just a remark I don't have 64-bits but a 32 so the
>>>>>>> problem is
>>>>>>> not comming because of the plateforme.
>>>>>>>
>>>>>>>> One thing you could *try*, to rule out any recent changes to the
>>>>>>>> glyph
>>>>>>>> rendering, is to comment out this line near the top of
>>>>>>>> src/ft2font.cpp:
>>>>>>>>
>>>>>>>> #define VERTICAL_HINTING
>>>>>>>>
>>>>>>>> as follows
>>>>>>>>
>>>>>>>> //#define VERTICAL_HINTING
>>>>>>> Yes it's doing the trick., I don't have anymore the problem. Thank
>>>>>>> you very much. I have now the same result than you with the test I
>>>>>>> produce before.
>>>>>>>
>>>>>>>> Additional information: Are there any warnings produced when
>>>>>>>> compiling
>>>>>>>> ft2font.cpp? Can you send me your matplotlibrc file?
>>>>>>> just the classic one:
>>>>>>>
>>>>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is
>>>>>>> valid for
>>>>>>> Ada/C/ObjC but not for C++
>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> N.
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> hu...@ya... wrote:
>>>>>>>>> Yep that can be a good idea. I don't know anything on how
>>>>>>>>> mathtext is
>>>>>>>>> working but I'm not completely sure that the problem is with
>>>>>>>>> freetype
>>>>>>>>> because sometime that can work. In reality every character I tested
>>>>>>>>> worked but you have to put in a certain order. To understand a
>>>>>>>>> little
>>>>>>>>> bit more what I try to say (very badly) see the script join and the
>>>>>>>>> figure.
>>>>>>>>>
>>>>>>>>> I hope that can help a little bit to try to find the reason of this
>>>>>>>>> behaviour.
>>>>>>>>>
>>>>>>>>> N
>>>>>>>>>
>>>>>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez
>>>>> écrit :
>>>>>>>>>> Darren Dale wrote:
>>>>>>>>>>> Hi Mike,
>>>>>>>>>>>
>>>>>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>>>>>>>> Unfortunately, I can't reproduce this on my machine even with
>>>>>>>>>>>> the latest stable version of freetype-2.5.3 (which is the same
>>>>>>>>>>>> version
>>>>>>>>>>>> in Ubuntu Gutsy).
>>>>>>>>>>> I think you mean freetype-2.3.5. I also have that version
>>>>>>>>>>> installed,
>>>>>>>>>>> although the mpl setup script is reporting 9.16.3.
>>>>>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
>>>>>>>>>> fully comprehend why the pkgconfig version doesn't match the
>>>>>>>>>> release
>>>>>>>>>> version (and why freetype2 is called freetype6 on Debian and
>>>>>>>>>> derivatives)... but my numbers do match yours.
>>>>>>>>>>
>>>>>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>>>>>>>> applied, and I don't know if they are causing this (but from the
>>>>>>>>>>>> looks of them, I doubt it).
>>>>>>>>>>>>
>>>>>>>>>>>> Can you set debug.verbose to "annoying" and send me the output
>>>>>>>>>>>> of your matplotlib run? I want to rule out any font-loading
>>>>>>>>>>>> problems.
>>>>>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>>>>>>>> gcc-4.2.2, in case its relevent.
>>>>>>>>>> Always good to have more details, but I'm sort of at a loss on
>>>>>>>>>> this one, especially since I can't reproduce it.
>>>>>>>>>>
>>>>>>>>>> Maybe we need to take a poll on this list of who is working and
>>>>>>>>>> who isn't to see what the source of the breakage may be...
>>>>>>>>>>
>>>>>>>>>> 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-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I should also mention -- please let me know if setting BROKEN to 0 fixes 
any rendering problems.
Cheers,
Mike
Michael Droettboom wrote:
> Forgot to attach the program.
> 
> Michael Droettboom wrote:
>> Nicolas, Darren,
>>
>> I have created a minimal program that hopefully will exercise the 
>> problem. If it breaks for either of you, I'll take this to the 
>> freetype mailing list for further clarification... If it doesn't 
>> break for you, my theory about the cause is still incorrect.
>>
>> I have attached a small C program. You can build it as follows, 
>> assuming freetype is installed in the usual place:
>>
>> gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o 
>> test_hinting_stretch
>>
>> Then you can run it by providing a .ttf fontname on the path. The one 
>> that seems to trip up so far is 
>> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source 
>> tree), but I'm curious to know if it also breaks for other more 
>> popular fonts like vera.ttf.
>>
>> ./test_hinting_stretch path_to_font
>>
>> It will render and print out all the glyphs in the font on stdout. 
>> Please send me the output (offlist, since it will be quite long).
>>
>> Thanks for helping me solve this problem,
>> Mike
>>
>> hu...@ya... wrote:
>>> I tried to change the value and the highest one I can use is 2 so 
>>> it's not a big improvement for what I understand.
>>>
>>> You can contact me if you need other test naturally
>>>
>>> N.
>>>
>>> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez écrit :
>>>> It's great to have narrowed this down! Unfortunately, with that 
>>>> #define
>>>> removed, you will get lower quality fonts (the hinting will be more
>>>> extreme, which causes the glyphs to often look too thin, or
>>>> inconsistent.) See this thread for more information --
>>>>
>>>> http://www.mail-archive.com/mat...@li.../msg01480 
>>>>
>>>> .html
>>>>
>>>> I'd hate to turn off this improvement because it doesn't work in some
>>>> environments.
>>>>
>>>> I wonder if you wouldn't mind performing one more experiment... There
>>>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
>>>> controls the amount of hinting subsampling. Currently it is set to 8,
>>>> but I wonder if a lower value would work. Ideally, we want to set this
>>>> as high as we can get away with.
>>>>
>>>> #define VERTICAL_HINTING
>>>> #ifdef VERTICAL_HINTING
>>>> #define HORIZ_HINTING 8
>>>> #else
>>>> #define HORIZ_HINTING 1
>>>> #endif
>>>>
>>>> Would you mind trying other values and seeing if any work? If not, 
>>>> I'll
>>>> probably take this question to the freetype mailing list now that we've
>>>> narrowed the cause down to only a three line difference in the code.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> hu...@ya... wrote:
>>>>> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>>>>>> Thanks for this information. It looks like the font outline data is
>>>>>> somehow getting corrupted before freetype renders it. Again, 
>>>>>> however, I
>>>>>> can't reproduce it on my machine (I've attached a copy of what it 
>>>>>> looks
>>>>>> like for me), so I'm still pretty stumped. My suspicion is that 
>>>>>> it's a
>>>>>> 64-bit vs. 32-bit problem since both people known to have trouble 
>>>>>> are on
>>>>>> 64-bit platforms, and I am not. I have tried recompiling with 
>>>>>> gcc-4.2.2
>>>>>> and I still wasn't able to reproduce.
>>>>> I can imagine that it's difficult for you to debug something you 
>>>>> cannot
>>>>> reproduce. Just a remark I don't have 64-bits but a 32 so the 
>>>>> problem is
>>>>> not comming because of the plateforme.
>>>>>
>>>>>> One thing you could *try*, to rule out any recent changes to the 
>>>>>> glyph
>>>>>> rendering, is to comment out this line near the top of 
>>>>>> src/ft2font.cpp:
>>>>>>
>>>>>> #define VERTICAL_HINTING
>>>>>>
>>>>>> as follows
>>>>>>
>>>>>> //#define VERTICAL_HINTING
>>>>> Yes it's doing the trick., I don't have anymore the problem. Thank you
>>>>> very much. I have now the same result than you with the test I produce
>>>>> before.
>>>>>
>>>>>> Additional information: Are there any warnings produced when 
>>>>>> compiling
>>>>>> ft2font.cpp? Can you send me your matplotlibrc file?
>>>>> just the classic one:
>>>>>
>>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is 
>>>>> valid for
>>>>> Ada/C/ObjC but not for C++
>>>>>
>>>>> Thank you very much.
>>>>>
>>>>> N.
>>>>>
>>>>>> Cheers,
>>>>>> Mike
>>>>>>
>>>>>> hu...@ya... wrote:
>>>>>>> Yep that can be a good idea. I don't know anything on how 
>>>>>>> mathtext is
>>>>>>> working but I'm not completely sure that the problem is with 
>>>>>>> freetype
>>>>>>> because sometime that can work. In reality every character I tested
>>>>>>> worked but you have to put in a certain order. To understand a 
>>>>>>> little
>>>>>>> bit more what I try to say (very badly) see the script join and the
>>>>>>> figure.
>>>>>>>
>>>>>>> I hope that can help a little bit to try to find the reason of this
>>>>>>> behaviour.
>>>>>>>
>>>>>>> N
>>>>>>>
>>>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez 
>>> écrit :
>>>>>>>> Darren Dale wrote:
>>>>>>>>> Hi Mike,
>>>>>>>>>
>>>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>>>>>> Unfortunately, I can't reproduce this on my machine even with the
>>>>>>>>>> latest stable version of freetype-2.5.3 (which is the same 
>>>>>>>>>> version
>>>>>>>>>> in Ubuntu Gutsy).
>>>>>>>>> I think you mean freetype-2.3.5. I also have that version 
>>>>>>>>> installed,
>>>>>>>>> although the mpl setup script is reporting 9.16.3.
>>>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
>>>>>>>> fully comprehend why the pkgconfig version doesn't match the 
>>>>>>>> release
>>>>>>>> version (and why freetype2 is called freetype6 on Debian and
>>>>>>>> derivatives)... but my numbers do match yours.
>>>>>>>>
>>>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>>>>>> applied, and I don't know if they are causing this (but from the
>>>>>>>>>> looks of them, I doubt it).
>>>>>>>>>>
>>>>>>>>>> Can you set debug.verbose to "annoying" and send me the output of
>>>>>>>>>> your matplotlib run? I want to rule out any font-loading 
>>>>>>>>>> problems.
>>>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>>>>>> gcc-4.2.2, in case its relevent.
>>>>>>>> Always good to have more details, but I'm sort of at a loss on this
>>>>>>>> one, especially since I can't reproduce it.
>>>>>>>>
>>>>>>>> Maybe we need to take a poll on this list of who is working and who
>>>>>>>> isn't to see what the source of the breakage may be...
>>>>>>>>
>>>>>>>> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Forgot to attach the program.
Michael Droettboom wrote:
> Nicolas, Darren,
> 
> I have created a minimal program that hopefully will exercise the 
> problem. If it breaks for either of you, I'll take this to the freetype 
> mailing list for further clarification... If it doesn't break for you, 
> my theory about the cause is still incorrect.
> 
> I have attached a small C program. You can build it as follows, 
> assuming freetype is installed in the usual place:
> 
> 	gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o 
> test_hinting_stretch
> 
> Then you can run it by providing a .ttf fontname on the path. The one 
> that seems to trip up so far is 
> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source 
> tree), but I'm curious to know if it also breaks for other more popular 
> fonts like vera.ttf.
> 
> 	./test_hinting_stretch path_to_font
> 
> It will render and print out all the glyphs in the font on stdout. 
> Please send me the output (offlist, since it will be quite long).
> 
> Thanks for helping me solve this problem,
> Mike
> 
> hu...@ya... wrote:
>> I tried to change the value and the highest one I can use is 2 so it's not a 
>> big improvement for what I understand.
>>
>> You can contact me if you need other test naturally
>>
>> N.
>>
>> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez écrit :
>>> It's great to have narrowed this down! Unfortunately, with that #define
>>> removed, you will get lower quality fonts (the hinting will be more
>>> extreme, which causes the glyphs to often look too thin, or
>>> inconsistent.) See this thread for more information --
>>>
>>> http://www.mail-archive.com/mat...@li.../msg01480
>>> .html
>>>
>>> I'd hate to turn off this improvement because it doesn't work in some
>>> environments.
>>>
>>> I wonder if you wouldn't mind performing one more experiment... There
>>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
>>> controls the amount of hinting subsampling. Currently it is set to 8,
>>> but I wonder if a lower value would work. Ideally, we want to set this
>>> as high as we can get away with.
>>>
>>> #define VERTICAL_HINTING
>>> #ifdef VERTICAL_HINTING
>>> #define HORIZ_HINTING 8
>>> #else
>>> #define HORIZ_HINTING 1
>>> #endif
>>>
>>> Would you mind trying other values and seeing if any work? If not, I'll
>>> probably take this question to the freetype mailing list now that we've
>>> narrowed the cause down to only a three line difference in the code.
>>>
>>> Cheers,
>>> Mike
>>>
>>> hu...@ya... wrote:
>>>> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>>>>> Thanks for this information. It looks like the font outline data is
>>>>> somehow getting corrupted before freetype renders it. Again, however, I
>>>>> can't reproduce it on my machine (I've attached a copy of what it looks
>>>>> like for me), so I'm still pretty stumped. My suspicion is that it's a
>>>>> 64-bit vs. 32-bit problem since both people known to have trouble are on
>>>>> 64-bit platforms, and I am not. I have tried recompiling with gcc-4.2.2
>>>>> and I still wasn't able to reproduce.
>>>> I can imagine that it's difficult for you to debug something you cannot
>>>> reproduce. Just a remark I don't have 64-bits but a 32 so the problem is
>>>> not comming because of the plateforme.
>>>>
>>>>> One thing you could *try*, to rule out any recent changes to the glyph
>>>>> rendering, is to comment out this line near the top of src/ft2font.cpp:
>>>>>
>>>>> #define VERTICAL_HINTING
>>>>>
>>>>> as follows
>>>>>
>>>>> //#define VERTICAL_HINTING
>>>> Yes it's doing the trick., I don't have anymore the problem. Thank you
>>>> very much. I have now the same result than you with the test I produce
>>>> before.
>>>>
>>>>> Additional information: Are there any warnings produced when compiling
>>>>> ft2font.cpp? Can you send me your matplotlibrc file?
>>>> just the classic one:
>>>>
>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
>>>> Ada/C/ObjC but not for C++
>>>>
>>>> Thank you very much.
>>>>
>>>> N.
>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>> hu...@ya... wrote:
>>>>>> Yep that can be a good idea. I don't know anything on how mathtext is
>>>>>> working but I'm not completely sure that the problem is with freetype
>>>>>> because sometime that can work. In reality every character I tested
>>>>>> worked but you have to put in a certain order. To understand a little
>>>>>> bit more what I try to say (very badly) see the script join and the
>>>>>> figure.
>>>>>>
>>>>>> I hope that can help a little bit to try to find the reason of this
>>>>>> behaviour.
>>>>>>
>>>>>> N
>>>>>>
>>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez 
>> écrit :
>>>>>>> Darren Dale wrote:
>>>>>>>> Hi Mike,
>>>>>>>>
>>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>>>>> Unfortunately, I can't reproduce this on my machine even with the
>>>>>>>>> latest stable version of freetype-2.5.3 (which is the same version
>>>>>>>>> in Ubuntu Gutsy).
>>>>>>>> I think you mean freetype-2.3.5. I also have that version installed,
>>>>>>>> although the mpl setup script is reporting 9.16.3.
>>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
>>>>>>> fully comprehend why the pkgconfig version doesn't match the release
>>>>>>> version (and why freetype2 is called freetype6 on Debian and
>>>>>>> derivatives)... but my numbers do match yours.
>>>>>>>
>>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>>>>> applied, and I don't know if they are causing this (but from the
>>>>>>>>> looks of them, I doubt it).
>>>>>>>>>
>>>>>>>>> Can you set debug.verbose to "annoying" and send me the output of
>>>>>>>>> your matplotlib run? I want to rule out any font-loading problems.
>>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>>>>> gcc-4.2.2, in case its relevent.
>>>>>>> Always good to have more details, but I'm sort of at a loss on this
>>>>>>> one, especially since I can't reproduce it.
>>>>>>>
>>>>>>> Maybe we need to take a poll on this list of who is working and who
>>>>>>> isn't to see what the source of the breakage may be...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mike
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> --
>>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Nicolas, Darren,
I have created a minimal program that hopefully will exercise the 
problem. If it breaks for either of you, I'll take this to the freetype 
mailing list for further clarification... If it doesn't break for you, 
my theory about the cause is still incorrect.
I have attached a small C program. You can build it as follows, 
assuming freetype is installed in the usual place:
	gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o 
test_hinting_stretch
Then you can run it by providing a .ttf fontname on the path. The one 
that seems to trip up so far is 
lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source 
tree), but I'm curious to know if it also breaks for other more popular 
fonts like vera.ttf.
	./test_hinting_stretch path_to_font
It will render and print out all the glyphs in the font on stdout. 
Please send me the output (offlist, since it will be quite long).
Thanks for helping me solve this problem,
Mike
hu...@ya... wrote:
> I tried to change the value and the highest one I can use is 2 so it's not a 
> big improvement for what I understand.
> 
> You can contact me if you need other test naturally
> 
> N.
> 
> Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez écrit :
>> It's great to have narrowed this down! Unfortunately, with that #define
>> removed, you will get lower quality fonts (the hinting will be more
>> extreme, which causes the glyphs to often look too thin, or
>> inconsistent.) See this thread for more information --
>>
>> http://www.mail-archive.com/mat...@li.../msg01480
>> .html
>>
>> I'd hate to turn off this improvement because it doesn't work in some
>> environments.
>>
>> I wonder if you wouldn't mind performing one more experiment... There
>> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
>> controls the amount of hinting subsampling. Currently it is set to 8,
>> but I wonder if a lower value would work. Ideally, we want to set this
>> as high as we can get away with.
>>
>> #define VERTICAL_HINTING
>> #ifdef VERTICAL_HINTING
>> #define HORIZ_HINTING 8
>> #else
>> #define HORIZ_HINTING 1
>> #endif
>>
>> Would you mind trying other values and seeing if any work? If not, I'll
>> probably take this question to the freetype mailing list now that we've
>> narrowed the cause down to only a three line difference in the code.
>>
>> Cheers,
>> Mike
>>
>> hu...@ya... wrote:
>>> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>>>> Thanks for this information. It looks like the font outline data is
>>>> somehow getting corrupted before freetype renders it. Again, however, I
>>>> can't reproduce it on my machine (I've attached a copy of what it looks
>>>> like for me), so I'm still pretty stumped. My suspicion is that it's a
>>>> 64-bit vs. 32-bit problem since both people known to have trouble are on
>>>> 64-bit platforms, and I am not. I have tried recompiling with gcc-4.2.2
>>>> and I still wasn't able to reproduce.
>>> I can imagine that it's difficult for you to debug something you cannot
>>> reproduce. Just a remark I don't have 64-bits but a 32 so the problem is
>>> not comming because of the plateforme.
>>>
>>>> One thing you could *try*, to rule out any recent changes to the glyph
>>>> rendering, is to comment out this line near the top of src/ft2font.cpp:
>>>>
>>>> #define VERTICAL_HINTING
>>>>
>>>> as follows
>>>>
>>>> //#define VERTICAL_HINTING
>>> Yes it's doing the trick., I don't have anymore the problem. Thank you
>>> very much. I have now the same result than you with the test I produce
>>> before.
>>>
>>>> Additional information: Are there any warnings produced when compiling
>>>> ft2font.cpp? Can you send me your matplotlibrc file?
>>> just the classic one:
>>>
>>> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
>>> Ada/C/ObjC but not for C++
>>>
>>> Thank you very much.
>>>
>>> N.
>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> hu...@ya... wrote:
>>>>> Yep that can be a good idea. I don't know anything on how mathtext is
>>>>> working but I'm not completely sure that the problem is with freetype
>>>>> because sometime that can work. In reality every character I tested
>>>>> worked but you have to put in a certain order. To understand a little
>>>>> bit more what I try to say (very badly) see the script join and the
>>>>> figure.
>>>>>
>>>>> I hope that can help a little bit to try to find the reason of this
>>>>> behaviour.
>>>>>
>>>>> N
>>>>>
>>>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez 
> écrit :
>>>>>> Darren Dale wrote:
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>>>> Unfortunately, I can't reproduce this on my machine even with the
>>>>>>>> latest stable version of freetype-2.5.3 (which is the same version
>>>>>>>> in Ubuntu Gutsy).
>>>>>>> I think you mean freetype-2.3.5. I also have that version installed,
>>>>>>> although the mpl setup script is reporting 9.16.3.
>>>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
>>>>>> fully comprehend why the pkgconfig version doesn't match the release
>>>>>> version (and why freetype2 is called freetype6 on Debian and
>>>>>> derivatives)... but my numbers do match yours.
>>>>>>
>>>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>>>> applied, and I don't know if they are causing this (but from the
>>>>>>>> looks of them, I doubt it).
>>>>>>>>
>>>>>>>> Can you set debug.verbose to "annoying" and send me the output of
>>>>>>>> your matplotlib run? I want to rule out any font-loading problems.
>>>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>>>> gcc-4.2.2, in case its relevent.
>>>>>> Always good to have more details, but I'm sort of at a loss on this
>>>>>> one, especially since I can't reproduce it.
>>>>>>
>>>>>> Maybe we need to take a poll on this list of who is working and who
>>>>>> isn't to see what the source of the breakage may be...
>>>>>>
>>>>>> Cheers,
>>>>>> Mike
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> --
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm using the AGG backend to output graphs as PNG files, but I have had 
users complain that the resulting files are too large (the images are 
being served via a web server).
The graphs are simple line graphs with less than 8 colours, so I'm 
trying to change src/_backend_agg.cpp to output a 4 bit per pixel PNG 
using PNG_COLOR_TYPE_PALETTE, rather than the default 
PNG_COLOR_TYPE_RGB_ALPHA. The code currently looks like this (the 
changes I have made have "PHB" in the comments):
src/_backend_agg.cpp, line 2077:
 // PHB inserted code start
 info_ptr->valid |= PNG_INFO_PLTE;
 info_ptr->palette = (png_color*)malloc(256 * sizeof (png_color));
 info_ptr->num_palette = 256;
 // PHB inserted code end
 if (setjmp(png_ptr->jmpbuf)) {
 if (fpclose) fclose(fp);
 png_destroy_write_struct(&png_ptr, &info_ptr);
 delete [] row_pointers;
 throw Py::RuntimeError("Error building image");
 }
 png_init_io(png_ptr, fp);
 png_set_IHDR(png_ptr, info_ptr,
 width, height, 4, // PHB Changed from 8 BPP
 PNG_COLOR_TYPE_PALETTE, PNG_INTERLACE_NONE, // PHB 
changed from PNG_COLOR_TYPE_RGB_ALPHA
 PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
 // this a a color image!
 sig_bit.gray = 0;
 sig_bit.red = 4; // PHB Changed from 8 to 4
 sig_bit.green = 4; // PHB Changed from 8 to 4
 sig_bit.blue = 4; // PHB Changed from 8 to 4
 /* if the image has an alpha channel then */
 sig_bit.alpha = 0; // PHB Changed from 8 to 0
This doesn't crash, but it outputs a stretched image - it looks like the 
pixels that make up the image have zero pixels in between. I've had a 
look through the libpng documentation here: 
http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-4.1 but 
there isn't a lot of detail about how to set up palettes, etc. Does 
anyone have any advice for me on how to get this working?
Cheers
Peter

I have not been able to reproduce this with some quick plots using 
ipython -pylab. Please provide the simplest complete script that 
illustrates it.
Eric
Chris wrote:
> In recent builds of matplotlib from SVN, when I create several plots in a row,
> each new figure ends up containing each of the previous plots, including the
> current one. Thus, the 1st plot would contain 1 series, the second 2 series,
> etc. This did not happen previously. I am calling figure() before each plot, so
> this should not be happening. I have even tried calling close() after each, but
> to no avail.
> 
> Any ideas?
> 
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

In recent builds of matplotlib from SVN, when I create several plots in a row,
each new figure ends up containing each of the previous plots, including the
current one. Thus, the 1st plot would contain 1 series, the second 2 series,
etc. This did not happen previously. I am calling figure() before each plot, so
this should not be happening. I have even tried calling close() after each, but
to no avail.
Any ideas?

When I switch to the GTKCairo backend, the alpha value no longer seems
to get passed when I use fill(). I looked at backend_cairo.py and I
believe this is because _fill_and_stroke always uses
ctx.set_source_rgb, instead of ctx.set_source_rgba.
I hacked backend_cairo.py to look at gc._alpha (I had to add gc as an
argument) and fill() with alpha works properly now.
 def _fill_and_stroke (self, gc, ctx, fill_c):
 #assert fill_c or stroke_c
 #_.ctx.save()
 if fill_c:
 ctx.save()
 if gc._alpha is not None:
 ctx.set_source_rgba (fill_c[0], fill_c[1], fill_c[2], gc._alpha)
 else:
 ctx.set_source_rgb (*fill_c)

I tried to change the value and the highest one I can use is 2 so it's not =
a=20
big improvement for what I understand.
You can contact me if you need other test naturally
N.
Le Friday 26 October 2007 12:24:34 Michael Droettboom, vous avez =C3=A9crit=
=C2=A0:
> It's great to have narrowed this down! Unfortunately, with that #define
> removed, you will get lower quality fonts (the hinting will be more
> extreme, which causes the glyphs to often look too thin, or
> inconsistent.) See this thread for more information --
>
> http://www.mail-archive.com/mat...@li.../msg014=
80
>.html
>
> I'd hate to turn off this improvement because it doesn't work in some
> environments.
>
> I wonder if you wouldn't mind performing one more experiment... There
> is another define at the top of ft2font.cpp, "HORIZ_HINTING" that
> controls the amount of hinting subsampling. Currently it is set to 8,
> but I wonder if a lower value would work. Ideally, we want to set this
> as high as we can get away with.
>
> #define VERTICAL_HINTING
> #ifdef VERTICAL_HINTING
> #define HORIZ_HINTING 8
> #else
> #define HORIZ_HINTING 1
> #endif
>
> Would you mind trying other values and seeing if any work? If not, I'll
> probably take this question to the freetype mailing list now that we've
> narrowed the cause down to only a three line difference in the code.
>
> Cheers,
> Mike
>
> hu...@ya... wrote:
> > Le Friday 26 October 2007 11:22:06, vous avez =C3=A9crit :
> >> Thanks for this information. It looks like the font outline data is
> >> somehow getting corrupted before freetype renders it. Again, however,=
 I
> >> can't reproduce it on my machine (I've attached a copy of what it looks
> >> like for me), so I'm still pretty stumped. My suspicion is that it's a
> >> 64-bit vs. 32-bit problem since both people known to have trouble are =
on
> >> 64-bit platforms, and I am not. I have tried recompiling with gcc-4.2=
=2E2
> >> and I still wasn't able to reproduce.
> >
> > I can imagine that it's difficult for you to debug something you cannot
> > reproduce. Just a remark I don't have 64-bits but a 32 so the problem is
> > not comming because of the plateforme.
> >
> >> One thing you could *try*, to rule out any recent changes to the glyph
> >> rendering, is to comment out this line near the top of src/ft2font.cpp:
> >>
> >> #define VERTICAL_HINTING
> >>
> >> as follows
> >>
> >> //#define VERTICAL_HINTING
> >
> > Yes it's doing the trick., I don't have anymore the problem. Thank you
> > very much. I have now the same result than you with the test I produce
> > before.
> >
> >> Additional information: Are there any warnings produced when compiling
> >> ft2font.cpp? Can you send me your matplotlibrc file?
> >
> > just the classic one:
> >
> > cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
> > Ada/C/ObjC but not for C++
> >
> > Thank you very much.
> >
> > N.
> >
> >> Cheers,
> >> Mike
> >>
> >> hu...@ya... wrote:
> >>> Yep that can be a good idea. I don't know anything on how mathtext is
> >>> working but I'm not completely sure that the problem is with freetype
> >>> because sometime that can work. In reality every character I tested
> >>> worked but you have to put in a certain order. To understand a little
> >>> bit more what I try to say (very badly) see the script join and the
> >>> figure.
> >>>
> >>> I hope that can help a little bit to try to find the reason of this
> >>> behaviour.
> >>>
> >>> N
> >>>
> >>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez=20
=C3=A9crit :
> >>>> Darren Dale wrote:
> >>>>> Hi Mike,
> >>>>>
> >>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
> >>>>>> Unfortunately, I can't reproduce this on my machine even with the
> >>>>>> latest stable version of freetype-2.5.3 (which is the same version
> >>>>>> in Ubuntu Gutsy).
> >>>>>
> >>>>> I think you mean freetype-2.3.5. I also have that version installed,
> >>>>> although the mpl setup script is reporting 9.16.3.
> >>>>
> >>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't
> >>>> fully comprehend why the pkgconfig version doesn't match the release
> >>>> version (and why freetype2 is called freetype6 on Debian and
> >>>> derivatives)... but my numbers do match yours.
> >>>>
> >>>>>> The Ubuntu/Debian package of freetype has a lot of patches
> >>>>>> applied, and I don't know if they are causing this (but from the
> >>>>>> looks of them, I doubt it).
> >>>>>>
> >>>>>> Can you set debug.verbose to "annoying" and send me the output of
> >>>>>> your matplotlib run? I want to rule out any font-loading problems.
> >>>>>
> >>>>> It's attached. I'm running 64bit gentoo, everything compiled with
> >>>>> gcc-4.2.2, in case its relevent.
> >>>>
> >>>> Always good to have more details, but I'm sort of at a loss on this
> >>>> one, especially since I can't reproduce it.
> >>>>
> >>>> Maybe we need to take a poll on this list of who is working and who
> >>>> isn't to see what the source of the breakage may be...
> >>>>
> >>>> Cheers,
> >>>> Mike
> >>>>
> >>>> --------------------------------------------------------------------=
=2D-
> >>>>--

It's great to have narrowed this down! Unfortunately, with that #define 
removed, you will get lower quality fonts (the hinting will be more 
extreme, which causes the glyphs to often look too thin, or 
inconsistent.) See this thread for more information --
http://www.mail-archive.com/mat...@li.../msg01480.html
I'd hate to turn off this improvement because it doesn't work in some 
environments.
I wonder if you wouldn't mind performing one more experiment... There 
is another define at the top of ft2font.cpp, "HORIZ_HINTING" that 
controls the amount of hinting subsampling. Currently it is set to 8, 
but I wonder if a lower value would work. Ideally, we want to set this 
as high as we can get away with.
#define VERTICAL_HINTING
#ifdef VERTICAL_HINTING
#define HORIZ_HINTING 8
#else
#define HORIZ_HINTING 1
#endif
Would you mind trying other values and seeing if any work? If not, I'll 
probably take this question to the freetype mailing list now that we've 
narrowed the cause down to only a three line difference in the code.
Cheers,
Mike
hu...@ya... wrote:
> Le Friday 26 October 2007 11:22:06, vous avez écrit :
>> Thanks for this information. It looks like the font outline data is
>> somehow getting corrupted before freetype renders it. Again, however, I
>> can't reproduce it on my machine (I've attached a copy of what it looks
>> like for me), so I'm still pretty stumped. My suspicion is that it's a
>> 64-bit vs. 32-bit problem since both people known to have trouble are on
>> 64-bit platforms, and I am not. I have tried recompiling with gcc-4.2.2
>> and I still wasn't able to reproduce.
> 
> I can imagine that it's difficult for you to debug something you cannot 
> reproduce. Just a remark I don't have 64-bits but a 32 so the problem is not 
> comming because of the plateforme.
> 
>> One thing you could *try*, to rule out any recent changes to the glyph
>> rendering, is to comment out this line near the top of src/ft2font.cpp:
>>
>> #define VERTICAL_HINTING
>>
>> as follows
>>
>> //#define VERTICAL_HINTING
> 
> Yes it's doing the trick., I don't have anymore the problem. Thank you very 
> much. I have now the same result than you with the test I produce before.
> 
>> Additional information: Are there any warnings produced when compiling
>> ft2font.cpp? Can you send me your matplotlibrc file?
> 
> just the classic one:
> 
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
> Ada/C/ObjC but not for C++
> 
> Thank you very much.
> 
> N.
> 
>> Cheers,
>> Mike
>>
>> hu...@ya... wrote:
>>> Yep that can be a good idea. I don't know anything on how mathtext is
>>> working but I'm not completely sure that the problem is with freetype
>>> because sometime that can work. In reality every character I tested
>>> worked but you have to put in a certain order. To understand a little bit
>>> more what I try to say (very badly) see the script join and the figure.
>>>
>>> I hope that can help a little bit to try to find the reason of this
>>> behaviour.
>>>
>>> N
>>>
>>> Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez écrit :
>>>> Darren Dale wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:
>>>>>> Unfortunately, I can't reproduce this on my machine even with the
>>>>>> latest stable version of freetype-2.5.3 (which is the same version in
>>>>>> Ubuntu Gutsy).
>>>>> I think you mean freetype-2.3.5. I also have that version installed,
>>>>> although the mpl setup script is reporting 9.16.3.
>>>> Yes. freetype-2.3.5. There are arcane historical reasons I don't fully
>>>> comprehend why the pkgconfig version doesn't match the release version
>>>> (and why freetype2 is called freetype6 on Debian and derivatives)...
>>>> but my numbers do match yours.
>>>>
>>>>>> The Ubuntu/Debian package of freetype has a lot of patches
>>>>>> applied, and I don't know if they are causing this (but from the looks
>>>>>> of them, I doubt it).
>>>>>>
>>>>>> Can you set debug.verbose to "annoying" and send me the output of your
>>>>>> matplotlib run? I want to rule out any font-loading problems.
>>>>> It's attached. I'm running 64bit gentoo, everything compiled with
>>>>> gcc-4.2.2, in case its relevent.
>>>> Always good to have more details, but I'm sort of at a loss on this one,
>>>> especially since I can't reproduce it.
>>>>
>>>> Maybe we need to take a poll on this list of who is working and who
>>>> isn't to see what the source of the breakage may be...
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> ------------------------------------------------------------------------
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA