bug or problem in my configuration

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'

image.png

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.

···

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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 the problem is in dvipng because I have exactly the same when
I'm using GtkAgg and before your message I didn't have dvipng installed. I'm
using ubuntu gutsy so perhaps there are a change in the lib.

N.

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :

···

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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.

-------------------------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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)

sorry to have bother you with this,

N.

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :

···

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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.

-------------------------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

···

On Friday 19 October 2007 10:38:36 am humufr@...136... wrote:

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
> On Thursday 18 October 2007 11:49:50 am humufr@...136... 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)

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 humufr@...136... wrote:
> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
> > On Thursday 18 October 2007 11:49:50 am humufr@...136... 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

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

humufr@...136... 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 humufr@...136... wrote:

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez �crit :

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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
Matplotlib-users@lists.sourceforge.net
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

humufr@...136... 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 humufr@...136... wrote:

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez �crit :

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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
Matplotlib-users@lists.sourceforge.net
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,

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.

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.

Darren

mathtext-debug.log (10.2 KB)

···

On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:

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
>
> humufr@...136... 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 humufr@...136... wrote:
>>>> Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :
>>>>> On Thursday 18 October 2007 11:49:50 am humufr@...136... 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
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

--
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

darren.dale@...163...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Darren Dale wrote:

Hi Mike,

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

···

On Tuesday 23 October 2007 09:05:56 am Michael Droettboom wrote:

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

humufr@...136... 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 humufr@...136... wrote:

Le Friday 19 October 2007 08:37:00 Darren Dale, vous avez écrit :

On Thursday 18 October 2007 11:49:50 am humufr@...136... 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
Matplotlib-users@lists.sourceforge.net
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 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 :

test_mathtext.png

test_mathtext.py (463 Bytes)

···

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

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

humufr@...136... wrote:

test_mathtext.png

···

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

humufr@...136... 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
Matplotlib-users@lists.sourceforge.net
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 é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.

matplotlibrc (12 KB)

···

Cheers,
Mike

humufr@...136... 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
>>
>> ------------------------------------------------------------------------

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/matplotlib-devel@lists.sourceforge.net/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

humufr@...136... 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

humufr@...136... 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
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/matplotlib-devel@lists.sourceforge.net/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

> 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
>>
>>> 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 :

···

humufr@...136... wrote:
>> humufr@...136... wrote:
>>>> 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
>>>>
>>>> ----------------------------------------------------------------------
>>>>--

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

humufr@...136... 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/matplotlib-devel@lists.sourceforge.net/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

humufr@...136... 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

humufr@...136... 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:

test_hinting_stretch.c (2.19 KB)

···

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

humufr@...136... 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/matplotlib-devel@lists.sourceforge.net/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

humufr@...136... 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

humufr@...136... 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

humufr@...136... 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/matplotlib-devel@lists.sourceforge.net/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

humufr@...136... 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

humufr@...136... 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
Matplotlib-users@lists.sourceforge.net
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. I
am posting again without the attachments.]

I attached the results (_b is with BROKEN = 0). I didn't notice any problems
in the Vera test, but in cmmi, Delta has problems when BROKEN is 1, it looks
better when BROKEN is 0.

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.

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
>>
>> humufr@...136... 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/matplotlib-devel@lists.sourceforge.net/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
>>>>
>>>> humufr@...136... 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
>>>>>>
>>>>>> humufr@...136... 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
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

--
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

darren.dale@...163...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu