From ALB@immedia.ca Sat Oct 11 13:04:00 1994 Received: from Clouso.CRIM.CA by dkuug.dk with SMTP id AA08831 (5.65c8/IDA-1.4.4j for ); Tue, 11 Oct 1994 19:13:15 +0100 Received: from immedia.ca by clouso.crim.ca (4.1/SMI-4.1) id AA03423; Tue, 11 Oct 94 14:11:59 EDT Return-Path: Received: by immedia.ca (3.2/2.D) id AA6457; 11 Oct 94 18:07:48 -0500 Date: 11 Oct 94 18:04:00 -0500 From: ALB@immedia.ca Message-Id: <199410111807.AA6457@immedia.ca> To: i18n@dkuug.dk, iso10646@jhuvm.hcf.jhu.edu, sc22@dkuug.dk Cc: 72330.1275@compuserve.com, rick_sutcliffe@twu.ca, alb@share-e.org.uk, bbuckley@agb.royalroads.ca, bealle@torolab6.vnet.ibm.com, cpwg-mail@revcan.ca, gwarren@vnet.ibm.com, ljdickey@math.waterloo.edu, paref@vm1.ulaval.ca, per@bnr.ca, rob@unb.ca, smichell@ncs.dnd.ca X-Charset: ASCII X-Char-Esc: 29 szpak@csi.uottawa.ca Subject: UCS-4 Support already available in IBM's APL2 (all Oper.Systems) ---------- This afternoon in Vienna, we had a very attractive (able to convert the most reluctant C programmers to switch to APL) and excellent presentation by Dr. Jim Brown, from the Santa Teresa IBM lab, on UCS-4 support in APL2. If I understood correctly, APL2 uses UCS-4 internally and all vendors' APLs ^^ communicate using UNICODE (UCS-2). It also allows entering some 30 extended characters in identifiers, a feature now shyly recommended by SC22/WG20 (internationalisation of applications standards and guidelines) for future programming standards. This product plans to allow a more complete set in the near future (SC22/WG20 already produced a list of UCS characters recommended for extended identifiers - last version produced by Keld Simonsen last week in Cupertino, the last meeting of this group). For now, it has internal limitations which will be removed as soon as possible. To communicate on the Internet, APL2 uses its own version of UUENCODE (8 half-lines of APL code compared to 3 and a half pages of C) to first remove the high-order 2 bytes of zeroes (right now UCS-4 only defines the first plane), mark the byte order as the first two octets sent as FEFF, and then uuencode a file. Conversely when it receives FFFE as the first 2 bytes of the uudecoded file, it inverts the octets, add 2 high-order octets of zeroes and that's it. I found this quite clean. Because they had problems with some APL characters that for an end-user are interpreted as ASCII characters (double coding in the UCS) they made the right decision to use, for example the ASCII ASTERISK instead of the STAR. The speaker mentioned this was due to preliminary experience and thoughts and that the decision was hard to make. But this seems also clean and the best decision for the circumstances. In addition the speaker was one of the best I ever heard. The best remedy against jet lag! Alain LaBont Secrtariat du Conseil du trsor Gouvernement du Qubec and SHARE Europe Manager of Standards PS: SHARE Europe to merge with G.U.I.D.E. to become GUIDE SHARE Europe as of January 1st 1995, if members of both organizations decide so tomorrow in Vienna.