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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
