Canadian Government Keyboard Standard for Information Technology Equipment Appendix B - Explanatory Notes, Suggestions and Implementation Considerations

This Appendix is not a normative part of this standard.

The purpose of this Appendix is to explain some of the rationale behind TBITS-5, to make recommendations regarding aspects of the CSA standard and ISO 9995 that have not yet been fully defined, and to explain some of the potential problems that should be considered in implementing this standard.

1.Explanatory Notes

The headings within parentheses refer to the corresponding headings in the main text of the implementation criteria.

1.1 Official Languages Act

The following extracts from the Official Languages Act set the context for this standard:

35(1) Every federal institution has the duty to ensure that

a) within the National Capital Region and in any part or region of Canada, or in any place outside Canada, that is prescribed, work environments of the institution are conducive to the effective use of both official languages and accommodate the use of either official language by its officers and employees; and

36(1) Every federal institution has the duty, within the National Capital Region and in any part or region of Canada, or in any place outside Canada, that is prescribed for the purpose of paragraph 35(1)(a), to

(b) ensure that regularly and widely used automated systems for the processing and communication of data acquired or produced by the institution on or after January 1, 1991 can be used in either official language; and

(2) Every federal institution has the duty to ensure that, within the National Capital Region and in any part or region of Canada, or in any place outside Canada, that is prescribed for the purpose of paragraph 35(1)(a), such measures are taken in addition to those required under subsection (1) as can reasonably be taken to establish and maintain work environments of the institution that are conducive to the effective use of both official languages and accommodate the use of either official language by its officers and employees.

For a list of prescribed regions, see Appendix C.

1.2 (1.7 Cross Index and 4. Interpretation)C ISO 9995 DIS

As of April 1, 1992, most of the ISO 9995 standard is still a Draft International Standard (DIS). It is anticipated that most of its parts will be finalized in 1992.

1.3 (3. Application)

"Keyboards" includes keyboards that are integrated with other parts of a computer such as a display screen or a processing unit. While it is mainly directed towards office-based keyboards, departments and agencies are encouraged to apply this standard, or a specified part of it, in all pertinent applications. However, it should not be applied if it would unduly restrict competition or unduly interfere with operations.

1.4 (4. Interpretation)

The only changes in the ISO 9995 DIS that are currently anticipated that may affect this standard relate to the positioning of the level 3 shift, group shift, Alt and Ctrl keys. Treasury Board Secretariat will endeavour to make updated information available as soon as possible after any changes to the DIS.

The CSA Standard defines a "primary keyboard layout" and a "secondary keyboard layout". The CSA primary keyboard layout standardizes the positioning of accented letters and diacritical marks and how to access them. The labelling specified for function keys used with this primary keyboard layout makes it feasible to use the one standard in English, French and bilingual environments.

The internationally-standardized secondary keyboard layout provides users of unaccented primary keyboard layouts with a viable and standardized means of producing accented characters. It also provides all users with standardized access to numerous additional characters that are often of use, such as characters used in other languages, fractions and special symbols. The extent of the availability of these additional characters will depend on the hardware and software being used.

The labelling of a keyboard layout relates to that layout (group, in ISO terminology) only. For example, if a key is labelled with the CSA primary keyboard layout and the ISO secondary keyboard layout, it is labelled with two layouts. Thus, the definition of "unaccented primary keyboard layout" as being one not labelled with any accented characters relates only to that single layout or group; it may be combined with another layout or group, such as the ISO common secondary keyboard layout, that contains labelled accented characters.

1.5 (5.3 Exemptions) C Some examples

Portable computers often do not have the exact physical keyboard layouts required by this standard, and that could be a reasonable justification for acquiring a non-standard keyboard. However, it may still be possible to require that they conform to the labelling and functionality requirements, within the limits of their non-standard physical layouts C this will depend on how soon manufacturers adapt their portables to this standard.

If a keyboard is being acquired primarily as a terminal to an existing computer that cannot support the accented characters intended to be produced by the keyboard, then that may be a reasonable justification for acquiring a non-standard keyboard.

The need to acquire keyboards adapted for use by persons with disabilities would be a reasonable justification for acquiring a non-standard keyboard.

1.6 (Appendix A, 3.1) C New shift and control key placements

There is still some debate within ISO over the positioning of the "level 3 shift", "group shift", "control" and "alternate" keys. We anticipate that it will result in further flexibility than the DIS provides for, so TBITS-5 provides considerably more flexibility than the DIS. TBITS-5 will be adjusted if necessary when ISO 9995 is finalized. (Note that it self-adjusts under clause 4 for most such changes.)

1.7 (Appendix A, 4.4) C Access to broken bar

It was proposed to the CSA that this character be placed on level 3 of key E11 (hyphen/underscore key), but it was not included due to the potential confusion respecting the solid vertical bar and the prevalent mislabelling of the vertical bar as a broken bar. Examples of acceptable other means of access are to hold down a key such as <Alt> and enter a code for the character, or to display a table of characters on the screen and provide a means of choosing to enter the broken bar.

1.8 (Appendix A, 5.1) C Secondary keyboard layout

"Implementation" generally equates to "operating system", although this does not prevent applications or some other level of software from implementing any of the specified keyboard layouts. However, it is usually preferable if it is done at the lowest level possible. For example, since access to all the graphic characters of TBITS-3 (CAN/CSA-Z243.4, ISO 8859-1) is able to be provided on all IBM-compatible personal computers (standard in Windows; available in MS/PC-DOS via code page 850 or third-party equivalents), the entire portion of the common secondary character set that is also part of the TBITS-3 character set should be functional on these computers (mapped to code page 850 for MS/PC-DOS).

Note that this does not guarantee that any given application within those implementations can properly process or image the entire character set C it may be some time before applications catch up with implementations in this regard. However, it at least enables those applications that can process and image the characters to do so.

Without going into the details, the clear implication in both the CSA Standard and ISO 9995 is that all characters of the common secondary group that are able to be functional shall be functional. This makes sense since manufacturers can then produce, for a given implementation, only one functional driver for the common secondary keyboard layout regardless of what national layouts it may be associated with. Labelling of group 2 characters on keycaps then becomes the separate issue that it is C dependant on national layouts.

In Canada, this has an immediate practical benefit in that users who wish to use an unaccented primary keyboard layout can still use the common secondary layout to obtain all the characters available within a given implementation's character set or sets.

1.9 Character sets

TBITS-3 adopts the Latin alphabet no. 1 graphic character set of CAN/CSA-Z243.4-87 which is the same as ISO 8859-1:1987. In this character set, each accented character is allocated to a separate code point.

The character set ISO 6937 is used in many telecommunications applications. It does not allocate separate code points to accented characters, but rather has a group of accents that, when followed by a valid letter, are interpreted as a single accented character. The ISO common secondary keyboard layout is based on the characters able to be generated using ISO 6937, which includes ISO 8859-1 as a proper subset.

IBM-compatible personal computers using PC/MS DOS 3.3 and above are capable of using a variety of character sets through the code page facility provided in DOS. While not a proper implementation of any of the above-mentioned character set standards, code page 850 provides the character set of Latin alphabet no. 1 and should therefore be used until a better option is available.

The Microsoft Windows operating environment bypasses the DOS code pages and uses the TBITS-3 character set (with the minor addition of single `6 and 9' quotes in the C1 set); therefore, Windows applications are essentially TBITS-3 compliant.

Implementations of keyboard drivers in IBM-compatible personal computers should take account of this information.

2.Suggestions

These suggestions are offered to assist suppliers in deciding how to implement certain features that otherwise are not clearly specified. They are not requirements and do not form part of any evaluation or compliance criteria. However, we commend them to keyboard suppliers, as well as to the CSA and ISO, who have as yet not seen fit to include such details in their keyboard standards.

2.1 Action of non-spacing characters ("accents")

Neither the CSA standard nor ISO 9995 defines what happens when a non-spacing character ("accent") is followed by an invalid character C that is, by a character with which the accent cannot be combined, either because the combination is not a recognized one (for example, ^3 or ^?) or because the particular implementation cannot deal with the combination (for example, ^j, which is a valid combination to produce a recognized language character (^j), but which most implementations cannot deal with).

The TBITS suggestion to suppliers is that this situation always be dealt with in the following simple and logical manner: discard the first in the sequence of two characters.

Thus, an accent followed by a 3 would produce only the 3. A circumflex followed by a j would produce the ^j character if that is available in the implementation, but otherwise would produce only the j. A circumflex followed by a diaeresis would discard the circumflex and would retain the diaeresis to be applied to the following character, if it is a valid one; likewise with a circumflex followed by itself.

An accent followed by a space is then a logical way to think of producing the accent as a spacing character, since it is essentially an accented space (which is made a valid character by definition).

2.2Group shift and level 3 shift

Neither the CSA standard nor ISO 9995 defines important aspects of the operation of the group shift and level 3 shift keys.

Group shift would be relatively simple if there were only two groups, the primary keyboard layout and the common secondary keyboard layout, but the standards provide for an unlimited number of groups. Many keyboards in Canada will have at least three groups available, the third being an unaccented keyboard layout. (The unaccented keyboard layout will likely continue to be the default if no software to implement the CSA standard is loaded, and users may often find it necessary to activate it in order to work with certain software.)

Annex B to ISO 9995-1 describes (but does not even go so far as to recommend) one method of group shifting: use the group shift key in conjunction with the left and right (regular) shift keys to move from group to group. It is not clear as to whether "in conjunction with" means "at the same time as" or "one after the other" that is, to move to another group, must you press and hold the group shift key, then press a regular shift key, or can you press the group shift key, let it up, then press a regular shift key? However, the whole description is in conflict with another statement in Annex B to ISO 9995-1 which states. "If, while the group shift key is held down, a graphic key is operated, the graphic character is generated from a different group and depends on the shift level in force" (underline added). This statement appears to be an error, since shifting to another group cannot require that you hold the group shift key down in order to get any characters from whatever group it may be.

Similarly, regarding the level 3 shift key, ISO 9995-1 Annex B states that "if the level 3 shift key has been operated, the graphic character is generated from level 3" (underline added). This would imply that it is, or may be, a sticky shift key, and that you can get a level 3 character by pressing and releasing the level 3 shift key and then pressing the character key.

It is suggested that both group shift and level 3 shift be implemented to function in the same way as regular shift keys C they must be held down while another key is pressed in order to produce any effect. This is best for consistency, and allows easy "cancellation" of a miss-hit shift key. The only disadvantage is to persons who do not have two hands to type with, and special keyboard drivers that make shift keys "sticky" are generally available to solve the problem for them.

It is also suggested that group shift be implemented in the following fashion: press and hold the group shift key or two-key combination, then press a number from 0 to 9 to indicate the group (layout) to shift to. The primary keyboard layout for a given implementation should always be 1, the common secondary keyboard layout should always be 2, and then others can be added beyond that. The 0 (zero) keyboard layout should always be the power-on default keyboard layout that is in effect if no special keyboard drivers are loaded. For example, in current North American personal computers, it would almost always be the unaccented keyboard layout that a given supplier now provides. That layout should always be available in case it is needed for use with an application that cannot work with another layout. It is highly unlikely that anyone will want to implement more than 7 other keyboard layouts.

Thus, in an existing personal computer implementation of the CSA standard, group 0 would be the unaccented power-on default layout, group 1 would be the CSA primary keyboard layout, and group 2 would be the secondary keyboard layout. If a two-key combination is used for this sort of implementation of the group shift function, it is suggested that it be the Alt-Ctrl combination.

3.Some Implementation Considerations

These considerations relate primarily to IBM-compatible personal computers, though some (especially the first) are applicable to other equipment.

3.1 Keyboard is only one step

The main thing to recognize is that the keyboard is only one step in implementing the capability to use French with a computer system. In fact, it is not even the first step C it is only the most visible. It cannot function properly without a compatible character set, display device and printer. And of course, the operating system and applications should all work compatibly with each of these other pieces of the system. In other words, there are complications.

One thing that must be realized is that users who are presented with a keyboard that is labelled with accented characters will expect that it will work as labelled. Therefore, if it will not work with certain applications or in certain instances, then users should be advised of this and should be trained in what to do about the problems. Everyone needs to realize that the transition will not be without problems.

3.2 Code pages

MS/PC-DOS versions 3.3 and above have the ability to use several character sets, which DOS calls "code pages". The code page recommended for use in conjunction with the TBITS-5 keyboard standard is code page 850 C Multinational. It contains all the characters required by TBITS-3 although they are not mapped to the same code points in the upper half of the set. (There is a possible exception C the no-break space, which should presumably be code point 255 decimal/FF hex in code page 850, but it is not clear that this works.)

However, using a code page presents problems. One is RAM cram, and another is that many applications, including some of the most popular ones, do not work with code pages. These are covered in more detail below. Another problem that is more one of appearance than reality is that the intersections of double and single lines of box-drawing symbols created using code page 437 will appear as alphabetic characters on a display using code page 850.

3.3 Hardware and operating system requirements

To properly implement this keyboard standard on an IBM-compatible personal computer, the computer should have an EGA or VGA compatible display and should be operating under MS/PC-DOS 3.3 or higher. Otherwise, code pages cannot be fully implemented and most uppercase accented characters probably cannot be displayed.

3.4 RAM cram

A keyboard driver (software to implement this keyboard standard) takes up memory. Implementation of the code page facility takes up even more memory. This can become a problem, especially for computers on a network, because network drivers also take up a lot of memory. The result may be that there is insufficient memory to run some applications. Upgrading to a new operating system such as MS-DOS 5.0 or DR-DOS 5.0/6.0 can help considerably. Another possible aid is third-party substitutes for DOS code pages.

3.5 Networks

Networks present problems other than RAM cram. Most significant are incompatibilities among computers on a network. If one computer is using code page 850 and another is using code page 437 (the PC-compatible default), then transmission compatibility problems need to be considered. This may involve incompatibilities in file contents, complications with printer drivers, and other problems. For example, a database record or electronic mail message containing uppercase accents entered using code page 850 would appear to contain errors if viewed on a computer using code page 437. Generally, a printer driver has to know what code page is being printed in order to print it correctly (WordPerfect being an exception since it deals with code pages and extended characters by itself). Informatics support staff will have to become much more familiar with these problems than most such staff currently are.

3.6 Application problems

Very few MS/PC-DOS applications are "code-page aware" C that is, few even recognize that a code page other than 437 exists. One important exception is WordPerfect C for more details on its use with code pages and with French characters, refer to TBITS-15, The use of French characters with IBM-compatible personal computers. Most applications just pass characters through as bytes, not really caring what they are (unless, for example, you are doing a validity check in a database or a spellcheck in a document). Such "transparent" applications may pose few problems, other than with printer drivers. A few applications want to take over the computer themselves, to the extent of taking control of the keyboard and using their own character sets. Lotus 1-2-3 is the major example. The key is to know your environment and how your applications interact with it.

3.7 Microsoft Windows

Microsoft Windows is an operating environment C something between the operating system (MS/PC-DOS) and the application (WordPerfect, Lotus 1-2-3, etc.). However, it creates an environment so different from DOS that one can safely regard it, for most purposes, as another operating system, and this is especially true with respect to keyboards and character sets.

Windows both alleviates and creates problems. It alleviates problems because it uses its own character set that is essentially the same as the TBITS-3 character set, and all true Windows applications can use that character set. (Note that WordPerfect for Windows still uses its own character set C exactly the same as in the DOS version C but this does not present problems since it knows how to deal with the Windows character set.) Windows also provides various keyboard drivers, and will hopefully be able to provide the ones required by this TBITS-5 standard by the effective date.

Windows creates problems because it takes over the keyboard from DOS, substituting its own keyboard driver (except that in a DOS window, the DOS keyboard is re-activated). Also, at the time of writing this document, Windows appears to assume that all data being imported from DOS is in code page 437 format C it does not contain a means of specifying that data is in another code page format, specifically code page 850.

4.Conclusion

Even from this brief summary, which barely scratches the surface of a complex issue, it should be evident that there are many complications related to implementing the capability to use French on computer systems, and in particular on IBM-compatible personal computers. TBITS-3 and TBITS-5 are important steps on the road to resolving these complications. These standards are fully compatible with national and international standards, and will finally provide the computer industry with a definitive Canadian framework that will resolve the confusion that has previously existed.

As with any transition period, problems can be expected. The important thing is that we have established a target for the future. It is now up to suppliers and government informatics support staff to work toward the common goal of eliminating the problems.