matplotlib-devel Mailing List for matplotlib

I seem to have found a fix. The key point was this comment in 
pprdrv_tt2.cpp:
 else /* The tt spec. does not clearly indicate */
 { /* whether these values are signed or not. */
 arg1 = *(signed char *)(glyph++);
 arg2 = *(signed char *)(glyph++);
 }
By adding the cast to (signed char *), things seem to work. I guess 
that's what the spec does in practice! This doesn't seem to break Latin 
compound glyphs that used to work (the only thing that has been 
extensively tested up until now), so I'm pretty confident that's the 
correct fix. This has been fixed in SVN. Please try with more Korean 
characters and let me know if you still see anything strange.
Cheers,
Mike
Michael Droettboom wrote:
> Correction -- no need to send the image. You said png output was 
> correct, so I'll just compare against that.
>
> Michael Droettboom wrote:
> 
>> 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
>>> Mat...@li...
>>> 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

Correction -- no need to send the image. You said png output was 
correct, so I'll just compare against that.
Michael Droettboom wrote:
> 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
>> Mat...@li...
>> 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

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
> Mat...@li...
> 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

John Hunter wrote:
> The problem is with the image.AxesImage._rgbacache -- it is not being
> cleared with a set_clim or a set_cmap. I am going to commit a
> preliminary fix which simply resets this on any call to
> image.AxesImage.changed and if there is a better place to do the reset
> vis-a-vis the optimization you are trying to capture, please modify as
> necessary.
John,
As far as I can see, you found the right solution. I don't think it 
interferes in any way with the optimizations.
Thank you.
Eric
> 
> JDH

In the interest of simplifying/unifying the API for callbacks in mpl,
I ported the cm.ScalarMappable callback API to the
cbook.CallbackRegistry functionality which is what we use (on the
trunk) for the toolbar event handling and the Axes xlim/ylim
notification. At a minimum, all callbacks (with one exception that I
am aware of in widgets.py) in mpl are now handled with the
cbook.CallbackRegistry, which is a start. backend_driver.py is
passing as are a few interactive tests I tried, but make sure it looks
OK on your end.
JDH

On Tue, May 27, 2008 at 6:40 PM, Eric Firing <ef...@ha...> wrote:
> If I fouled it up--as evidently I did--I would like to fix it. I will
> take a first look at it this evening.
FYI, this bug is only exposed in interactive use since the caching is
triggered by the first draw.
The problem is with the image.AxesImage._rgbacache -- it is not being
cleared with a set_clim or a set_cmap. I am going to commit a
preliminary fix which simply resets this on any call to
image.AxesImage.changed and if there is a better place to do the reset
vis-a-vis the optimization you are trying to capture, please modify as
necessary.
JDH