Hi, I have a small problem with label. plot([0,1],[0,1]) xlabel(r'$ABCDEF$',fontsize=35) (but the size doesn't change anything) I obtain the result visible on the figure join. I think there are a problem when using latex and how the first character is handle. Thanks for matplotlib. N. PS: I'm using svn version: pylab.__version__ '1.0.4.dev4241'
On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote: > Hi, > > I have a small problem with label. > > > plot([0,1],[0,1]) > xlabel(r'$ABCDEF$',fontsize=35) > > (but the size doesn't change anything) I obtain the result visible on the > figure join. I think there are a problem when using latex and how the first > character is handle. I don't think its a problem with matplotlib; I can't reproduce the problem on my machine. Maybe its an issue with your dvipng? I'm using version 1.9.
I don't think the problem is in dvipng because I have exactly the same when= =20 I'm using GtkAgg and before your message I didn't have dvipng installed. I'= m=20 using ubuntu gutsy so perhaps there are a change in the lib. N.=20 Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez =E9crit=A0: > On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote: > > Hi, > > > > I have a small problem with label. > > > > > > plot([0,1],[0,1]) > > xlabel(r'$ABCDEF$',fontsize=3D35) > > > > (but the size doesn't change anything) I obtain the result visible on t= he > > figure join. I think there are a problem when using latex and how the > > first character is handle. > > I don't think its a problem with matplotlib; I can't reproduce the problem > on my machine. Maybe its an issue with your dvipng? I'm using version 1.9. > > ------------------------------------------------------------------------- > 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
Oups I found the problem, I don't know why because it was working fine befo=
re=20
the upgrade to gutsy but I have to change matplotlib configuration and=20
everything is working fine if I put in the file:
rc('text', usetex=3DTrue)
sorry to have bother you with this,
N.
Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez =E9crit=A0:
> On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
> > Hi,
> >
> > I have a small problem with label.
> >
> >
> > plot([0,1],[0,1])
> > xlabel(r'$ABCDEF$',fontsize=3D35)
> >
> > (but the size doesn't change anything) I obtain the result visible on t=
he
> > figure join. I think there are a problem when using latex and how the
> > first character is handle.
>
> I don't think its a problem with matplotlib; I can't reproduce the problem
> on my machine. Maybe its an issue with your dvipng? I'm using version 1.9.
>
> -------------------------------------------------------------------------
> 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 Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez =E9crit=A0:
> > On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
> > > Hi,
> > >
> > > I have a small problem with label.
> > >
> > >
> > > plot([0,1],[0,1])
> > > xlabel(r'$ABCDEF$',fontsize=3D35)
> > >
> > > (but the size doesn't change anything) I obtain the result visible on
> > > the figure join. I think there are a problem when using latex and how
> > > the first character is handle.
> >
> > I don't think its a problem with matplotlib; I can't reproduce the
> > problem on my machine. Maybe its an issue with your dvipng? I'm using
> > version 1.9.
> >
> Oups I found the problem, I don't know why because it was working fine
> before the upgrade to gutsy but I have to change matplotlib configuration
> and everything is working fine if I put in the file:
>
> rc('text', usetex=3DTrue)
In your first email you said you were using latex, but you were actually us=
ing=20
mathtext. I can confirm the problem when I disable usetex and instead use=20
mathtext. Mike, is this something easy to fix?
Darren
Sorry I didn't know the difference...
N.
Le Friday 19 October 2007 10:52:25 Darren Dale, vous avez =E9crit=A0:
> On Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
> > Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez =E9crit=A0:
> > > On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
> > > > Hi,
> > > >
> > > > I have a small problem with label.
> > > >
> > > >
> > > > plot([0,1],[0,1])
> > > > xlabel(r'$ABCDEF$',fontsize=3D35)
> > > >
> > > > (but the size doesn't change anything) I obtain the result visible =
on
> > > > the figure join. I think there are a problem when using latex and h=
ow
> > > > the first character is handle.
> > >
> > > I don't think its a problem with matplotlib; I can't reproduce the
> > > problem on my machine. Maybe its an issue with your dvipng? I'm using
> > > version 1.9.
> >
> > Oups I found the problem, I don't know why because it was working fine
> > before the upgrade to gutsy but I have to change matplotlib configurati=
on
> > and everything is working fine if I put in the file:
> >
> > rc('text', usetex=3DTrue)
>
> In your first email you said you were using latex, but you were actually
> using mathtext. I can confirm the problem when I disable usetex and inste=
ad
> use mathtext. Mike, is this something easy to fix?
>
> Darren
I can't reproduce this bug on my own machine with SVN head. I suspect
this is freetype2 related -- that's the library that actually performs
the rendering of the characters for the Agg backend. The fact the
humufr saw this after upgrading to Gutsy suggests there might have been
change to freetype that is now revealing possibly an incorrect usage
in matplotlib. Can you please send the version of freetype you are
using? (pkg-config --modversion freetype2)
My machine has the (fairly old) 2.1.9.
I'm going to try installing the latest freetype and see if I can
reproduce this bug.
[I believe this is an instance of the same bug that Darren sent me
off-list.]
Cheers,
Mike
hu...@ya... wrote:
> Sorry I didn't know the difference...
>
> N.
>
> Le Friday 19 October 2007 10:52:25 Darren Dale, vous avez écrit :
>> On Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
>>> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
>>>> On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
>>>>> Hi,
>>>>>
>>>>> I have a small problem with label.
>>>>>
>>>>>
>>>>> plot([0,1],[0,1])
>>>>> xlabel(r'$ABCDEF$',fontsize=35)
>>>>>
>>>>> (but the size doesn't change anything) I obtain the result visible on
>>>>> the figure join. I think there are a problem when using latex and how
>>>>> the first character is handle.
>>>> I don't think its a problem with matplotlib; I can't reproduce the
>>>> problem on my machine. Maybe its an issue with your dvipng? I'm using
>>>> version 1.9.
>>> Oups I found the problem, I don't know why because it was working fine
>>> before the upgrade to gutsy but I have to change matplotlib configuration
>>> and everything is working fine if I put in the file:
>>>
>>> rc('text', usetex=True)
>> In your first email you said you were using latex, but you were actually
>> using mathtext. I can confirm the problem when I disable usetex and instead
>> use mathtext. Mike, is this something easy to fix?
>>
>> Darren
>
> -------------------------------------------------------------------------
> 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
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). 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.
Cheers,
Mike
Michael Droettboom wrote:
> I can't reproduce this bug on my own machine with SVN head. I suspect
> this is freetype2 related -- that's the library that actually performs
> the rendering of the characters for the Agg backend. The fact the
> humufr saw this after upgrading to Gutsy suggests there might have been
> change to freetype that is now revealing possibly an incorrect usage
> in matplotlib. Can you please send the version of freetype you are
> using? (pkg-config --modversion freetype2)
>
> My machine has the (fairly old) 2.1.9.
>
> I'm going to try installing the latest freetype and see if I can
> reproduce this bug.
>
> [I believe this is an instance of the same bug that Darren sent me
> off-list.]
>
> Cheers,
> Mike
>
> hu...@ya... wrote:
>> Sorry I didn't know the difference...
>>
>> N.
>>
>> Le Friday 19 October 2007 10:52:25 Darren Dale, vous avez écrit :
>>> On Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
>>>> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
>>>>> On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a small problem with label.
>>>>>>
>>>>>>
>>>>>> plot([0,1],[0,1])
>>>>>> xlabel(r'$ABCDEF$',fontsize=35)
>>>>>>
>>>>>> (but the size doesn't change anything) I obtain the result visible on
>>>>>> the figure join. I think there are a problem when using latex and how
>>>>>> the first character is handle.
>>>>> I don't think its a problem with matplotlib; I can't reproduce the
>>>>> problem on my machine. Maybe its an issue with your dvipng? I'm using
>>>>> version 1.9.
>>>> Oups I found the problem, I don't know why because it was working fine
>>>> before the upgrade to gutsy but I have to change matplotlib configuration
>>>> and everything is working fine if I put in the file:
>>>>
>>>> rc('text', usetex=True)
>>> In your first email you said you were using latex, but you were actually
>>> using mathtext. I can confirm the problem when I disable usetex and instead
>>> use mathtext. Mike, is this something easy to fix?
>>>
>>> Darren
>> -------------------------------------------------------------------------
>> 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
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, althou=
gh=20
the mpl setup script is reporting 9.16.3.
> The Ubuntu/Debian package of freetype has a lot of patches=20
> 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=
,=20
in case its relevent.
Darren
> Michael Droettboom wrote:
> > I can't reproduce this bug on my own machine with SVN head. I suspect
> > this is freetype2 related -- that's the library that actually performs
> > the rendering of the characters for the Agg backend. The fact the
> > humufr saw this after upgrading to Gutsy suggests there might have been
> > change to freetype that is now revealing possibly an incorrect usage
> > in matplotlib. Can you please send the version of freetype you are
> > using? (pkg-config --modversion freetype2)
> >
> > My machine has the (fairly old) 2.1.9.
> >
> > I'm going to try installing the latest freetype and see if I can
> > reproduce this bug.
> >
> > [I believe this is an instance of the same bug that Darren sent me
> > off-list.]
> >
> > Cheers,
> > Mike
> >
> > hu...@ya... wrote:
> >> Sorry I didn't know the difference...
> >>
> >> N.
> >>
> >> Le Friday 19 October 2007 10:52:25 Darren Dale, vous avez =E9crit :
> >>> On Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
> >>>> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez =E9crit :
> >>>>> On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I have a small problem with label.
> >>>>>>
> >>>>>>
> >>>>>> plot([0,1],[0,1])
> >>>>>> xlabel(r'$ABCDEF$',fontsize=3D35)
> >>>>>>
> >>>>>> (but the size doesn't change anything) I obtain the result visible
> >>>>>> on the figure join. I think there are a problem when using latex a=
nd
> >>>>>> how the first character is handle.
> >>>>>
> >>>>> I don't think its a problem with matplotlib; I can't reproduce the
> >>>>> problem on my machine. Maybe its an issue with your dvipng? I'm usi=
ng
> >>>>> version 1.9.
> >>>>
> >>>> Oups I found the problem, I don't know why because it was working fi=
ne
> >>>> before the upgrade to gutsy but I have to change matplotlib
> >>>> configuration and everything is working fine if I put in the file:
> >>>>
> >>>> rc('text', usetex=3DTrue)
> >>>
> >>> In your first email you said you were using latex, but you were
> >>> actually using mathtext. I can confirm the problem when I disable
> >>> usetex and instead use mathtext. Mike, is this something easy to fix?
> >>>
> >>> Darren
> >>
> >> ----------------------------------------------------------------------=
=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
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 wrote:
>>> I can't reproduce this bug on my own machine with SVN head. I suspect
>>> this is freetype2 related -- that's the library that actually performs
>>> the rendering of the characters for the Agg backend. The fact the
>>> humufr saw this after upgrading to Gutsy suggests there might have been
>>> change to freetype that is now revealing possibly an incorrect usage
>>> in matplotlib. Can you please send the version of freetype you are
>>> using? (pkg-config --modversion freetype2)
>>>
>>> My machine has the (fairly old) 2.1.9.
>>>
>>> I'm going to try installing the latest freetype and see if I can
>>> reproduce this bug.
>>>
>>> [I believe this is an instance of the same bug that Darren sent me
>>> off-list.]
>>>
>>> Cheers,
>>> Mike
>>>
>>> hu...@ya... wrote:
>>>> Sorry I didn't know the difference...
>>>>
>>>> N.
>>>>
>>>> Le Friday 19 October 2007 10:52:25 Darren Dale, vous avez écrit :
>>>>> On Friday 19 October 2007 10:38:36 am hu...@ya... wrote:
>>>>>> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
>>>>>>> On Thursday 18 October 2007 11:49:50 am hu...@ya... wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have a small problem with label.
>>>>>>>>
>>>>>>>>
>>>>>>>> plot([0,1],[0,1])
>>>>>>>> xlabel(r'$ABCDEF$',fontsize=35)
>>>>>>>>
>>>>>>>> (but the size doesn't change anything) I obtain the result visible
>>>>>>>> on the figure join. I think there are a problem when using latex and
>>>>>>>> how the first character is handle.
>>>>>>> I don't think its a problem with matplotlib; I can't reproduce the
>>>>>>> problem on my machine. Maybe its an issue with your dvipng? I'm using
>>>>>>> version 1.9.
>>>>>> Oups I found the problem, I don't know why because it was working fine
>>>>>> before the upgrade to gutsy but I have to change matplotlib
>>>>>> configuration and everything is working fine if I put in the file:
>>>>>>
>>>>>> rc('text', usetex=True)
>>>>> In your first email you said you were using latex, but you were
>>>>> actually using mathtext. I can confirm the problem when I disable
>>>>> usetex and instead use mathtext. Mike, is this something easy to fix?
>>>>>
>>>>> Darren
>>>> ------------------------------------------------------------------------
>>>> - 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
Yep that can be a good idea. I don't know anything on how mathtext is worki= ng=20 but I'm not completely sure that the problem is with freetype because=20 sometime that can work. In reality every character I tested worked but you= =20 have to put in a certain order. To understand a little bit more what I try = to=20 say (very badly) see the script join and the figure.=20 =20 I hope that can help a little bit to try to find the reason of this behavio= ur. N Le Thursday 25 October 2007 15:41:40 Michael Droettboom, vous avez =C3=A9cr= it=C2=A0: > 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 late= st > >> 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
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. 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 Additional information: Are there any warnings produced when compiling ft2font.cpp? Can you send me your matplotlibrc file? 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
More information -- I just compiled matplotlib on a communal RHEL4 64-bit installation, and I still can not reproduce this bug there. The plot thickens... Cheers, Mike Michael Droettboom wrote: > 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. > > 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 > > Additional information: Are there any warnings produced when compiling > ft2font.cpp? Can you send me your matplotlibrc file? > > 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
Le Friday 26 October 2007 11:22:06, vous avez =E9crit=A0: > 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=20 reproduce. Just a remark I don't have 64-bits but a 32 so the problem is no= t=20 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= =20 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=20 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 b= it > > 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 =E9c= rit : > >> 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 ful= ly > >> 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 loo= ks > >>>> of them, I doubt it). > >>>> > >>>> Can you set debug.verbose to "annoying" and send me the output of yo= ur > >>>> 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 on= e, > >> 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
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- > >>>>--
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
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
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
[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
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
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
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
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
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