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:
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 --
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.
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...
-------------------------------------------------------------------------
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/
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:
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 --
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.
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...
-------------------------------------------------------------------------
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/
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 "/#define1/ \{ 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 FreeType and Patents
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
···
On Monday 29 October 2007 10:09:21 am Michael Droettboom 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
···
On Monday 29 October 2007 10:09:21 am Michael Droettboom wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Works here, thank you very much for your hard work!
Darren
···
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.
Le Monday 29 October 2007 10:57:52 Darren Dale, vous avez écrit :
···
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
Oups I just come back and I was unable to do test but fortunatly Dave seem to
have been able to manage it, thank you. The fix is working here too, thank
you very much. Great work!
Andrew Straw and I taught a workshop at the Claremont Colleges this
weekend and I was running mpl from svn. When I brought up the 1st
figure in ipython -pylab mode running GTKAgg, the fonts were totally
whacked (see attached) and I was reminded of why they call it "the
bleeding edge". Fortunately, it only affected the first draw of an
ipython session. For example, a figure resize, which triggers the
draw, made the problem go away, and subsequent figures were fine.
Odd. I just updated from svn and it looks like the problem is gone on
that machine, so I hope this was the source of the problem (the
workshop machine was running open-suse)
In [2]: !uname -a
Linux ns3 2.6.18.8-0.5-bigsmp #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686
i686 i386 GNU/Linux
In other news, TkAgg is segfaulting in that environment, but I haven't
had time to track it down since I was busy preparing the course
material.
On 10/29/07, Michael Droettboom <mdroe@...86...> wrote:
I submitted a fix for this in matplotlib SVN r4047. Freetype takes a
FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode
hinter at runtime (even if it was compiled in). This appears to fix the
problem, and doesn't force people to recompile their freetype -- they
should now get identical results regardless.
I’d like to thank all those who participated in fixing this bug. It’s much appreciated.
David
2007/10/29, John Hunter <jdh2358@…287…
···
:
On 10/29/07, Michael Droettboom <mdroe@…86… > > wrote:
I submitted a fix for this in matplotlib SVN r4047. Freetype takes a
FT_LOAD_FORCE_AUTOHINT flag to force it to bypass the patented bytecode
hinter at runtime (even if it was compiled in). This appears to fix the
problem, and doesn’t force people to recompile their freetype – they
should now get identical results regardless.
Andrew Straw and I taught a workshop at the Claremont Colleges this
weekend and I was running mpl from svn. When I brought up the 1st
figure in ipython -pylab mode running GTKAgg, the fonts were totally
whacked (see attached) and I was reminded of why they call it “the
bleeding edge”. Fortunately, it only affected the first draw of an
ipython session. For example, a figure resize, which triggers the
draw, made the problem go away, and subsequent figures were fine.
Odd. I just updated from svn and it looks like the problem is gone on
that machine, so I hope this was the source of the problem (the
workshop machine was running open-suse)
In [2]: !uname -a
Linux ns3 2.6.18.8-0.5-bigsmp #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686
i686 i386 GNU/Linux
In other news, TkAgg is segfaulting in that environment, but I haven’t
had time to track it down since I was busy preparing the course
material.
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/
