From keld Fri Jan 10 23:27:16 1997 Received: (from keld@localhost) by dkuug.dk (8.6.12/8.6.12) id XAA04219; Fri, 10 Jan 1997 23:27:16 +0100 Message-Id: <199701102227.XAA04219@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Fri, 10 Jan 1997 23:27:12 +0100 In-Reply-To: "Alain LaBont/e'/" "(SC18WG9.36) RE: Keyboard standards and general keyboard making considerations, in particular involving Microsoft" (Jan 10, 17:42) X-Charset: ISO-8859-1 X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Alain LaBont/e'/" , Elisabeth Anniehs Subject: Re: (SC18WG9.36) RE: Keyboard standards and general keyboard making considerations, in particular involving Microsoft Cc: loribr@MICROSOFT.com, susanput@MICROSOFT.com, michelsu@MICROSOFT.com (M. Suignard), sc22wg20@dkuug.dk, sc18wg9@dkuug.dk "Alain LaBont/e'/" writes: > I ask with this note my friend and colleague Keld Simonsen from Denmark > (responsible for pertinent mailing lists on these subjects) to put her name > on our SC22WG20 (internationalization of applications) and SC18WG9 (system > user interfaces) international email lists (I am a standards project editor > in these two ISO/IEC groups). I by the same occasion invite Microsoft to > become a regular member of our SC22WG20 team if it is possible also through > national participation in official standards bodies. We had participation > from Michel Suignard for a few meetings (when he was located in Paris, he is > now in Seattle), but that has stopped, Michel concentrating his work in the > SC2 (character coding standardization) area. Who exactly should I put on the lists, Alain? Please give name and email. Regards Keld > For what I also send you occasionally when I think about it, you are also > encouraged to copy everything to Microsoft people whererever they are in the > world. It will be useful for Microsoft and also for us. If I can personally > help clarify some issues, I will also be glad as this is very important for > my work, dedicated to solving these issues. > > With warm regards. > > Amitiés. > > Alain LaBonté > > cc Keld Simonsen, SC22WG20 email list site manager > Lori Brownel > Susan Putnam > Michel Suignard > SC22WG20 list > SC18WG9 list > ________________________________________________________ > > >-----Original Message----- > >From: Alain LaBont/e'/ [SMTP:alb@sct.gouv.qc.ca] > >Sent: Thursday, January 09, 1997 3:29 PM > >To: Jean-Yves Fortin; trondt@barsek.hsf.no > >Cc: Pierre Chadi; Elisabeth Anniehs; Sophie Godon; Michel Lemay; > >everson@indigo.ie > >Subject: Re: Keyboard standards and general keyboard makingconsiderations, > >in particular involving Microsoft > > > >At 14:23 97-01-09 -0500, Jean-Yves Fortin wrote: > >>From that viewpoint, the Macintosh has implemented the "decimal > >delimiter" > >>at the system level allowing a user to specify it using the control > >panel. > >>Once set, the keypad will return the appropriate delimiter (i.e. comma or > >>period). > > > >That is better than nothing but it is not conformant to the standard nor > >does it make sense in a general model. Whenever you enter a number, the > >software should not care *at all* about the symbol(s) that will be used > >for > >presenting this number. A number is a number and when you signify the > >software (even more *on the numeric keypad* really intended for massive > >data > >entry of pure numbers) that you want to stop entering the integer part and > >begin entering the fractional part, it has nothing to do with a symbol but > >is intimately related to the properties of a pure number. > > > >>In fact, on the Canadian Macintosh keyboard both symbols appear. > >>In the case of Excel, it will automatically recognize the comma, if the > >>comma has been set in the control panel. I do not know how this is > >>implemented in Windows 3.1 or 95. > > > >Under Windows (even with the latest version of Excel), if the keyboard > >driver returns a " . " for the decimal delimiter located on the numeric > >keypad, the user is forced to tell Excel that the *presentation* of the > >number on *output* will use a " . " even if it will rather use a " , ". > >Then, for presentation, it has to be changed back to " , "... > > > >That is a major flaw that all those doing massive data entry using the > >numeric keypad in Québec have complained about for years, perhaps not to > >the > >right persons. It has an impact on their productivity and it is very > >frustrating... you have no idea about what they say about the implementers > >of this flaw! > > > >There are 2 flaws : > > > >1) one with the software keyboard driver that generates a character instead > >of > > calling a function. This is a general historic flaw worlwide. Only > > progressively will it be changed when we migrate to new keyboards and > >new > > systems. > > > >2) that said, given that a scan code is also generated by any keyboard and > > provided to the software, the first flaw could still be righted. > >Indeed, > > one needs to know the difference between a " . " (or a " , ") generated > > by the keyboard driver out of the numeric keypad from the one coming > >out > > of the alphanumeric section of the keyboard. Excel is very able to > > distinguish that but it does not yet under Windows. I am glad that at > >least > > the problem does not exist on a Mac, but are you really sure ? Did you > > really understand the problem? If the Mac generates a character, it > > generates one character, not the other. This is at least a partial flaw > > too. In Canada (and I documented this in 9995-7 amendment 1, the usage > >is > > as follows for the decimal delimiter (it is variable so therefore in > >the > > way you say it is done, it would not work without changing parameters > >too > > even for data entry, while data entry of a number is an invariable > > process): > > > > > > English Canada French Canada > > > >General purpose . by default , by default > > (, for certain applications) (. for certain > >applications) > > > >Banking . . for interbank > >transactions > > , for certain customers , for customer > >presentation > > . for certain customers > > > >The amendment 1 to ISO/IEC 9995-1 also documents numerous other usages in > >countries which have more than 1 usage in the same country (Scandinavian > >countries, Arabic countries, Portugal, and so on), so this problem is not > >proper to Canada. > > > >Nevertheless a number is a number everywhere, regardless of presentation. > > > >Input methods shall be acknowledge this... > > > >Alain LaBonté > >Québec > > > > > > > > >