Hi, After a lot of head-scratching, I figured out that I need to set an appropriate charmap when fonts are loaded. Well, as a matter of fact, I even didn't know if fonts can have multiple charmaps.
Anyhow, I just committed a patch that I think fix the issue. Please update your mpl and see if it works. Regards, -JJ On Thu, Nov 5, 2009 at 9:18 AM, tcb <thecolourblu...@gmail.com> wrote: > Hi, > > That's ok- let me know if there's anything I can help with. I can't see what > textpath.py is doing any different on mac or linux, and it seems to find the > right glyph code- but I suspect freetype on the mac is passing back the > wrong glyph. So it would seem to point to a freetype problem, or a font > problem, and specific to the mac. > > I did install the latest amsfonts but the bug was still there. > > tcb > > On Wed, Nov 4, 2009 at 2:32 PM, Jae-Joon Lee <lee.j.j...@gmail.com> wrote: >> >> It seems that this could be bug in textpath.py that picks up wrong >> glyph. Unfortunately, I cannot spend much time on this until the end >> of this week. >> >> As a matter of fact, I'm far from an expert on this issue. While I >> wrote the textpaht.py, the code is largely based on the code in the >> pdf_backend and svg_backend. So, I hope someone who is more >> knowledgeable than me step in. >> >> On the other hand, it seems that some glyph-name related bug has >> recently fixed in the amsfont. And, this might be related to the >> current issue. >> >> http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README >> >> I'm not sure what version of amsfont you're using but, can you try to >> update them to newest 3.0.2 version? And see if that makes any change? >> >> I'll try to look into this later this week. >> Regards, >> >> -JJ >> >> >> >> >> On Tue, Nov 3, 2009 at 10:26 PM, tcb <thecolourblu...@gmail.com> wrote: >> > hi, >> > >> > i took a quick look at what is going on here- but I have still not quite >> > found the problem. From tracing things back into the ft2font code, it >> > seems >> > that the wrong glyph index is getting passed in or used somewhere. I put >> > this debugging code into ft2font.cpp in "FT2Font::load_glyph" >> > >> > #define MAX_LEN 1024 >> > unsigned char bf[MAX_LEN]; >> > FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN); >> > std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ << >> > " " >> > << glyph_index << " " >> > << num << " " >> > << face->family_name << " " >> > << face->style_name << " " >> > << FT_Get_Postscript_Name(face) << " " >> > << "[ " << bf << " ]" >> > << std::endl; >> > >> > I modified your example demo_text_path2.py to just load the single >> > symbol >> > '\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' - >> > and >> > the output I get is this from the command line: >> > >> > FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium >> > CMMI12 >> > [ xi ] >> > >> > so, it seems to pick the correct font but the wrong glyph name (xi >> > instead >> > of pi)- I am not sure what the index should be. What gets displayed is >> > the >> > '\xi' symbol- you can see from the first output I sent that '\pi' has >> > been >> > replaced by '\xi' - the indexes of all the symbols are just offset by >> > one, I >> > think. >> > >> > If the correct glyph index is being passed to ft2font, then it could >> > very >> > well be a problem with freetype. >> > >> > regards >> > >> > >> > On Tue, Nov 3, 2009 at 6:19 PM, tcb <thecolourblu...@gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> Yes, with the pdfbackend, and using just the plain text code (with >> >> usetex=True), the correct output is produced (for Text but not >> >> TextPath). I >> >> modified your demo_text_path2.py to draw with text, and attached the >> >> output. >> >> >> >> This is the terminal output from running your attached code. I am using >> >> the texlive 2009 distribution- which appears to be working fine, I have >> >> not >> >> noticed any problems at all. What is the difference between the bluesky >> >> and >> >> amsfonts? >> >> >> >> texname, type1name, enc, char_id >> >> cmex10 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb >> >> None CMEX10-34 >> >> cmsy10 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb >> >> None CMSY10-49 >> >> cmex10 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb >> >> None CMEX10-88 >> >> cmmi12 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb >> >> None CMMI12-110 >> >> cmr17 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMR17-61 >> >> cmr17 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMR17-49 >> >> cmsy10 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMSY10-0 >> >> cmmi12 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMMI12-101 >> >> cmmi12 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMMI12-105 >> >> cmmi12 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMMI12-25 >> >> cmr17 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMR17-50 >> >> cmmi12 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMMI12-110 >> >> cmex10 >> >> >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb >> >> None CMEX10-35 >> >> phvr8r >> >> /usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb >> >> /usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc >> >> Nimbus%20Sans%20L%20Regular-2 >> >> >> >> regards, >> >> >> >> >> >> On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee.j.j...@gmail.com> >> >> wrote: >> >>> >> >>> On Tue, Nov 3, 2009 at 4:23 AM, tcb <thecolourblu...@gmail.com> wrote: >> >>> > and if I convert the dvi with dvipng, it all seems in order >> >>> > (demo_text_path_tex.png). I haven't looked closely into how the >> >>> > textpath >> >>> > stuff works, but I thought it would read the dvi as a path, and >> >>> > display >> >>> > that >> >>> > on the screen- if that is correct then I dont know how it ends up >> >>> > displaying >> >>> > a different symbol from what is in the dvi file. >> >>> >> >>> Well, dvi files only contains the name of the tex font. What textpath >> >>> does is to pick up corresponding type I font and convert them to path >> >>> using the freetype library (as far as I know, this is what dvipng and >> >>> matplotlib pdf backend does). So, my guess is that, textpath is >> >>> somehow picking up wrong fonts, or wrong glyphs. >> >>> >> >>> The code works fine at least in my mac os X tiger w/ texlive 2008, and >> >>> in ubuntu with texlive 2007. >> >>> As I don't have any access to mac os X 10.6, it would be hard to track >> >>> down what is wrong. Here are a few more test I wish you to run. >> >>> >> >>> *) Check if pdf backend produces a correct result. Do not use textpath >> >>> example, but simply use text command with usetex=True, and see if the >> >>> pdf output is okay. FWIW, the textpath code is largely borrowed from >> >>> the pdfbackend. >> >>> >> >>> *) Run the attached code, and post the terminal output. The output is >> >>> basically the name of the tex font and the name of the substituted >> >>> type1 font, etc. For your reference, here is my output. >> >>> >> >>> texname, type1name, enc, char_id >> >>> cmex10 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb >> >>> None CMEX10-34 >> >>> cmsy10 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb >> >>> None CMSY10-49 >> >>> cmex10 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb >> >>> None CMEX10-88 >> >>> cmmi12 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb >> >>> None CMMI12-110 >> >>> cmr17 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMR17-61 >> >>> cmr17 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMR17-49 >> >>> cmsy10 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMSY10-0 >> >>> cmmi12 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMMI12-101 >> >>> cmmi12 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMMI12-105 >> >>> cmmi12 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMMI12-25 >> >>> cmr17 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMR17-50 >> >>> cmmi12 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMMI12-110 >> >>> cmex10 >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb >> >>> None CMEX10-35 >> >>> pncr8r >> >>> /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb >> >>> /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc >> >>> Century%20Schoolbook%20L%20Roman-232 >> >>> >> >>> Regards, >> >>> >> >>> -JJ >> >> >> > >> > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
