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
[EMAIL PROTECTED] 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/[EMAIL PROTECTED]/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
>>
>> [EMAIL PROTECTED] 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
>>>>
>>>> [EMAIL PROTECTED] 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
-------------------------------------------------------------------------
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
