Subject: Re: (SC18WG9.36) RE: Keyboard standards and general keyboard making considerations, in particular involving Microsoft

From: [email-masked] (Keld J|rn Simonsen)
Date: Fri, 10 Jan 1997 23:27:12 +0100

"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:[email-masked]]
> >Sent:	Thursday, January 09, 1997 3:29 PM
> >To:	Jean-Yves Fortin; [email-masked]
> >Cc:	Pierre Chadi; Elisabeth Anniehs; Sophie Godon; Michel Lemay; 
> >[email-masked]
> >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
> >
> >
> >
> >
>