New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacOSX backend unicode problems in python 3.3 #1737
Comments
I'm not a Mac user, so I'm only speculating based on reading the code, but it appears as if the |
Any Mac users want to take this on? |
@mdehoon is an obvious candidate - although that doesn't mean that others shouldn't step-up. 😄 |
I'd be happy if somebody else gives a try. This doesn't sound like a very complicated bug, at least not one that would need much code reorganization. If nobody steps up over the next couple of months or so, I can have a look at it. |
I came across this yesterday and made a few changes to the v1.2.0 commit of _macosx.m that resolve the problems as far as I can tell. My disclaimer is that I have never worked with Objective-C and I am just beginning with python. My changes were to GraphicsContext_get_text_width_height_descent and GraphicsContext_draw_text, I changed PyArg_ParseTuple to pass back UTF8 encoded strings (s# instead of u#). if(!PyArg_ParseTuple(args, "ffs#Ofssf", &x, &y, &text, &n, &family, &size, &weight, &italic, &angle)) return NULL;
CFStringRef s = CFStringCreateWithCString(kCFAllocatorDefault, text, kCFStringEncodingUTF8); This would require a review as I am not confident about best practices. I added a pull request with my changes if it is useful to anyone. |
@bingjeff : Could you post a diff so we can have a look at your changes? (or better yet, create a github branch with the fix?) |
@bingjeff : Thanks for providing the pull request. It seems to work fine for Python 3.3, but it breaks unicode handling for Python 2. For example, try running unicode_demo.py in examples/pylab_examples. So I think we need to add #ifdef's to GraphicsContext_draw_text to keep using the old code for Python 2. |
Resolving Issue #1737 - MacOSX backend unicode problems in python 3.3
My matplotlib install on Python 3.3.0 seems to be cutting basically all strings in half in the MacOSX backend. This happens with both matplotlib 1.2.0 and the latest git; it doesn't happen on 2.7. I don't have a 3.2 install anymore, but I didn't see this problem with slightly earlier versions of matplotlib.
For example, if I simply run
plt.xlabel('xlabel')
, onlyxla
shows up in the xlabel position. This problem also applies to the ticks, so that labels that would normally say eg0.2
say just0.
. In general, it seems that the length of displayed strings is half the length of the passed string, rounded up. If I try to save the resulting figure through the backend, I get this exception:The Qt4Agg backend seems normal, and
matplotlib.test()
succeeds with only known failures and irrelevant warnings.I'm on OSX 10.8.2 with the most recent Xcode command line tools (
clang --version
saysApple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
); dependencies are installed via homebrew.The full log of
setup.py build
is here, but only this quite suspcious-looking warning stands out:Since the referenced line is in the function
choose_save_file
, it seems like that probably explains at least the problem with saving files, andunichar
being anunsigned short
vsPy_UNICODE
being anint
seems likely to explain the general problem (since ashort
is 2 bytes and anint
is 4).This presumably broke in 3.3 because of something related to PEP 393, which notes that "The
Py_UNICODE
type is still supported but deprecated."The text was updated successfully, but these errors were encountered: