<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;">If it's not to late and I can put in a vote for the type of Unicode to support I'd like to vote it be UTF-16. Most of the Windows platforms like 2000, and XP have their internal character representation as UTF-16. NT was UCS-2 though but UTF-16 is compatible with UCS-2 from U+0000 through U+FFFF it just doesn't support surrogate pairs so UTF-16 can support the entire BMP and the highest planes of Unicode while UCS-2 cannot. .Net also internally maintains it's characters as UTF-16. The fact that windows internally is UTF-16 may be why an earlier poster had problems with UTF-8 encoded paths. I know shapelib isn't Windows specific but if we support UTF-16 it will make windows development a whole lot easier and I don't think it would make *nix or other platform development any harder using UTF-16 instead of UTF-8. Mac OS X's Cocoa and Core foundation frameworks use UTF-16 internally as does the Java bytecode environment. I haven't worked on *nix platforms in almost two years now so I can't remember what they use internally. Anyway those are my thoughts and if it isn't to late to vote for the Unicode format we support I would like to throw my hat in UTF-16s corner.<br>Thank you,<br>Andy Canfield<br></div><br><br><br><hr id="stopSpelling">> Date: Fri, 7 Dec 2007 20:36:01 +0100<br>> From: mateusz@loskot.net<br>> To: shapelib@lists.maptools.org<br>> Subject: Re: [Shapelib] Re: shapelib improvements<br>> <br>> Bram de Greve wrote:<br>> > Tom Kazimiers wrote:<br>> >> Mateusz Loskot schrieb: <br>> >> <br>> >>> Tom,<br>> >>><br>> >>> Perhaps we could make a unicode branch of Shapelib.<br>> >>> Frank's opinion is most important here, not mine<br>> >>> <br>> >>> <br>> >> This would be a good thing<br>> >> <br>> >>>> But if you use shapelib as a dll from another program, esp. a managed<br>> >>>> code one (I use C#) - on windows CE you have the only option to call<br>> >>>> with unicode parameters. This means you have to write wrappers which<br>> >>>> to the transformation or one makes the dll unicode aware (this is<br>> >>>> what I did). Are there any ways to get a managed to unmanaged call on<br>> >>>> Win CE working with char?<br>> >>>> <br>> >>>> <br>> >>> Doesn't marchaling to UnmanagedType.LPStr work?<br>> >>> Also, CharSet attribute of DLLImport to control how encoding information<br>> >>> is marshalled. CharSet.Ansi is default for C++, so Unicode->ANSI is<br>> >>> translated automatically.<br>> >><br>> >> Sure it is on a "normal" desktop computer - but in Win CE environment<br>> >> one can only choose CharSet.Unicode as the whole OS works only with unicode.<br>> >> The UnmanagedType.LPStr I did not try out - I will test it. But since I<br>> >> have read that Win CE can only handle unicode I doupt it would work.<br>> > <br>> > It might solve your problems with unicode filenames, but how will you<br>> > cope with textual content<br>> <br>> Bram,<br>> <br>> We are discussing solution for encodings of file paths only.<br>> Certainly, it wouldn't solve problems with handling localized content<br>> (strings) but this is another subject.<br>> <br>> > You will need to build in all your encodings<br>> > as internally all textural content is char* exclusively (with various<br>> > encodings). That can be done?<br>> <br>> Yes, it can.<br>> However, it is complex task and would require use of char codes<br>> encoders/decoders like iconv.<br>> <br>> This subject will probably be covered along with implementation of<br>> GDAL/OGR RFC 5 (http://trac.osgeo.org/gdal/wiki/rfc5_unicode).<br>> <br>> > Also, I suggest to first consider if you can't solve your problems with<br>> > wrapper code. Not wrapper code around the DLL, but building a unicode<br>> > DLL with wrapper code around the original. That way, you don't have to<br>> > branch (or to fork), which might be beneficial to both ...<br>> <br>> This won't solve all possible problems with internationalized paths.<br>> IMHO, simpler and cleaner solution is to replace current I/O calls with<br>> Unicode-aware calls from C/C++ libraries. The main disadvantage is that<br>> it will introduce new fork. However, Shapelib is not a big library, it's<br>> just 3 files of code, so forking does not sound as a problem for<br>> possible merge in future.<br>> <br>> Cheers<br>> -- <br>> Mateusz Loskot<br>> http://mateusz.loskot.net<br>> _______________________________________________<br>> Shapelib mailing list<br>> Shapelib@lists.maptools.org<br>> http://lists.maptools.org/mailman/listinfo/shapelib<br><br /><hr />Share life as it happens with the new Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007' target='_new'>Share now!</a></body>
</html>