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:
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:

  1. The US requests that  the comment in item #4 of these comments be included or that the characters FFF9, FFFA, FFFB be removed.
  2. 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.
  3. 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.)
  4. 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.

  5. 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.