Hi all,<br><br>I've committed some changes to the unicode branch. I've fixed copyright infos and headers, the README, added an entry in NEWS for 0.4, and did some other work on the source code as well. The compiler warnings should be gone.
<br><br>If possible, can you guys test it to identify any further issues? You can use the WIP-pyshapelib-Unicode branch "out of the box", as no merge with the trunk is necessary (I did that for you).<br><br>Known issues:
<br><br>* {test_load|test_load_1_0}.TestNonAsciiColumnName.test:<br><br>the column name Fläche is giving us troubles. Not in dbflib itself, as it is handled correctly over there, but apparently it is not encoded to UTF-8 when written to the session XML, causing the test to fail. I'm not familiar with this issue, so if anyone can help, please feel free =)
<br><br>* test_transientdb.TestTransientTable.{test_auto_transient_table|test_transient_table}:<br><br>the shapelib C library returns integer numerical fields with more than 10 digits as double (in order to avoid an overflow with the C int). This is causing the test to fail as an 'int' is expected for column 3, and an 'double' is found. Bernard Herzog suggests to let pyshapelib convert them back to Python long integers. On the Python API level this can easily be done using PyLong_FromDouble. Is it OK to mix long integers and "short" integers, or should all integers coming from pyshapelib be converted to long ints?
<br><br>* when creating new DBF files, Thuban will use the LDID_ESRI_ANSI code page. That's LDID 0x57 and uses the cp1252 codec. This should be configurable by the user, but I don't really know where to start. Can anyone who's familier with the Thuban UI give a headstart?
<br><br>* pyshapelib should get a proper unittest that can run on its own, but is also tested from test/runtests.py. I've never made a unittest in Python before, so I'm a bit puzzled here.<br><br>-- <br>hi, i'm a signature viruz, plz set me as your signature and help me spread :)