From ALB@immedia.ca Sun Jun 15 14:05:00 1994 Received: from Clouso.CRIM.CA by dkuug.dk with SMTP id AA27033 (5.65c8/IDA-1.4.4j for ); Thu, 16 Jun 1994 15:07:41 +0200 Received: from immedia.ca by clouso.crim.ca (4.1/SMI-4.1) id AA15942; Thu, 16 Jun 94 09:07:04 EDT Return-Path: Received: by immedia.ca (3.2/2.D) id AA18745; 16 Jun 94 13:13:12 -0500 Date: 15 Jun 94 19:05:00 -0500 From: ALB@immedia.ca Message-Id: <199406161313.AA18745@immedia.ca> To: bealle@torolab6.vnet.ibm.com, cpwg-mail@revcan.ca, paref@vm1.ulaval.ca, umavs@torolab6.vnet.ibm.com Cc: i18n@dkuug.dk, sc22wg20@dkuug.dk, tc304@dkuug.dk Subject: Decimal delimiter: presentation params should not force input X-Charset: ASCII X-Char-Esc: 29 ---------- 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 (Real address: ALB@IMMEDIA.CA, if different in header) Gouvernement du Qubec Secrtariat du Conseil du trsor ******************************** Title: Request for a decimal delimiter symbol to enforce the function Source: Canadian SC18/WG9 (author: Alain LaBont) 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.