Subject: Decimal delimiter: presentation params should not force input

From: [email-masked]
Date: 15 Jun 94 19:05:00 -0500

----------
This has implications for i18n, person/machine interfaces and character sets.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To       : /Personnel/comp-soft-intrn
Subject  : Problem of the decimal delimiter function on input: i18n issue
From     : ALB

The following will be submitted to ISO/IEC JTC1/SC18/WG9 in Stockholm, the week
of June 27.  Software designers, be aware... This is a subtle issue which costs
a lot in terms of productivity in all current implementations of spreadsheets
and similar applications, when massive data entry is done with the help of a
numeric keypad.

Alain LaBont<e'>         (Real address: [email-masked], if different in header)
Gouvernement du Qu<e'>bec
Secr<e'>tariat du Conseil du tr<e'>sor
********************************
Title:  Request for a decimal delimiter symbol to enforce the function

Source: Canadian SC18/WG9      (author: Alain LaBont<e'>)

Date:   1994-06-16

Status: For action by the KBD and SYM rapporteur groups of SC18/WG9

Canada faces two problems with the decimal delimiters as present on the
numeric keypads and we believe this is a problem that applies to numerous
countries/environments.

On many keyboards (most personal computers), only one key has a decimal
delimiter, which some countries prefer to be [for presentation purposes]
the dot (typically in English-speaking countries) and some others (those
aligning on the SI system and ISO recommendations) the comma; some others
even use other characters to mean the decimal delimiter, which sometimes
varies in representation according to whether it is a banking or a
scientific application.

The first problem is that if the DOT is engraved on the keyboard and that
the keyboard driver generates, as is logical, a DOT, and that your
application requires a comma for presentation, you have to change your
application platform parameters (say, for example, Microsoft Windows
parameters) to tell it that the decimal delimiter will be a DOT for massive
data entry. When your input has ended, you have to change application
platform parameters to a COMMA decimal delimter again so that you can
present your number figures correctly, in accordance to your environment
habits. This is typical in Quebec, where the SI is used in French language
software but where one variant of the Canadian keyboard in use has a DOT as
decimal delimiter on its numeric keypad. Conversely, if you were to use
another keyboard variant with a COMMA as decimal delimiter and you want to
use a typical English language software in an English-speaking environment,
you would have to do a double change from the DOT to COMMA to DOT again.

This one problem calls for more flexibility at the application platform
level to better change the keyboard-application handshaking for the decimal
delimiter, which should be generic instead of "hard-wired". The function of
delimiting fractions is indeed generic and should not depend on
presentation parameters, as its meaning in computing applications is the
same everywhere.

Hence the second problem can be deduced from what was said earlier: there
is a lack of a symbol to represent what should be considered a function,
and not a "hard" character. We believe it was the intention in ISO/IEC 9995
but we are forced to say it is not the way it is implemented on any
platform that we know of.

We therefore request the inclusion of a DECIMAL DELIMITER function in a
technical addendum of ISO/IEC 9995-7 and ask for the design of an
appropriate symbol for it.

Furthermore, such a symbol will be required in online documentation and
hence ought to be coded as a character. SC18/WG9 already requested, in its
liaison with SC2/WG2 (Character sets and information coding), inclusion of
some symbols of ISO/IEC 9995-7 (those which are required as characters in
online documentation) in the first plane of the UCS (Universal coded
character set, i.e. ISO/IEC 10646-1). For coding economy reasons, Canada
requests SC18/WG9, if possible, to use an existing coded character of the
presently published UCS, to represent this new symbol. This will have a
twofold advantage: this character will be readily available and will save
coding space. There are plenty of special symbols and "dingbats" in the UCS
which are candidates to be associated conventional meanings and for which,
anyway, a good education campaign will be necessary so that the world
learn them. SC2 codes characters, users determine their meanings or vice
versa.  SC2 always made a principle to be independent of semantics and of
meanings of characters, as far as possible.

This new symbol (ideally an existing character), however, should not be a
DOT, a COMMA, an APOSTROPHE, a monetary symbol, nor any other character
specifically known to be used as a decimal delimiter already.