From: Doug Ewell (email@example.com)
Date: Sat Mar 17 2007 - 14:11:28 CST
Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:
>I think that normalizing to NFC is good when it's time to store the
>text in file (this could be made optional by adding an option in the
>save dialog) or into some data stream (for later interchange) ; in the
>editor itself (or even after saving the file from the editor storage),
>you don't need to perform it, so you'll keep the characters as they are
>generated from the keyboard driver. This way, you don't need any
>special code for specific keyboard drivers.
I agree with the idea of making normalization an option at save time,
just like the option of what format to save the file in (UTF-16, UTF-8,
etc.). For a long time I had hopes that SC UniPad would add a
normalization feature, but that seems unlikely now.
> Rally, normalization is only needed for compatibility with other
> processes that do not recognize the canonically equivalent forms (i.e.
> non Unicode-compliant processes, because all compliant processes
> should produce consistent results, i.e. canonically equivalent results
> from any canonically equivalent input), or that restrict their
> supported character set (for example, for increased security like in
But that list of "other processes" includes most software products on
the market. Very few text processors really support normalization.
It's disappointing how many vendors, even today, think "Unicode support"
means the ability to read and write files in UTF-16 or UTF-8.
-- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages
This archive was generated by hypermail 2.1.5 : Sat Mar 17 2007 - 14:13:27 CST