In our previous episode, dmitry boyarintsev said: > On Tue, Mar 21, 2010 at 2:01 PM, Marco van de Voort > <http://bugs.freepascal.org/view.php?id=15795> wrote: > > I'll reiterate my opinion that first a decision about what the working > > stringtype of the RTL will be. > > IMHO there is no decent solution till there is a real utf-8 type (read > > cpnewstr) > > The whole reason for the package, is not to wait for cpnewstr being > implemented. > That's the point that package's interface uses UnicodeString, rather > than ambiguous "String" type (that's currently system dependent).
Yes. Which is no problem for the package. But it is a reason to not include it. > > Note that the recent update does not tackle my main gripe at all, the main > > units interface is still UTF-16 on Unix, > > it just translates it to UTF-8 in the backend. > Yes, it does so and i see no problems here. The package also converts > UTF-16 to ansi encoding for Win9x. > Converting string from UTF16 to UTF8 (or any other encoding) is not > much time penalty comparing to the time of the file operation itself. Sure. But that still doesn't mean UTF-16 is the ideal choice. > Btw, the current RTL implementation also forces a user to convert a > "string" type to utf8, to work correctly on Unixes for unicode names. Currently there is no unicode support. The point is rather that I don't want to commit an halve one, and be stuck with it (and all kinds of packages "just" using it) forever. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
