Hi,
Pierre Martineau wrote:
Hi,
I'm trying to compile the python-uno bridge using my system python UCS4 enabled (Debian unstable) from OOo1.1.4 source.
It indeed compile but it does not work because the unicode conversion between OOo and python are not working correctly. Since I don't know C++ and gdb it's difficult to understand what is going on.
Conversion from OOo -> python seems to be done in pyuno_util in the function ustring2PyUnicode For Wide unicode the code is: OString o = OUStringToOString( str, RTL_TEXTENCODING_UCS4 ); ret = PyRef( PyUnicode_FromUnicode( (Py_UNICODE*)o.getStr() ,o.getLength() ), SAL_NO_ACQUIRE );
Conversion from python -> OOo are in pyuno_runtime in pyObject2Any. Again for wide unicode: // fixed for 0.9.2: OUString ctor expects the length of the byte array ! s = OUString( (sal_Char * ) PyUnicode_AsUnicode( o ), PyUnicode_GetSize( o ) * sizeof(Py_UNICODE), RTL_TEXTENCODING_UCS4 );
I replaced both conversions by a conversion through UTF8.
In pyuno_util:
OString o = OUStringToOString( str, RTL_TEXTENCODING_UTF8 ); PyObject* utf8 = PyUnicode_DecodeUTF8(o.getStr(), o.getLength(),NULL); ret = PyRef( utf8, SAL_NO_ACQUIRE );
An in pyuno_runtime:
PyObject* utf8 = PyUnicode_AsUTF8String(o); s = OUString(PyString_AsString(utf8),PyString_Size(utf8), RTL_TEXTENCODING_UTF8);
It seems now to work ok. Since there is an additional conversion it may be a bit slower but I don't think this is the main limiting factor.
the last one introduces a leak, you need to add a
Py_DECREF( utf8 );
My problem is that I have no idea if it can be considered as a bug in pyuno, in the sal/rtl library or in my Debian system. Did somebody have any success with UCS4 python?
Your suggested solution indeed is none.
Debian itself might choose to provide binary rpms to ship both a python and OpenOffice.org, that play well together.
Or you choose to build both python and OOo by from source.
Or you use the python coming with ooo.
But in general you can't make a binary debian python package run with a binary OpenOffice downloaded from somewhere else. Even if you can work around the the above issue as described, it may not work, because python and OOo were built with incompatible compiler versions (currently, this does not seem to be the case but may and will occur in not so distant future).
There is no way to workaround this until there is a binary compatible python (and even before a binary compatible g++). And this seems notto be going to happen ...
Bye,
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
