[Shapelib] Re: shapelib improvements

ANDY CANFIELD andy_canfield at hotmail.com
Tue Dec 11 16:39:42 PST 2007


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.
Thank you,
Andy Canfield



> Date: Fri, 7 Dec 2007 20:36:01 +0100
> From: mateusz at loskot.net
> To: shapelib at lists.maptools.org
> Subject: Re: [Shapelib] Re: shapelib improvements
> 
> Bram de Greve wrote:
> > Tom Kazimiers wrote:
> >> Mateusz Loskot schrieb:  
> >>   
> >>> Tom,
> >>>
> >>> Perhaps we could make a unicode branch of Shapelib.
> >>> Frank's opinion is most important here, not mine
> >>>   
> >>>     
> >> This would be a good thing
> >>   
> >>>> But if you use shapelib as a dll from another program, esp. a managed
> >>>> code one (I use C#) - on windows CE you have the only option to call
> >>>> with unicode parameters. This means you have to write wrappers which
> >>>> to the transformation or one makes the dll unicode aware (this is
> >>>> what I did). Are there any ways to get a managed to unmanaged call on
> >>>> Win CE working with char?
> >>>>     
> >>>>       
> >>> Doesn't marchaling to UnmanagedType.LPStr work?
> >>> Also, CharSet attribute of DLLImport to control how encoding information
> >>> is marshalled. CharSet.Ansi is default for C++, so Unicode->ANSI is
> >>> translated automatically.
> >>
> >> Sure it is on a "normal" desktop computer - but in Win CE environment
> >> one can only choose CharSet.Unicode as the whole OS works only with unicode.
> >> The UnmanagedType.LPStr I did not try out - I will test it. But since I
> >> have read that Win CE can only handle unicode I doupt it  would work.
> > 
> > It might solve your problems with unicode filenames, but how will you
> > cope with textual content
> 
> Bram,
> 
> We are discussing solution for encodings of file paths only.
> Certainly, it wouldn't solve problems with handling localized content
> (strings) but this is another subject.
> 
> > You will need to build in all your encodings
> > as internally all textural content is char* exclusively (with various
> > encodings).  That can be done?
> 
> Yes, it can.
> However, it is complex task and would require use of char codes
> encoders/decoders like iconv.
> 
> This subject will probably be covered along with implementation of
> GDAL/OGR RFC 5 (http://trac.osgeo.org/gdal/wiki/rfc5_unicode).
> 
> > Also, I suggest to first consider if you can't solve your problems with
> > wrapper code.  Not wrapper code around the DLL, but building a unicode
> > DLL with wrapper code around the original.  That way, you don't have to
> > branch (or to fork), which might be beneficial to both ...
> 
> This won't solve all possible problems with internationalized paths.
> IMHO, simpler and cleaner solution is to replace current I/O calls with
> Unicode-aware calls from C/C++ libraries. The main disadvantage is that
> it will introduce new fork. However, Shapelib is not a big library, it's
> just 3 files of code, so forking does not sound as a problem for
> possible merge in future.
> 
> Cheers
> -- 
> Mateusz Loskot
> http://mateusz.loskot.net
> _______________________________________________
> Shapelib mailing list
> Shapelib at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/shapelib

_________________________________________________________________
Share life as it happens with the new Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/shapelib/attachments/20071211/b23979cb/attachment.html>


More information about the Shapelib mailing list