[Shapelib] Re: shapelib improvements

[Mateusz Loskot]

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