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/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
I'd like to thank all those who participated in fixing this bug. It's much appreciated. David 2007年10月29日, John Hunter <jd...@gm...>: > > 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 > > ------------------------------------------------------------------------- > 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 > > >