Michael Droettboom wrote: > Darren Dale wrote: >> I think the problem is related to autohinting. When I compile freetype, the >> patented bytecode and subpixel hinting support is disabled, I am using >> freetype's autohinting instead. I recompiled freetype with the support for >> the patented hinting instead of autohinting, and reran the test on cmmi.ttf. >> The result is cmmi10_p.txt. > > That seems like a likely explanation... Exactly, which #defines did you > change to make it work again? The vanilla freetype tarball works for me...
I seem to have the reversed behavior. On my machine, if I have the patented bytecodes disabled (which is the default when you download the vanilla freetype tarball from freetype.sf.net), everything works. When I define (uncomment) TT_CONFIG_OPTION_BYTECODE_INTERPRETER in ftoption.h, things break. (And great news, I'm finally able to reproduce this problem.) Is that not what you see? Cheers, Mike >> On Monday 29 October 2007 08:57:42 am Michael Droettboom wrote: >>> I should also mention -- please let me know if setting BROKEN to 0 fixes >>> any rendering problems. >>> >>> Cheers, >>> Mike >>> >>> Michael Droettboom wrote: >>>> Forgot to attach the program. >>>> >>>> Michael Droettboom wrote: >>>>> Nicolas, Darren, >>>>> >>>>> I have created a minimal program that hopefully will exercise the >>>>> problem. If it breaks for either of you, I'll take this to the >>>>> freetype mailing list for further clarification... If it doesn't >>>>> break for you, my theory about the cause is still incorrect. >>>>> >>>>> I have attached a small C program. You can build it as follows, >>>>> assuming freetype is installed in the usual place: >>>>> >>>>> gcc -I/usr/include/freetype2 -lfreetype test_hinting_stretch.c -o >>>>> test_hinting_stretch >>>>> >>>>> Then you can run it by providing a .ttf fontname on the path. The one >>>>> that seems to trip up so far is >>>>> lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf (in the matplotlib source >>>>> tree), but I'm curious to know if it also breaks for other more >>>>> popular fonts like vera.ttf. >>>>> >>>>> ./test_hinting_stretch path_to_font >>>>> >>>>> It will render and print out all the glyphs in the font on stdout. >>>>> Please send me the output (offlist, since it will be quite long). >>>>> >>>>> Thanks for helping me solve this problem, >>>>> Mike >>>>> >>>>> [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]/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 >>>>>>> >>>>>>> [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 >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> ---- >>>>>>>>>>> >>>>>>>>>>> -- >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------- >>>> 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 ------------------------------------------------------------------------- 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
