From crs@crs.cl.msu.edu Thu Apr 27 14:08:17 1995 Received: from crs.cl.msu.edu by dkuug.dk with SMTP id AA29770 (5.65c8/IDA-1.4.4j for ); Fri, 28 Apr 1995 00:08:07 +0200 Received: by crs.cl.msu.edu (5.65/MSU-2.08A) id AA07277; Thu, 27 Apr 1995 18:08:17 -0400 Date: Thu, 27 Apr 1995 18:08:17 -0400 From: Charles Severance Message-Id: <9504272208.AA07277@crs.cl.msu.edu> To: SC22WG15@dkuug.dk Subject: Comments on WG15 Action Item 9410-24 (Canadien questions) X-Charset: ASCII X-Char-Esc: 29 This document is from the IEEE P1003.2 Working Group in response to WG15 Action Item A9410-24. This is being mailed to the cpwg mailing list as well as the entire WG15 mailing list. Charles Severance (crs@msu.edu)) Secretary, WG15 US TAG IEEE P1003.2 N269 April 26, 1995 Page 1 of 2 SC22/WG15 US TAG N520 Topic: Response to SC22/WG15 Action Item A9410-24 From: Donald W. Cragun I apologize for the delay in this response. The first draft containing full text of the changes for this proposal was not printed until last week. The questions submitted by Canada with our responses are below: 1) a) Could the US present the precise format of the proposed new charmap file? Draft 10.9 will be available from the US delegation at the Enschede meeting. Draft 11 will be distributed for concurrent registration and ballot soon. b) Specifically, could the US explain the relationship of the new proposed field to the portion of each line that is now considered "comment" or explanatory material? The proposal does not include a new field. If just allows two additional forms for specifying the part of the the existing forms. The portion of the lines between CHARMAP and END CHARMAP are not changed. c) Has the been used to delimit RHS comments (i.e. those comments that do not start at the beginning of the line)? Empty lines and lines starting with the are comments. The field can contain any characters (within the context of a line in a text file). Comments are separated from the by one or more characters. A could be used after the required as a convention to make the charmap files easier to read by humans, but are not required by the current standard or the proposed changes. 2) a) Could the US explain the need for the addition of a new parameter to the localedef utility? The new option (-u code_set_name), specifies the name of a code set to be used as the target mapping of character symbols and collating element symbols whose encodings are defined in terms of ISO 10646 position constant values. IEEE P1003.2 N269 April 26, 1995 Page 2 of 2 SC22/WG15 US TAG N520 b) Would not a similar effect be achieved by manipulating the charmap with the standard text utilities and then using the existing localedef utility? None of the other standard utilities specified in 9945-2 (even the iconv utility in P1003.2b) is designed to translate from ISO 10646 16- or 32-bit values encoded as strings of the form or to octal, decimal, or hexadecimal encodings of the forms expected in charmap files by localedef. Scripts could be created using awk or sed to perform these translations manually, but the P1003.2 working group believes that implementations should be able to translate from 10646 to codesets supported by the implementation without manual assistance. 3) a) Could the US explain what is meant by "... have localedef predefine mappings for the standard symbolic names for characters in the character set defined by 9945-2 Section 2.4"? Canada is aware that 9945-2 specifies standard symbolic names for the characters referenced in Section 2.4. Canada's question relates to the "... localedef predefine mappings ...". Since the 10646 encodings for all of the characters in Table 2-4 in section 2.4 of 9945-2 are always the same, they need not be specified in charmap files that are encoded using the new formats; localedef will be required to supply the encoding information using the values specified in Table 2-4 implicitly.