Subject: RE: Keyboard standards and general keyboard making considerations, in particular involving Microsoft

From: "Alain LaBont/e'/" <[email-masked]>
Date: Fri, 10 Jan 1997 11:09:02 -0500

At 07:42 97-01-10 -0800, Elisabeth Anniehs (Microsoft Canada) wrote:
>Hello Alain:
>
>There are lots of interesting discussions you cc me now and then.  I am 
>trying to find the best way to get this information available to those that 
>can actually look into the discussion from a developers perspective.
>
>I got in touch with Lori Brownel - [email-masked] who is an 
>International Program Manager for Windows NT development. She is interested 
>in any discussion that is related to International issues - Unicode, 
>keyboard standards, anything that would be system related.  I was wondering 
>if it's possible at all for you to include her on your distribution list 
>for relevant discussions.
>
>Is it ok with you that I provide contacts at MS that are actual in 
>development so you can cc on discussions that are relevant to the areas of 
>their interest?  Because if it is, I do have another name that is 
>interested in discussions concerning the use of Word in International and 
>multilingual environments.  Her name is Susan Putnam - 
>[email-masked] who is a Program Manager for Word development.
>
>Unfortunately there are not many contacts at our Corporation that can 
>understand French, which is a pity as some of the email you cc me are in 
>French and very interesting. None of the names I gave you can manage 
>reading French.
>
>I wish you a great week-end.  Many thanks for your mails.
>
>Elisabeth

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.

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
>
>
>
>