Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On Thu, Nov 20, 2008 at 1:22 PM, peter green <[EMAIL PROTECTED]> wrote: > > > > The thing is we can't reasonablly provide functions based on what a user > > would see as a character because doing so would require huge lookup tables > > (one user visible character != one code point) so the best we can do is > code > > point based which isn't really much better for most tasks than code unit > > I think basing those functions on code points should suffice. I also > think as soon as strings are assigned or loaded from file, they should > be normalized. So two code points like the A and Umlaut code points > would become one. > > The .SaveToFile() methods could take an optional parameter to decide > if the normalized version of the string gets saved, or if it must be > split again - which I think Mac OS-X prefers.
Mac OS X (or better: HFS) auto normalizes. SaveToFile just needs unicode. Normalization is only important when comparing filenames. That's why lazarus code always uses CompareFilenames. Mattias _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
