The code that generates the Type 3 fonts for us is fairly old (1995), and certainly predates the widespread adoption of Unicode, so I'm somewhat not surprised this doesn't work. I'll have a brief look to see if there are any obvious fixes, but we're unlikely to implement a full-fledged Unicode rendering system (like Pango) any time soon. Since I don't read Korean, can you provide an image file of what the resulting compound glyph is supposed to look like?
As a workaround, you could try using the Cairo backend to generate Postscript and PDF. It may do a better job. You could also try other Korean fonts -- they may not use compound glyph composition. Cheers, Mike Jae-Joon Lee wrote: > Hello, > > I wanted to render some Korean text in my matplotlib figure and this > is how I did (with python2.5 and trunk version of matplotlib). > > # -*- coding: utf-8 -*- > from pylab import * > > import matplotlib.font_manager as fm > fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf", size=100) > > plot([1,2,3]) > text(1.,1.5, u'이', fontproperties=fp) > savefig("test.eps") > show() > > > It works fine with GtkAgg (and saving to png file also). > But ps (fonttype=3) and pdf backends seem to render the characters > incorrectly. > Rendering with ps backends (fonttype=42) IS correct on the other hand. > See attached eps and pdf files. "test_correct.eps" is the correct one > made with ps fonttype=42. > "test_wrong.eps" is from fonttype=3. > > Just in case, my rc file contains > text.usetex : False > ps.useafm : False > > > If I use ps backend with fonttype=3 (the wrong one), the embedded font > in the output eps file for the above character is defined as follows. > > /uniC774{917 0 67 -2 833 678 _sc > gsave 0 343 translate > false CharStrings /cho12-1 get exec > grestore false CharStrings /jung21-1 get exec > }_d > > It is a composition of two glyphs (/cho12-1 and /jung21-1), and my > guess is the first glyph is somehow misplaced. If I manually change > the translation of the first glyph to something like (0, -150) instead > the current value of (0, 343), the output looks okay. > > I tried a few other Korean fonts but the results were similar. Some of > the glyphs are misplaced (in ps(type=3) and pdf backends). > Although I cannot rule out that the fonts I used have wrong font > information, but my inclination is this could be a bug in > "pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h). > > The translation of each glyphs seems to be handled by following code > (around line 594 of pprdrv_tt2.cpp). > > if( flags & ARGS_ARE_XY_VALUES ) > { > if( arg1 != 0 || arg2 != 0 ) > stream.printf("gsave %d %d translate\n", topost(arg1), > topost(arg2) ); > } > > It would be great if someone who is expert on this font issue can look > into this. > Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600 > for this particular glyph. > The later two are used inside "topost". > Regards, > > -JJ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel