INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC 1/SC 2/WG 2

Transcription

1 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC 1/SC 2/WG 2 Title: Source: References: Action: Distribution: Universal Multiple-Octet Coded Character Set (UCS) ISO/IEC JTC 1/SC 2/WG and handling of Defect Reports on Character Names (Replaces N2352, N 2002 and N1876) Ad hoc group on Principles and Procedures (Edited by: V.S. Umamaheswaran) See references section in the document To be considered by SC 2/WG 2 and all potential submitters of proposals for new characters the repertoire of ISO/IEC 10646, and for new collection identifiers ISO/IEC JTC 1/SC 2/WG 2, ISO/IEC JTC 1/SC 2 and Liaison Organisations This document incorporates all updates that have been approved by WG 2 up to meeting M 40 and reflecting changes to clause numbers and Annex numbers in : 2000, and the new : Table of Contents 1. Introduction 3 2. Allocation of New Characters and Scripts Goals for Encoding New Characters into the BMP Character Categories Procedure for Encoding New Characters and Scripts WG 2 Evaluation Procedure 4 3. Handling Defect Reports on Character Names Collection Identification Enumeration of repertoires in other documents Use of Sequence Identifiers 7 5. Work Flow and Stages of Progression Roadmaps Electronic Submissions Format of Character additions in Amendments to On the relative ordering of characters...8 Annex A: Information Accompanying Submissions...9 A.1 Submitter's Responsibilities 9 Annex B: Handling of Defect Reports on Character Names...16 B.1 Principles to be used by WG 2 16 B.2 Some Guidelines for Submitters of Defect Reports: 16 Annex C: Work Flow and Stages of Progression...17 C.1 The UCS workflow 17 C.2 The stages of work: 17 C.3 Examples: 18 Annex D: BMP and Supplementary Planes Allocation Roadmaps...19 D.1 Overview 19 D.2 Guidelines for Roadmap Allotments 20 D.2.1 Block assignment starting on half-row boundary...20 D code position boundary for supplementary planes...20 D.2.3 Empty '00' position in a block...20 D.2.4 Gaps in ranges of assigned code positions...20 Annex E: Request for new collection identifiers...21 Annex F: Formal criteria for disunification...23 F.1 What is disunification? Page 1 of 35

2 F.2 Cost and Benefits 23 F.3 Criteria of analysis 23 F.4 Some Examples of Precedents 24 Annex G: Formal criteria for coding precomposed characters...26 G.1 Criteria 26 G.2 Implications of Normalization on Character Encoding 26 Annex H: Criteria for encoding symbols...28 H.1 Symbols and plain text 28 H.2 The symbol fallacy 28 H.3 Classification 28 H.3.1 Symbols that are part of a notational system...28 H.3.2 Symbols that are not part of a notational system...28 H Legacy symbols...28 H.4 Kinds of symbols found in ISO / Unicode 29 H.5 Discussion 29 H.6 Some criteria that strengthen the case for encoding 29 H.7 Some criteria weaken the case for encoding 30 H.8 Completion of a set 30 H.9 Instability 30 H.10 Perceived Usefulness 31 History of Changes...32 References Page 2 of 35

3 1. Introduction This document is a standing document of ISO/IEC JTC 1/SC 2 WG 2. It consists of a set of Principles and Procedures on a number of items relevant to the preparation, submission and handling of proposals for additions of characters to the repertoire of the standard (ISO/IEC and the Unicode standard). The document also contains procedures and guidelines for adding new collection identifiers to the standard. Submitters should check the standard documents (including all the amendments and corrigenda) first before preparing new proposals. Submitters are also encouraged to contact the convener of WG 2 (and the chair of the Unicode Technical Committee) to check and compare any similar proposals that may already have been considered earlier. 2. Allocation of New Characters and Scripts Annex D on page 9 details roadmaps for allocation of characters in the basic and supplementary planes -- Basic Multilingual plane (Plane0 -- BMP), Plane 1 SMP for Scripts and Symbols, Plane 2 SIP for Ideographs, and Plane 14 SSP for Special Purpose characters. The following sections describe the principles and procedures to be used for assessing whether a proposed script or character(s) could be a candidate for inclusion in the standard, and whether it should be encoded in the BMP or in the supplementary planes. 2.1 Goals for Encoding New Characters into the BMP A. The Basic Multilingual Plane should contain all contemporary characters in common use: Generally, the Basic Multilingual Plane (BMP) should be devoted to high-utility characters that are widely implemented in information technology and communication systems. These include, for example, characters from hard copy publishing systems that are awaiting computerization, and characters recognizable and useful to a large community of customers. The "utility" of a character in a computer or communications standard can be measured (at least in theory) by such factors as: number of publications (for example, newspapers or books) using the character, the size of the community who can recognize the character, etc. Characters of more limited use should be considered for encoding in supplementary planes, for example, obscure archaic characters. B. The characters encoded into the Basic Multilingual Plane will not cover all characters included in future standards: It is not necessary, though it may often be desirable, that all characters encoded in future international, national, and industry information technology and communication standards are included in the BMP. The first edition used characters from pre-existing standards as a means of evaluating the established utility as well as ensuring compatibility with existing practice. Characters encoded in future standards may or may not have proven utility, and may or may not establish themselves in common use. 2.2 Character Categories WG 2 will use the following categories to aid in assessing the encoding of the proposed characters. A Contemporary There exists a contemporary community of native users who produce new printed matter with the proposed characters in newspapers, magazines, books, signs, etc. Examples include Myanmar (Burmese), Thaana (Maldivian), Syriac, Yi, Xishuang Banna Dai 1. B.1 Specialized (Small Collections of Characters) The characters are part of a relatively small set. There exists a limited community of 1 Since the writing of this initial set of principles and procedures several scripts proposed following these guidelines have been reviewed and included in the second edition of the standard Page 3 of 35

4 users (for example, ecclesiastical) who produce new printed material with these proposed characters. Generally, these characters have few native users, or are not in day-to-day use for ordinary communication. Examples include Javanese and Pahlavi. B.2 Specialized (Large Collections of Characters) The characters are part of a relatively large set. There exists a limited community of users (for example, ecclesiastical) who produce new printed material with these proposed characters. Generally, these characters have few native users, or are not in day-to-day use for ordinary communication. Examples include personal name ideographs, Chu Nom, and Archaic Han. C Major Extinct (Small Collections of Characters) The characters are part of a relatively small set. There exists a relatively large body of literature using these characters, and a relatively large scholarly community studying that literature. Examples include Old Italic and Linear B. D Attested Extinct (Small Collections of Characters) The characters are part of a relatively small set. There exists a relatively limited literature using these characters and a relatively small scholarly community studying that literature. Examples include Samaritan and Meroitic. E Minor Extinct The characters are part of a relatively small set. The utility of publicly encoding these characters is open to question 2. Examples are Khotanese and Lahnda. F Archaic Hieroglyphic or Ideographic These characters are part of a large set (for example, 160 or more characters) of hieroglyphic or ideographic characters. In general, for a large character set, it is difficult to obtain information or agreement on the precise membership of the set. Examples include Lolo, Moso, Akkadian, Egyptian Hieroglyphics, Hittite (Luvian), Kitan, Mayan Hieroglyphics, and Jurchin. G Obscure or Questionable Usage Symbols The characters are part of a small or large collection that is not yet deciphered, or not completely understood, or not well attested by substantial literature or the scholarly community. Or they are symbols that are not normally used in in-line text, that are merely drawings, that are used only in two-dimensional diagrams, or that may be composed (such as, a slash through a symbol to indicate forbidden). Examples include Phaistos, Indus, Rongo-rongo, logos, pictures of cows, circuit components, and weather chart symbols. As the standard evolved it was found necessary to provide guidelines on specific aspects of proposals for additional scripts and characters to the standard. See Annex F: Formal criteria for disunification on page 23, Annex G: Formal criteria for coding precomposed characters on page 26, and Annex H: Criteria for encoding symbols on page 28 for three such topics. 2.3 Procedure for Encoding New Characters and Scripts The following defines a procedure with criteria for deciding how to encode new characters in ISO/IEC This procedure shall be used for new scripts only after thorough research into the repertoire and ordering of the characters within the script. See A.1 Submitter's Responsibilities and the attached Proposal Summary Form in Annex A on page WG 2 Evaluation Procedure In assessing the suitability of a proposed character for encoding, WG 2 shall evaluate the 2 The minor extinct category of characters may be secondary candidates for encoding elsewhere on the BMP, or their limited scholarly communities may wish to encode them in the Private Use Area (PUA). Caution: Use of PUA is by agreement between sending and receiving devices and its content is NOT defined by the standard, and proposals for standardization should not include any of the PUA Page 4 of 35

5 credibility of the submitter and then use the following procedure: 1. Do not encode. a) If the proposed character is a (shape or other) variation of a character already encoded in the standard and therefore may be unified, or b) If the proposed character is a precomposed character and does not pass the formal criteria for coding precomposed characters that is detailed in Annex G on page 26. c) If the proposed character is a presentation form (glyph), variant, or ligature, or d) If the proposed character may be better represented as a sequence of standardized encoded characters, or e) If the proposed character is a non-han character, and leads to disunification with an existing character in the standard, and does not pass the formal criteria for disunification that is detailed in Annex F on page Suggest use of the Private Use Area a) If the proposed character has an extremely small or closed community of customers, or b) If the proposed characters are part of a script that is very complex to implement and the script has not yet been encoded in the standard (the Private Use Area PUA, may be used for test and evaluation). (Note: Use of PUA is not standardized; its use is by agreement between sending and receiving devices, and its use should not be included in any proposal made to the standardization body for consideration.) 3. Encode on a supplementary plane a) If the proposed character is used infrequently, or b) If it is part of a set of characters for which insufficient space is available in the Basic Multilingual Plane. 4. Encode on the Basic Multilingual Plane a) If the proposed character does not fit into one of the previous criteria (1, 2, or 3), and b) If the proposed character is part of a well-defined character collection not already encoded in the standard, or c) If the proposed character is part of a small number of characters to be added to a script already encoded in the Basic Multilingual Plane (for example, the characters can be encoded at unallocated code positions within the block or blocks allocated for that script). 3. Handling Defect Reports on Character Names In principle, the Character Names in the standard are not to be changed. The main purpose of having this international standard is the interoperability of characters of all the world scripts represented by their assigned code points. Within each language version of the standard, the names of individual characters must be unique and fixed. When initially assigned the names will be somewhat meaningful to the user community. However, it may be found to have some errors or found to be less satisfactory later on. Once standardized, these names must not be changed. The short identifiers defined in the standard can be used for identifying the standardized characters in a languageindependent manner or between different language versions of the standard. One can view the names in each language version of the standard as unique long identifier of arbitrary character sequences in that language. Even in the English language version of the standard these names may be meaningless to casual readers of the standard. Such long identifiers are used to establish correspondences with names of characters in other character collections or standards in the same (and sometimes in a different) language. The English language version, which is developed in SC 2/ WG 2, is also the reference document from which other language versions are created. This makes the invariance of names in the English version even more mandatory. Translated versions are generated by groups other than SC 2/WG 2 for example, the Canadian and French national bodies helped ITTF create the French language version of Page 5 of 35

6 If the names in the English language version of the standard are not suitable for clarity or accuracy for non-english users, these names can be translated in non-english versions of the standard, or in technical supplements in other languages. However, in all cases technical equivalence with the English version of the standard must be maintained from the viewpoint of all normative aspects of the standard including most importantly the interoperability of code points assigned to the characters. There may be situations where annotations to names of characters in the English version of the standard may be warranted. Requests for such annotations to character names may be made by submitting a defect report. The principles of dealing with such defect reports by SC 2/WG 2 are described in Annex B on page Collection Identification The second edition of the standard ISO/IEC : 2000 defines collections (clause 4.11 collection; and clause 4.19 fixed collection). A collection is a set of coded characters which is numbered and named and which consists of those coded characters whose code positions lie within one or more identified ranges. Note: If any of the identified ranges include code positions to which no character is allocated, the repertoire of the collection will change if an additional character is assigned in the standard to any of these positions in the future. However, it is intended that the collection number and name will remain unchanged in future editions of this International Standard. The intent is to require a new collection identifier when that new collection either involves an expansion of identified range(s) or addition of new range(s) compared with an existing collection. Implementations may have associated a collection identifier using the outer bounds of defined ranges for an existing collection, and an expansion or addition of new ranges can negatively impact such an implementation. A fixed collection is a collection in which every code position within the identified range(s) has a character allocated to it, and which is intended to remain unchanged in future editions of this International Standard -- in other words, the repertoire remains fixed. A number of collections -- some marked as fixed collections with an asterisk (*) in the positions column -- are defined in Annex A of ISO/IEC and Annex A of ISOIEC WG 2 has accepted (per resolution M34.18) the following recommendations from the ad hoc on collection identifiers at WG 2 meeting 34 (see N1726 dated ): a) Annex A in Part 1 will be the home for all collection identifiers and their names for collections that are entirely within Part 1 (BMP) or span both Part 1 and Part 2 (BMP and supplementary planes) of ISO/IEC b) Annex A in Part 1 will mark a block of numbers in it as reserved for identifying collections that are entirely within Part 2 (supplementary planes) of ISO/IEC c) An Annex in Part 2 should be created, similar to Annex A in Part 1, containing the list of collection identifiers, collection names for collections that are entirely within Part 2. Also, some text should be added in this Annex to refer the readers to Annex A in Part 1 for the other collection identifiers in the standard. A collection identifier and a collection name are usually assigned whenever a new script is added to the standard. A collection could be referenced in an application by its identifier or as a collection of collections by enumerating the collection identifiers or collection names. However, there may be situations where an application needs a single identifier for a specific collection, and the required collection is not readily identified in the standard, or a reference to the required collection by an enumeration of standardized collections is not acceptable. Annex E on page 21 provides a format and guidelines for requesting new collection identifiers in the standard Page 6 of 35

7 4.1 Enumeration of repertoires in other documents There may be a need to enumerate a repertoire of characters in different documents such as national standards, resource definition documents or others. Such an enumeration can be in the form of: a listing of a sequence of one or more ranges of short identifiers (as defined in clause 6.5 in the standard), or a listing in the form of identifiers of one or more standardized collections, or a combination of the above in the form of a list of one or more collection identifiers and a list of one or more ranges of short identifiers for the characters either removed from that collection or added to the listed collections 4.2 Use of Sequence Identifiers Where there is a need to identify a sequence of n standardized characters that represents an element of a repertoire, the UCS Sequence Identifier (USI) (defined in a new clause 6.6 see PDAM1 to : 2000, Item 5, in document JTC 1/SC 2 N 3503 of December 2000) should be used. The format of the UCS Sequence Identifier is: <UID1, UID2 UIDn>, where UIDs are the short identifiers for the characters in the same order as those characters appear in the sequence. Note that the USIs will not appear in any subsets of the standard and hence will not appear in any specified collections in the standard. Use of a combination of short identifiers, the collection identifiers, and UCS sequence identifiers in the manner described above provides a language-neutral way of enumerating a specific repertoire of characters. 5. Work Flow and Stages of Progression To give the submitters of proposals for new scripts an understanding of how WG 2 deals with a proposal from its initiation to completion, Annex C on page 17 contains a description of the work flow and the various stages of progression of submissions to WG Roadmaps A summary of the scripts and characters that have been included in the standard, and known scripts which are either work in progress in WG 2 (for which some initial discussion documents have been made available to WG 2), or scripts which are known for future possible inclusion in the standard but have not matured are addressed in Annex D on page 19. This Annex points to a number of WG 2 standing roadmap documents, which will be updated to reflect the set of scripts that have reached at least the stage of PDAM balloting (equivalent of accepted CD for balloting) and will track that script to its publication in terms of the number of code positions allocated to that script / proposed characters. An indication of which scripts are under consideration is also included. 7. Electronic Submissions Contributions for consideration by WG 2 (and to the Unicode Technical Committee) should be made in electronic form. The preferred formats are Word.DOC, or printable.pdf formats, with unprotected text portions and possibly copyrighted font portions. Whereas, files could be ZIP -ped for compressing them, it should be noted that.exe files may not be accepted in many organizations as part of their Security Policy and self-extracting.exe files should be avoided. 8. Format of Character additions in Amendments to Per resolution M39.23, WG2 has resolved that the format for amendments that involve character additions will be in the form of complete replacements of tables and character name lists where they exist, with an explanatory text listing the code positions to which new characters are assigned. If it is a new block it will be presented as a complete new table and names list Page 7 of 35

8 9. On the relative ordering of characters The standard is multi-lingual. In the process several characters that may be considered as individual characters in different scripts are unified. When scripts were encoded in the standard, while relative ordering of characters within that script is given due consideration, some characters of the script may not have been included for various reasons. However, to ensure stability and interoperability, once a character is assigned a code position in the standard it must not be changed. By definition, ensuring correct ordering of the characters within a script is outside the scope of the standard. ISO/IEC must be used to address the problem of correct ordering of the characters within a script according to the appropriate linguistic or application-specific needs. The Unicode Collation Algorithm (see is in synchronization with ISO/IEC and may be consulted for an algorithm that may be used for achieving the desired ordering of characters Page 8 of 35

9 Annex A: Information Accompanying Submissions The process of deciding which characters should be included in the repertoire of the standard by WG 2 depends on the availability of accurate and most comprehensive information about any proposed additions. WG 2, at its San Francisco meeting 26, designed a form (template) that will assist the submitters in gathering and providing the relevant information, and will assist WG 2 in making more informed decisions. This form is included in the following pages of this annex. A duly completed proposal summary form must accompany each new submission. Such a form will assist WG 2 to better evaluate the proposal, and progress the proposal towards a speedier acceptance and inclusion in the standard. Submitters are also requested to ensure that a proposed character does not already exist in the standard. If a submission has already been made prior to the existence of the proposal summary form, the submitters are requested to re-evaluate the submission for completeness using the form as a template, and either provide reference(s) to existing information or provide additional information. The status of each submission is tracked in the WG 2 standing document "WG 2 Summary Status of Proposals". A.1 Submitter's Responsibilities The national body or liaison organization (or any other organization or an individual) proposing new character(s) or a new script shall provide: 1. Proposed category for the script or character(s), character name(s), and description of usage. 2. Justification for the category and name(s). 3. A representative glyph(s) image on paper: If the proposed glyph image is similar to a glyph image of a previously encoded ISO/IEC character, then additional justification for encoding the new character shall be provided. Note: Any proposal that suggests that one or more of such variant forms is actually a "distinct" character requiring separate encoding, should provide detailed, printed evidence that there is actual, contrastive use of the variant form(s). It is insufficient for a proposal to claim a requirement to encode "as characters" in the Standard, glyphic forms which happen to occur in another character encoding that did not follow the Character-Glyph Model that guides the choice of appropriate characters for encoding in ISO/IEC Note: WG 2 has resolved in Resolution M38.12 not to add any more Arabic presentation forms to the standard and suggests users to employ appropriate input methods, rendering and font technologies to meet the user requirements. 4. Mappings to accepted sources, for example, other standards, dictionaries, accessible published materials 5. Computerized/camera-ready font: Prior to the preparation of the final text of the next amendment or version of the standard a suitable computerized font (camera-ready font) will be needed. Camera-ready copy is mandatory for final text of any pdams before the next revision. Ordered preference of the fonts is True Type or PostScript format. The minimum design resolution for the font is 96 by 96 dots matrix, for presentation at or near 22 points in print size. 6. List of all the parties consulted. 7. Equivalent glyph images: If the submission intends using composite sequences of proposed or existing combining and noncombining characters, a list consisting of each composite sequence and its corresponding glyph image shall be provided to better understand the intended use. 8. Compatibility equivalents: If the submission includes compatibility ideographic characters, identify the equivalent unified CJK Ideograph character(s). 9. Any additional information that will assist in correct understanding of the different characteristics and linguistic processing of the proposed character(s) or script Page 9 of 35

10 ISO/IEC JTC 1/SC 2/WG 2 PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC Please fill all the sections A, B and C below. (Please read Principles and Procedures Document for guidelines and details before filling this form) See for latest Forms. See for latest Principles and Procedures document. See for latest roadmaps. A. Administrative 1. Title: _ 2. Requester's name: 3. Requester type (Member body/liaison/individual contribution): 4. Submission date: _ 5. Requester's reference (if applicable): 6. (Choose one of the following:) This is a complete proposal: _ or, More information will be provided later: _ B. Technical - General 1. (Choose one of the following:) a. This proposal is for a new script (set of characters): Proposed name of script: _. b. The proposal is for addition of character(s) to an existing block: Name of the existing block: 2. Number of characters in proposal: 3. Proposed category (see section II, Character Categories): 4. Proposed Level of Implementation (1, 2 or 3) (see clause 14, ISO/IEC : 2000): Is a rationale provided for the choice? If Yes, reference: 5. Is a repertoire including character names provided? a. If YES, are the names in accordance with the 'character naming guidelines in Annex L of ISO/IEC : 2000? b. Are the character shapes attached in a legible form suitable for review? 6. Who will provide the appropriate computerized font (ordered preference: True Type, or PostScript format) for publishing the standard? If available now, identify source(s) for the font (include address, , ftp-site, etc.) and indicate the tools used: _ 7. References: a. Are references (to other character sets, dictionaries, descriptive texts etc.) provided? b. Are published examples of use (such as samples from newspapers, magazines, or other sources) of proposed characters attached? 8. Special encoding issues: Does the proposal address other aspects of character data processing (if applicable) such as input, presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information)? _ 9. Additional Information: Submitters are invited to provide any additional information about Properties of the proposed Character(s) or Script that will assist in correct understanding of and correct linguistic processing of the proposed character(s) or script. Examples of such properties are: Casing information, Numeric information, Currency information, Display behaviour information such as line breaks, widths etc., Combining behaviour, Spacing behaviour, Directional behaviour, Default Collation behaviour, relevance in Mark Up contexts, Compatibility equivalence and other Unicode normalization related information. See the Unicode standard at for such information on other scripts. Also see and associated Unicode Technical Reports for information needed for consideration by the Unicode Technical Committee for inclusion in the Unicode Standard. 3 Form number: N2352-F (Original ; Revised , , , , , ) Page 10 of 35

11 C. Technical - Justification 1. Has this proposal for addition of character(s) been submitted before? If YES explain 2. Has contact been made to members of the user community (for example: National Body, user groups of the script or characters, other experts, etc.)? If YES, with whom? If YES, available relevant documents? 3. Information on the user community for the proposed characters (for example: size, demographics, information technology use, or publishing use) is included? Reference: 4. The context of use for the proposed characters (type of use; common or rare) Reference: 5. Are the proposed characters in current use by the user community? If YES, where? Reference: 6. After giving due considerations to the principles in "Principles and Procedures" document (a WG 2 standing document) must the proposed characters be entirely in the BMP? If YES, is a rationale provided? If YES, reference: 7. Should the proposed characters be kept together in a contiguous range (rather than being scattered)? 8. Can any of the proposed characters be considered a presentation form of an existing character or character sequence? If YES, is a rationale for its inclusion provided? If YES, reference: 9. Can any of the proposed characters be encoded using a composed character sequence of either existing characters or other proposed characters? If YES, is a rationale for its inclusion provided? If YES, reference: 10. Can any of the proposed character(s) be considered to be similar (in appearance or function) to an existing character? If YES, is a rationale for its inclusion provided? If YES, reference: 11. Does the proposal include use of combining characters and/or use of composite sequences (see clauses 4.12 and 4.14 in ISO/IEC : 2000)? If YES, is a rationale for such use provided? If YES, reference: Is a list of composite sequences and their corresponding glyph images (graphic symbols) provided? If YES, reference: 12. Does the proposal contain characters with any special properties such as control function or similar semantics? If YES, describe in detail (include attachment if necessary) 13. Does the proposal contain any Ideographic compatibility character(s)? If YES, is the equivalent corresponding unified ideographic character(s) identified? If YES, reference: Page 11 of 35

12 ISO/IEC JTC 1/SC 2/WG 2 PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC Please fill all the sections A, B and C below. (Please read Principles and Procedures Document for guidelines and details before filling this form) See for latest Forms. See for latest Principles and Procedures document. See ww/dkuug.dk/jtc1/wg2/roadmaps for latest roadmaps. A. Administrative 1. Title: Braille 2. Requester's name: Kohji Shibano, Japan 3. Requester type (Member body/liaison/individual contribution): Individual Contribution 4. Submission date: Requester's reference (if applicable): J2-94-xy 6. (Choose one of the following:): This is a complete proposal: or, More information will be provided later: Yes B. Technical - General 1. (Choose one of the following:) a. This proposal is for a new script (set of characters): Yes Proposed name of script: Braille. b. The proposal is for addition of character(s) to an existing block: No Name of the existing block: 2. Number of characters in proposal: Proposed category (see section II, Character Categories): A 4. Proposed Level of Implementation (1, 2 or 3) (see clause 14, ISO/IEC : 2000): 1 Is a rationale provided for the choice? No If Yes, reference: 5. Is a repertoire including character names provided? Yes a. If YES, are the names in accordance with the 'character naming guidelines in Annex L of ISO/IEC : 2000? No (will provide) b. Are the character shapes attached in a legible form suitable for review? Yes 6. Who will provide the appropriate computerized font (ordered preference: True Type, or PostScript format) for publishing the standard? Japan If available now, identify source(s) for the font (include address, , ftp-site, etc.) and indicate the tools used: IBM Japan (ftp://ifi.jp/pub/font) 7. References: a. Are references (to other character sets, dictionaries, descriptive texts etc.) provided? ISO TC 173 b. Are published examples of use (such as samples from newspapers, magazines, or other sources) of use of proposed characters attached? No (will provide) 8. Special encoding issues: Does the proposal address other aspects of character data processing (if applicable) such as input, presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information)? No 9. Additional Information: Submitters are invited to provide any additional information about Properties of the proposed Character(s) or Script that will assist in correct understanding of and correct linguistic processing of the proposed character(s) or script. Examples of such properties are: Cas ing information, Numeric information, Currency information, Display behaviour information such as line breaks, widths etc., Combining behaviour, Spacing behaviour, Directional behaviour, Default Collation behaviour, relevance in Mark Up contexts, Compatibility equivalence and other Unicode normalization related information. See the Unicode standard at for such information on other scripts. Also see and associated Unicode Technical Reports for information needed for consideration by the Unicode Technical Committee for inclusion in the Unicode Standard. 4 Form number: N2352-F (Original ; Revised , , , , , ) 5 The date of this example is retained as originally created even though the form has been revised since that date Page 12 of 35

13 C. Technical - Justification 1. Has this proposal for addition of character(s) been submitted before? No If YES explain 2. Has contact been made to members of the user community (for example: National Body, user groups of the script or characters, other experts, etc.)? If YES, with whom? If YES, available relevant documents? 3. Information on the user community for the proposed characters (for example: size, demographics, information technology use, or publishing use) is included? Reference: People with impaired vision (info will be provided) 4. The context of use for the proposed characters (type of use; common or rare) Common Reference: on-line database services for Braille-translated text (e.g. www: braille.dknet.dk) 5. Are the proposed characters in current use by the user community? Yes If YES, where? Reference: No Worldwide 6. After giving due considerations to the principles in "Principles and Procedures" document (a WG 2 standing document) must the proposed characters be entirely in the BMP? Yes If YES, is a rationale provided? If YES, reference: 7. Should the proposed characters be kept together in a contiguous range (rather than being scattered)? Yes 8. Can any of the proposed characters be considered a presentation form of an existing character or character sequence? If YES, is a rationale for its inclusion provided? If YES, reference: 9. Can any of the proposed characters be encoded using a composed character sequence of either existing characters or other proposed characters? If YES, is a rationale for its inclusion provided? If YES, reference: 10. Can any of the proposed character(s) be considered to be similar (in appearance or function) to an existing character? If YES, is a rationale for its inclusion provided? If YES, reference: 11. Does the proposal include use of combining characters and/or use of composite sequences (see clauses 4.12 and 4.14 in ISO/IEC : 2000)? If YES, is a rationale for such use provided? If YES, reference: Is a list of composite sequences and their corresponding glyph images (graphic symbols) provided? If YES, reference: 12. Does the proposal contain characters with any special properties such as control function or similar semantics? If YES, describe in detail (include attachment if necessary) 13. Does the proposal contain any Ideographic compatibility character(s)? No If YES, is the equivalent corresponding unified ideographic character(s) identified? If YES, reference: No No No No No Page 13 of 35

14 ISO/IEC JTC 1/SC 2/WG 2 PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONS FOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC Please fill all the sections A, B and C below. (Please read Principles and Procedures Document for guidelines and details before filling this form) See for latest Forms. See for latest Principles and Procedures document. See for latest roadmaps. A. Administrative 1. Title: Addition of two Latin characters 2. Requester's name: Danish Standards Association 3. Requester type (Member body/liaison/individual contribution): NB 4. Submission date: Requester's reference (if applicable): 6. (Choose one of the following:) This is a complete proposal: Yes or, More information will be provided later: B. Technical - General 1. (Choose one of the following:) a. This proposal is for a new script (set of characters): No Proposed name of script:. b. The proposal is for addition of character(s) to an existing block: Yes Name of the existing block: Table 4 - Row 01: Latin Extended-B 2. Number of characters in proposal: 2 3. Proposed category (see section II, Character Categories): A 4. Proposed Level of Implementation (1, 2 or 3) (see clause 14, ISO/IEC : 2000): 1 Is a rationale provided for the choice? If Yes, reference: 5. Is a repertoire including character names provided? Yes a. If YES, are the names in accordance with the 'character naming guidelines in Annex L of ISO/IEC : 2000? Yes b. Are the character shapes attached in a legible form suitable for review? Yes 6. Who will provide the appropriate computerized font (ordered preference: True Type, or PostScript format) for publishing the standard? Michael Everson, Everson Gunn Teoranta If available now, identify source(s) for the font (include address, , ftp-site, etc.) and indicate the tools used: Michael Everson, Everson Gunn Teoranta 7. References: a. Are references (to other character sets, dictionaries, descriptive texts etc.) provided? Yes b. Are published examples of use (such as samples from newspapers, magazines, or other sources) of proposed characters attached? Yes 8. Special encoding issues: Does the proposal address other aspects of character data processing (if applicable) such as input, presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information)? Specifications enclosed 9. Additional Information: Submitters are invited to provide any additional information about Properties of the proposed Character(s) or Script that will assist in correct understanding of and correct linguistic processing of the proposed character(s) or script. Examples of such properties are: Casing information, Numeric information, Currency information, Display behaviour information such as line breaks, widths etc., Combining behaviour, Spacing behaviour, Directional behaviour, Default Collation behaviour, relevance in Mark Up contexts, Compatibility equivalence and other Unicode normalization related information. See the Unicode standard at for such information on other scripts. Also see and associated Unicode Technical Reports for information needed for consideration by the Unicode Technical Committee for inclusion in the Unicode Standard. 6 Form number: N2352-F (Original ; Revised , , , , , ) 7 The date of this example is retained as originally created even though the form has been revised since that date Page 14 of 35

15 C. Technical - Justification 1. Has this proposal for addition of character(s) been submitted before? No If YES explain 2. Has contact been made to members of the user community (for example: National Body, user groups of the script or characters, other experts, etc.)? Yes If YES, with whom? Irish National Body, Oxford University If YES, available relevant documents? 3. Information on the user community for the proposed characters (for example: size, demographics, information technology use, or publishing use) is included? Enclosed Reference: 4. The context of use for the proposed characters (type of use; common or rare) Rare Reference: The Community of Gothic and Medieval English Literature 5. Are the proposed characters in current use by the user community? Yes If YES, where? Reference: Scholar Communities 6. After giving due considerations to the principles in "Principles and Procedures" document (a WG 2 standing document) must the proposed characters be entirely in the BMP? Yes If YES, is a rationale provided? Yes If YES, reference: Enclosed 7. Should the proposed characters be kept together in a contiguous range (rather than being scattered)? No 8. Can any of the proposed characters be considered a presentation form of an existing character or character sequence? If YES, is a rationale for its inclusion provided? If YES, reference: 9. Can any of the proposed characters be encoded using a composed character sequence of either existing characters or other proposed characters? If YES, is a rationale for its inclusion provided? If YES, reference: 10. Can any of the proposed character(s) be considered to be similar (in appearance or function) to an existing character? If YES, is a rationale for its inclusion provided? If YES, reference: 11. Does the proposal include use of combining characters and/or use of composite sequences (see clauses 4.12 and 4.14 in ISO/IEC : 2000)? If YES, is a rationale for such use provided? If YES, reference: Is a list of composite sequences and their corresponding glyph images (graphic symbols) provided? If YES, reference: 12. Does the proposal contain characters with any special properties such as control function or similar semantics? If YES, describe in detail (include attachment if necessary) 13. Does the proposal contain any Ideographic compatibility character(s)? If YES, is the equivalent corresponding unified ideographic character(s) identified? If YES, reference: Yes No No No No No No Page 15 of 35

16 Annex B: Handling of Defect Reports on Character Names Since the publication of ISO/IEC in May 1993, WG2 has received several defect reports requesting changes to character names. In principle, the names in the standard are not to be changed. However, there may be situations where an annotation to the character name may be warranted. B.1 Principles to be used by WG 2 The following paragraphs describe the principles of dealing with defect reports on character names: A. Explanatory information in Annex P, Additional Information on Characters of the standard: If WG 2 decides that the request is justified, WG 2 will first consider accommodating the request by adding explanatory text to Annex P of the standard. B. Non-normative parenthetic annotation of the name: If WG 2 considers that the request falls within the guidelines of Rule 12 in Annex K - Character naming guidelines in the standard, then an appropriate annotation will be added to the character name. C. In instances where a name change causes a potential problem for compliance by implementations of existing standard, and if the concern expressed in the defect report may be handled with a simple explanatory note, a note may be added. D. Deprecation: If WG 2 considers that the character identified in the defect report should not have been in the standard, for reasons such as duplication, or incorrect inclusion in a block, then that coded character will be marked with the annotation "(deprecated character)" after its name. Note, however, that the character will never be removed from the standard. E. Reject: In all other situations, where WG 2 considers that the request is not sufficiently justified or none of the above-mentioned measures is warranted, the defect report will be rejected with an explanation. B.2 Some Guidelines for Submitters of Defect Reports: As a supplement to the above information on dealing with defect reports, the submitters can assist the working group by following the guidelines given below: a) report all defects associated with characters from the same block or set of characters as a single defect report (for example, use a single one for all defects from within a character block such as Malayalam), instead of one for each character. b) avoid including defective characters from different character blocks or sets in the same report. c) please check if the defect has already been reported by some one else or considered earlier by WG 2. Copies of the dispositions of prior defect reports can be obtained from the SC 2 Secretariat. d) if one or more new character(s) - with their own new name and glyph - is proposed to be added in conjunction with a defect report, please submit the addition requests separate from the defect report along with the Proposal Summary Form for the new characters Page 16 of 35

17 Annex C: Work Flow and Stages of Progression This annex contains a description of the UCS workflow and stages in progression from initial proposal to final publication. C.1 The UCS workflow UCS workflow can be illustrated in a simplified form as follows: Communication to WG 2 and communication inside WG 2 related to populating the standard Communication from WG 2 to the world outside Input Process Output Output From whom What Under meetings Convener Agenda (e.g. N1387) Resolutions SC 2 Ballots (e.g. N1354) JTC 1 ITTF NBs WG experts IRG-group Liaisons Secretary Editor Secretary Editor Input documents: Requests (e.g. N1324) Defect reports (e.g. N1806) Working documents Liaison statements C.2 The stages of work: After meetings What To whom Minutes (e.g. N1353): Action Items Minutes: Action Items Standing documents Types of Documents Standing documents: WG 2 distribution list (e.g. N1351) Document register (e.g. N1300) Summary of WG 2 work (e.g. N1302) Cumulative list of repertoire additions (Buckets) (e.g. N1385) Alphabetic (Arabic, Cyrillic, Hebrew, Latin, etc.) Symbols Ideographs Cumulative list of Corrigenda (editorial, technical) (e.g. N1384) ISO/IEC Corrigendum (e.g. N1396) List of character names and code positions allocated (e.g. N1675) Principles and procedures (e.g. N 1352) Overview of the basic Multilingual Plane (e.g. N1332) Result of request: Acceptance Rejection Editorial corrigenda. Technical corrigenda. (e.g. N1393) Amendments (e.g. N1310) Standards (e.g. ISO/IEC ) Requester SC 2 JTC 1 ITTF IRG How Presentation forms: Paper documents Web site (the WG 2 web site at DKUUG and the IRG web site in HK) Any new proposal for addition of new characters will pass a number of stages from initial proposal to finalized publication. The stages are: Initial proposal Provisional acceptance Final acceptance (Bucket) Hold for ballot This terminology indicates the stage of maturity of the proposal and the WG s confidence in the proposal Page 17 of 35

18 In process within WG 2 Further progression Stage Initial proposal Provisional acceptance Final acceptance (allocation of bucket) Hold for ballot Progression/ Publication status Item 1* Character shapes 2* Character names 3* Code position allocation 4* Text to be included in the standard 5* Font** SC 2 JTC 1 ITTF Ballot Ballot Publication ** 6 Other items from proposal summary form * Items 1 through 5 are mandatory for entering final acceptance stage ** Camera-ready copy is mandatory for stage 7. It is expected that the quality of the fonts will improve to camera-ready quality as the proposal progress trough the various stages. For information on the format of the font see the Proposal summary form. Stages 1 to 3 may contain provisionally allocated code positions. When a proposal enters stage 4 the code positions are final. The contents of the Buckets are reviewed at every meeting to decide whether the content shall progress for balloting (stage 4). The progress of each proposal is recorded in the WG 2 standing document Summary of WG 2 work (the WG 2 standing document in the form of a spreadsheet). When a proposal reaches stage 4 its status is included in List of character names and code positions allocated. C.3 Examples: List of character names and code positions allocated: Code position Status Reference Character name... 20AB 6 N1092 DONG SIGN C LATIN CAPITAL LETTER I WITH BREVE... 00E6 7 N1128 LATIN SMALL LETTER AE (ash)... 1E9B 6 N1132 LATIN SMALL LETTER LONG S WITH DOT ABOVE... FFFC 2 N1365 OBJECT REPLACEMENT CHARACTER WG 2 standing document "Status Summary of WG 2 work items" shows the status of different proposals Page 18 of 35