ISO/IEC SC22/WG15 RIN N169

Japan Action Item Report to WG15/RIN 1996-MAY meeting
=====================================================

						ITCSJ/SC22/POSIX WG
						May, 1996

9510-05 Japan to check if the reference to IS 9899:1995 would satisfy
	their requirements for MSE support in 9945-1, and to report
	their findings back to WG15.

	We found that the reference to IS 9899:1995 (which includes
	Amendment 1) was not enough. The wcwidth()/wcswidth() functions
	defined XPG4 are also necessary to implement POSIX.2.
	To support the MSE function [wctrans()/towctrans()] and the XPG4
	functions [wcwidth()/wcswidth()], IS 9945-2 locale definition
	needs to be extended. One of the extension proposals was included
	in N158. (See the response to 9510-10 below.) The other one is
	already specified in .2b/D11 but needs to be changed. (See the
	response to 9510-14 below.)

9510-08 Rapporteurs to review and respond to the parts of N158 which
	address the LC_COLLATE proposal, with specific attention to
	whether it can be resolved by changes only to the localedef
	specification, or whether changes to the API are required in
	order to handle the proposed localedef extension.

	As an originator, Japan has not revised the proposal in N158.
	We are waiting for the comments from other member bodies.

9510-10 Rapporteurs to review and respond to the Japanese proposal for
	LC_CTYPE extension for locale-specific character mapping in N158.

	This is the proposal mentioned in the response to 9510-05 above.
	Two of the ISO C Amendment functions (wctrans, towctrans)
	requires this extension to behave in a locale dependent way
	on a POSIX system. Japan believes that the proposal is almost
	complete and has no objections.

9510-14 Action on US, Denmark and Japan to consider the proposal in N160
	re the WIDTH... statements, with attention to whether WIDTH...
	should be handled in the locale as in the N160 proposal, or as
	represented in 1003.2b D11.

	Comments from Japan on this subject is attached below.

[END]
=============================================================================
[Attachment: Comments on character width extension to charmap]

Page 9, 2.4.1 Character Set Description File.

Japan objects against the change made in Draft 11 about specification
of display column width.
Although the rationale is available in page 10, the description is not correct.
The character "width" information is independent from codesets, i.e. how the
character is encoded. Kanji characters have width 2 and ASCII characters have
width 1. These values are intrinsic to the characters, not the coded
representation of them. Please also refer to the definition of term
"column position" in ISO 9945-2:1990.

Therefor Japan thinks that the character "width" information matches better
with locale source than charmap. Japan proposes to regain the specification
of Draft 10 for character "width" specification.

Another concern is the introduction of concept of variable width.
The wcwidth function returns useful values only for printing characters
which have intrinsic character width independent from position of a line.
Therefore we cannot use such information from applications. Japan proposes
to remove the specification for variable width.

Excerpt from .2B/D11, Page 10, line 191 - 198

The character "width" information was first considered for inclusion under
LC_CTYPE but was moved because it is more closely associated with the informa-
tion in the charmap than information in the locale source (cultural conventions
information). Concerns were raised that formalizing this type of information is
moving the locale source definition from the codeset independent entity that it
was designed to be to a repository of codeset specific information. A similar issue
occurred with the <code_set_name>, <mb_cur_max>, and <mb_cur_min> infor-
mation, which was resolved to reside in the charmap definition.

[END]