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.ge
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 wro
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 back
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
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
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 surp
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
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
