Subject: To the rescue of Keld in Symbolic name usefulness when chars don't exis

From: ALB <[email-masked]>
Date: Thu, 9 Jan 1992 00:47 GMT

I hope I will scandalize nobody if I say that to process characters
corectly, coded character sets are not very useful any way, except it is the
best need to input and output characters to minimize necessity of agreement
between parties, which has even proven to be quite difficult.

In fact in the Quebec Government, to be able to process (sort/search/compare/
merge textual data without having to change old programs, sort programs,
access methods provided by vendors and so on, we store character data in
only retaining meaning according to CSA standard Z243.4.1 (on which has
been built POSIX LC_COLLATE structure).

Now as a consequence it means that even if we don't have, say, the possibility
to input or output a LATIN LETTER C WITH CARON, we can store the character
so that it can be correctly compared everywhere, and we can even omit the
accent on output just by dropping temporarily part of the data, like
in floating point numbers you can truncate a mantissa and only lose precision
without loss of the essence of a number.

In this case Keld's short ids can be quite useful: once decorticated all the
information is retained in binary processable form. So far it works even in
so-called 8-bit envrironments because we don't store 8-bit characters,
but n-bit strings of binary data directly representing chaarcter data in
the most efficient processable (directly) form...

I found the other explanation simplist about processing of caharcter data.
Comparisons of chaarcters are not limited to equality, and thus just storing
characters on an external file in their standardized format does nothing to
make processing consistent, though I agree for fixed messages (error msgs,
info msgs, prompts, etc.) it is the only way, except it must also be
stored ideally, as Keld pointed out, independently of a given code, so that
these messages be ported even in the same country using the same language
but another code.

For more information about structure of binary processable text (those who
never heard my sempiternal preaching and conferences on this issue), please
contact me.

              Alain LaBont/e
              Minist\ere des Communications du Qu/ebec