ISO/IEC JTC 1/SC 2 N 3252
DATE: 1999-02-12
ISO/IEC JTC 1/SC 2
Coded Character Sets
Secretariat: Japan (JISC)
|
DOC TYPE: |
Summary of Voting/Table of Replies
|
TITLE:
|
Summary of Voting on SC 2 N 3210, Combined PDAM
registration and consideration ballot on WD for 10646-1/Amd. 30, Information
technology - Universal Multiple-Octet Coded Character Set (UCS) - Part
1: Architecture and Basic Multilingual Plane -- AMENDMENT 30: Additonal
Latin and other characters |
SOURCE:
|
Secretariat, ISO/IEC JTC 1/SC 2 |
PROJECT:
|
JTC 1.02.18.01.30* |
STATUS:
|
1) PDAM Registration: Approved. 2) PDAM Consideration:
This document is forwarded to WG 2 for consideration. WG 2 is requested
to prepare a disposition of comments report, revised text and a recommendation
to the SC 2 Secretariat for further processing. |
ACTION ID: |
ACT |
DUE DATE: |
|
DISTRIBUTION: |
P, O and L Members of ISO/IEC JTC 1/SC 2
WG Conveners, Secretariats
ISO/IEC JTC 1 Secretariat
ISO/IEC ITTF
|
NO. OF PAGES: |
6 |
ACCESS LEVEL: |
Defined |
WEB ISSUE #: |
042 |
Secretariat ISO/IEC JTC 1/SC 2 - Toshiko KIMURA
IPSJ/ITSCJ (Information Processing Society of Japan/Information
Technology Standards Commission of Japan)*
Room 308-3, Kikai-Shinko-Kaikan Bldg., 3-5-8, Shiba-Koen,
Minato-ku, Tokyo 105 JAPAN
Tel: +81 3 3431 2808; Fax: +81 3 3431 6493; E-mail: kimura@itscj.ipsj.or.jp;
http://www.dkuug.dk/jtc1/sc2
*A Standard Organization accredited by JISC
Summary of Voting on SC 2 N 3210
|
PDAM Registration |
PDAM Consideration |
|
P-member |
Approve |
Approve with Comments |
Disapprove |
Abstain |
Approve |
Approve with Comments |
Disapprove |
Abstain |
Comment |
Armenia* |
|
|
|
|
|
|
|
|
|
Australia |
X
|
|
|
|
X
|
|
|
|
|
Austria |
|
|
|
|
|
|
|
|
|
Belgium |
|
|
|
|
|
|
|
|
|
Brazil |
|
|
|
|
|
|
|
|
|
Canada |
X
|
|
|
|
X
|
|
|
|
|
China |
|
|
|
|
|
|
|
|
|
Denmark |
X
|
|
|
|
X
|
|
|
|
|
Egypt |
X
|
|
|
|
X
|
|
|
|
|
Ethiopia |
|
|
|
|
|
|
|
|
|
Finland |
X
|
|
|
|
X
|
|
|
|
|
France |
|
|
|
|
|
|
|
|
|
Germany |
X
|
|
|
|
X
|
|
|
|
|
Greece |
X
|
|
|
|
X
|
|
|
|
|
Iceland |
|
|
|
|
|
|
|
|
|
India |
|
|
|
|
|
|
|
|
|
Iran, Islamic Republic
of |
|
|
|
|
|
|
|
|
|
Ireland |
X
|
|
|
|
|
|
X
|
|
Att.1 |
Israel |
|
X
|
|
|
|
X
|
|
|
Att.2 |
Italy |
|
|
|
|
|
|
|
|
|
Japan |
X
|
|
|
|
X
|
|
|
|
|
Korea Rep. Of |
X
|
|
|
|
X
|
|
|
|
|
Morocco |
|
|
|
|
|
|
|
|
|
Netherlands |
X
|
|
|
|
X
|
|
|
|
|
Norway |
X
|
|
|
|
X
|
|
|
|
|
Poland |
X
|
|
|
|
X
|
|
|
|
|
Romania |
|
|
|
|
|
|
|
|
|
Singapore |
|
|
|
|
|
|
|
|
|
Slovenia |
|
|
|
|
|
|
|
|
|
Sweden |
|
X
|
|
|
|
X
|
|
|
Att.3 |
Thailand |
|
|
|
|
|
|
|
|
|
Tunisia |
X
|
|
|
|
X
|
|
|
|
|
Turkey |
|
|
|
|
|
|
|
|
|
UK |
X
|
|
|
|
|
X
|
|
|
Att.4 |
USA |
X
|
|
|
|
|
X
|
|
|
Att.6 |
Viet Nam |
|
|
|
|
|
|
|
|
|
Yugoslavia |
|
|
|
|
|
|
|
|
|
|
16
|
2
|
0
|
0
|
13
|
4
|
1
|
0
|
|
Total |
18
|
0
|
0
|
17
|
1
|
0
|
|
O-Member |
Portugue |
X
|
|
|
|
X
|
|
|
|
|
Russian Federation |
X
|
|
|
|
X
|
|
|
|
|
Attachment 1 - Ireland
See 02n32521.pdf
Attachment 2 - Israel
Israel votes Yes provided that the relevant (*) national body/bodies
also approve -otherwise our vote is ABSTAIN.
Attachment 3 - Sweden
The Vote is on condition of approval from the countries concerned.
Attachment 4 - UK
UK COMMENTS ACCOMPANYING VOTE OF APPROVAL ON ISO/IEC 10646-1/PDAM30,
ADDITIONAL LATIN AND OTHER CHARACTERS
The UK approves the PDAM in SC2 N 3210 with the following comments.
Editorial comments:
Page 5: In the entry for page 701, the code position numbers
should be 0488 and 0489, as on page 1.
Page 6: The text of the entries for Annex P should be reworded
as -
01A6 LATIN LETTER YR
This character is the capital letter form of: 0280 LATIN LETTER
SMALL CAPITAL R.
0280 LATIN LETTER SMALL CAPITAL R
This character is the small letter form of: 01A6 LATIN LETTER
YR.
Justification: This wording is more consistent with existing
entries 0189 and 019F in Annex P.
Attachment 5 - US
December 9, 1998
Ballot: PDAM consideration for ISO/IEC 10646-1:1993 - Amendment 30:
Additional Latin and other characters
Document: SC2 N3210
Comments:
-
The US requests that the comment in item #4 of these comments be
included or that the characters FFF9, FFFA, FFFB be removed.
-
The description in JTC1/SC2/WG2 N1886 of the need for a soft space
in Thai and other languages is correct. However, there is already provision
in ISO/IEC 10646 for such a character: 200B ZERO-WIDTH SPACE. This
character was designed specifically for use at word boundaries in languages
such as Thai that do not use spaces. This is described at a number of places
in the Unicode Standard. Although it is nominally zero-width, as with some
space characters the ZERO-WIDTH space may expand in width when being justified.
To avoid duplicate encoding and confusion among implementors, the US requests
that the SOFT SPACE be withdrawn or a satisfactory explanation of the difference
be given.
-
The glyph shown for U+03DF GREEK SMALL LETTER KOPPA in PDAM 30 uses the
omicron with tail variant. This choice is fine, and matches the glyphs
shown in the relevant source standard, ISO 5428-1984; however, this choice
conflicts with the glyph shown currently in 10646 for U+03DE GREEK CAPITAL
LETTER KOPPA, which uses the sigmoid koppa variant. The U.S. suggests that
the editor note the glyph currently in 10646 is defective and should be
corrected, so that the result of adding U+03DF by Amendment 30 will be
a consistent case pair for these two letters. (This comment should not
be construed as advocating the addition of two more characters for the
sigmoid variants of koppa; the U.S. feels that the question of whether
two more characters are required should be addressed by a separate proposal,
rather than resolution of ballot comments on Amd 30.)
-
These new characters are used in internal processing when out of band information
is associated with a character stream, very similarly to the usage of the
U+FFFC OBJECT REPLACEMENT CHARACTER. However unlike objects hidden by the
latter character, the annotation itself is textual.
The usage of these new characters in plain text interchange is strongly
discouraged without prior agreement between the sender and the receiver,
because otherwise the content may be misinterpreted. Simply filtering out
these new characters on input will produce an unreadable result, or even
worse, an opposite meaning.
On input a plain text receiver should either preserve all characters,
or remove the interlinear annotation characters as well as the annotation
text included between the interlinear annotation separator and the interlinear
annotation terminator.
When an output for plain text usage is desired and when the receiver
is unknown to the sender, these interlinear annotation characters should
be removed as well as the annotation text included between the interlinear
annotation separator and the interlinear annotation terminator.
This doesn’t preclude their usage in plain text interchange, but it
requires a prior agreement between the sender and the receiver as for the
interpretation of the annotations.