Re: [matplotlib-devel] some funny behavior on the trunk
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] incorrectly rendered unicode (korean) character in ps (fonttype=3) and pdf backend
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/vse012070mrt/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/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] incorrectly rendered unicode (korean) character in ps (fonttype=3) and pdf backend
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/vse012070mrt/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/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] incorrectly rendered unicode (korean) character in ps (fonttype=3) and pdf backend
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/vse012070mrt/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
---
Re: [matplotlib-devel] new release?
Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? - Charlie On Wed, May 7, 2008 at 11:07 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > > What do people think of releasing 0.98 after numpy 1.1 is released this > weekend? > > The main reason I'd like to do this (instead of releasing another > 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is > installed as an egg basemap (or any other toolkit) cannot be installed. > > -Jeff > > -- > Jeffrey S. Whitaker Phone : (303)497-6313 > Meteorologist FAX: (303)497-6449 > NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] > 325 BroadwayOffice : Skaggs Research Cntr 1D-124 > Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Should we still proceed with this now that numpy 1.1.0 is out? Any holdups? I've done a fair amount of testing on the branch (0.91.3), particularly looking at all the PDF and SVG output from backend driver, and these backends are in the best shape I've ever seen them. I don't use these backends in my daily work, so haven't fully appreciated all the incremental progress that has been made. They are both now fully feature compliant, which is amazing to me (thanks to Mike and Jouni and everyone who did all the nitty gritty work here). I did notice a bug in SVG and PS for the first time, where the polar lines are not clipped to the polygon axes background ( I filed it at http://sourceforge.net/tracker/index.php?func=detail&aid=1977271&group_id=80706&atid=560720). I think we should take a crack at fixing these since the branch is otherwise in such good shape that we could perhaps go a long time w/o another maintenance release. On the trunk (0.98), the bug I am most concerned with is http://sourceforge.net/tracker/index.php?func=detail&aid=1976887&group_id=80706&atid=560720 . I find these jaggedy fonts in rotated text particularly grating, so I want to track this one down. So let's focus on clearing these bugs (and anything else the other devs raise), hopefully in the next couple days, and then push out the maintenance release followed by the pre-release of the branch. I'll also work on getting the site docs ready to go. On the issue of numpy 1.1: I am still not clear if our old binaries are broken. This came up in another thread on OS-X. If our binaries are broken with numpy 1.1 we need to move with a release ASAP, and these comparatively minor bugs should not hold us up. If they are not, I prefer to take a day or two and try and clear the above bugs first. I tested the mpl 0.91.2 win32 exe installer with the numpy 1.1 exe installer and had no troubles. Is the situation on OS-X different? Please advise. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] incorrectly rendered unicode (korean) character in ps (fonttype=3) and pdf backend
Hi Mike,
Yes, it is correct now.
I tried bunch of Korean characters and fonts and they were all fine.
Thanks a lot!
Unfortunately, there's an other problem. Although the glyphs are
rendered at correct location, some of the characters are still
incorrect (pdf backends is fine only ps output is wrong).
I'm attaching pdf one (correct) and ps one (incorrect). You will
easily notice what's wrong.
When a single glyph is consisted of overlapping closed paths, current
ps font definition does not fill those overlapping regions (the source
code has a comment that it assumes the paths are detached.).
In the output font definition, paths are filled with "eofill" command.
If I replace "eofill" with simple "fill" (line 384 of pprdrv_tt.cpp),
then characters are rendered correctly. I tried other non-korean
characters to see if such change is harmful, but no such case is found
as far as I see.
As I know little about postscipt and ttf font, I'm not sure this is a
correct way (although it works fine for me). So, it will be
appreciated if Mike or others confirm this and make a change.
Thanks very much in advance.
Regards,
-JJ
ps. Although it is a very simple fix, a diff file is also attached.
On Wed, May 28, 2008 at 9:38 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> 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
>>>
[matplotlib-devel] Fwd: incorrectly rendered unicode (korean) character in ps (fonttype=3) and pdf backend
A slightly different (and can be minor) issue related with unicode support in ps backend. For one of my Korean font, it raises an following exception. File "/users/research/lee/local/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", line 688, in draw_unicode self.set_font(font.get_sfnt()[(1,0,0,6)], prop.get_size_in_points()) KeyError: (1, 0, 0, 6) Apparently, the return value of get_sfnt() for this particular font does not have (1,0,0,6) key. Agg, png, and Cairo backends are all okay with this font. Anyhow, as it happens for only one font AFAIK, and as we can use Cairo backend instead, there may not be much need to fix this unless it can be easily done. Regards, -JJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
