9 #=======================================================================
10 # File name: GURMUKHI.TXT
12 # Contents: Map (external version) from Mac OS Gurmukhi
13 # encoding to Unicode 2.1 and later.
15 # Copyright: (c) 1997-2002, 2005 by Apple Computer, Inc., all rights
18 # Contact: charsets@apple.com
22 # c02 2005-Apr-05 Update header comments. Matches internal xml
23 # <c1.1> and Text Encoding Converter 2.0.
24 # b3,c1 2002-Dec-19 Change mappings for 0x91, 0xD5 based on
25 # new decomposition rules. Update URLs,
26 # notes. Matches internal utom<b2>.
27 # b02 1999-Sep-22 Update contact e-mail address. Matches
28 # internal utom<b1>, ufrm<b1>, and Text
29 # Encoding Converter version 1.5.
30 # n02 1998-Feb-05 First version; matches internal utom<n5>,
36 # Apple, the Apple logo, and Macintosh are trademarks of Apple
37 # Computer, Inc., registered in the United States and other countries.
38 # Unicode is a trademark of Unicode Inc. For the sake of brevity,
39 # throughout this document, "Macintosh" can be used to refer to
40 # Macintosh computers and "Unicode" can be used to refer to the
43 # Apple Computer, Inc. ("Apple") makes no warranty or representation,
44 # either express or implied, with respect to this document and the
45 # included data, its quality, accuracy, or fitness for a particular
46 # purpose. In no event will Apple be liable for direct, indirect,
47 # special, incidental, or consequential damages resulting from any
48 # defect or inaccuracy in this document or the included data.
50 # These mapping tables and character lists are subject to change.
51 # The latest tables should be available from the following:
53 # <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/>
55 # For general information about Mac OS encodings and these mapping
56 # tables, see the file "README.TXT".
61 # Three tab-separated columns;
62 # '#' begins a comment which continues to the end of the line.
63 # Column #1 is the Mac OS Gurmukhi code or code sequence
64 # (in hex as 0xNN or 0xNN+0xNN)
65 # Column #2 is the corresponding Unicode or Unicode sequence
66 # (in hex as 0xNNNN or 0xNNNN+0xNNNN).
67 # Column #3 is a comment containing the Unicode name or sequence
68 # of names. In some cases an additional comment follows the
71 # The entries are in two sections. The first section is for pairs of
72 # Mac OS Gurmukhi code points that must be mapped in a special way.
73 # The second section maps individual code points.
75 # Within each section, the entries are in Mac OS Gurmukhi code order.
77 # Control character mappings are not shown in this table, following
78 # the conventions of the standard UTC mapping tables. However, the
79 # Mac OS Gurmukhi character set uses the standard control characters
80 # at 0x00-0x1F and 0x7F.
82 # Notes on Mac OS Gurmukhi:
83 # -------------------------
85 # This is a legacy Mac OS encoding; in the Mac OS X Carbon and Cocoa
86 # environments, it is only supported via transcoding to and from
89 # Mac OS Gurmukhi is based on IS 13194:1991 (ISCII-91), with the
90 # addition of several punctuation and symbol characters. However,
91 # Mac OS Gurmukhi does not support the ATR (attribute) mechanism of
94 # 1. ISCII-91 features in Mac OS Gurmukhi include:
96 # a) Explicit halant and soft halant
98 # A double halant (0xE8 + 0xE8) constitutes an "explicit halant",
99 # which will always appear as a halant instead of causing formation
100 # of a ligature or half-form consonant.
102 # Halant followed by nukta (0xE8 + 0xE9) constitutes a "soft
103 # halant", which prevents formation of a ligature and instead
104 # retains the half-form of the first consonant.
106 # b) Invisible consonant
108 # The byte 0xD9 (called INV in ISCII-91) is an invisible consonant:
109 # It behaves like a consonant but has no visible appearance. It is
110 # intended to be used (often in combination with halant) to display
111 # dependent forms in isolation, such as the RA forms or consonant
114 # c) Extensions for Vedic, etc.
116 # The byte 0xF0 (called EXT in ISCII-91) followed by any byte in
117 # the range 0xA1-0xEE constitutes a two-byte code point which can
118 # be used to represent additional characters for Vedic (or other
119 # extensions); 0xF0 followed by any other byte value constitutes
120 # malformed text. Mac OS Gurmukhi supports this mechanism, but
121 # does not currently map any of these two-byte code points to
124 # 2. Mac OS Gurmukhi additions
126 # Mac OS Gurmukhi adds characters using the code points
127 # 0x80-0x8A and 0x90-0x94 (the latter are some Gurmukhi additions).
129 # 3. Unused code points
131 # The following code points are currently unused, and are not shown
132 # here: 0x8B-0x8F, 0x95-0xA1, 0xA3, 0xAA-0xAB, 0xAE-0xAF, 0xB2,
133 # 0xC7, 0xCE, 0xD0, 0xD2-0xD3, 0xD6, 0xDF-0xE0, 0xE3-0xE4, 0xE7,
134 # 0xEB-0xEF, 0xFB-0xFF. In addition, 0xF0 is not shown here, but it
135 # has a special function as described above.
137 # Unicode mapping issues and notes:
138 # ---------------------------------
140 # 1. Mapping the byte pairs
142 # If the byte value 0xE8 is encountered when mapping Mac OS
143 # Gurmukhi text, then the next byte (if there is one) should be
144 # examined. If the next byte is 0xE8 or 0xE9, then the byte pair
145 # should be mapped using the first section of the mapping table
146 # below. Otherwise, each byte should be mapped using the second
147 # section of the mapping table below.
149 # - The Unicode Standard, Version 2.0, specifies how explicit
150 # halant and soft halant should be represented in Unicode;
151 # these mappings are used below.
153 # If the byte value 0xF0 is encountered when mapping Mac OS
154 # Gurmukhi text, then the next byte should be examined. If there
155 # is no next byte (e.g. 0xF0 at end of buffer), the mapping
156 # process should indicate incomplete character. If there is a next
157 # byte but it is not in the range 0xA1-0xEE, the mapping process
158 # should indicate malformed text. Otherwise, the mapping process
159 # should treat the byte pair as a valid two-byte code point with no
160 # mapping (e.g. map it to QUESTION MARK, REPLACEMENT CHARACTER,
163 # 2. Mapping the invisible consonant
165 # It has been suggested that INV in ISCII-91 should map to ZERO
166 # WIDTH NON-JOINER in Unicode. However, this causes problems with
167 # roundtrip fidelity: The ISCII-91 sequences 0xE8+0xE8 and 0xE8+0xD9
168 # would map to the same sequence of Unicode characters. We have
169 # instead mapped INV to LEFT-TO-RIGHT MARK, which avoids these
172 # 3. Mappings using corporate characters
174 # Mapping the GURMUKHI LETTER SHA 0xD5 presents an interesting
175 # problem. At first glance, we could map it to the single Unicode
178 # However, our goal is that the mappings provided here should also
179 # be able to generate the mappings to maximally decomposed Unicode
180 # by simple recursive substitution of the canonical decompositions
181 # in the Unicode database. We want mapping tables derived this way
182 # to retain full roundtrip fidelity.
184 # Since the canonical decomposition of 0x0A36 is 0x0A38+0x0A3C,
185 # the decomposition mapping for 0xD5 would be identical with the
186 # decomposition mapping for 0xD7+0xE9, and roundtrip fidelity would
189 # We solve this problem by using a grouping hint (one of the set of
190 # transcoding hints defined by Apple).
192 # Apple has defined a block of 32 corporate characters as "transcoding
193 # hints." These are used in combination with standard Unicode characters
194 # to force them to be treated in a special way for mapping to other
195 # encodings; they have no other effect. Sixteen of these transcoding
196 # hints are "grouping hints" - they indicate that the next 2-4 Unicode
197 # characters should be treated as a single entity for transcoding. The
198 # other sixteen transcoding hints are "variant tags" - they are like
199 # combining characters, and can follow a standard Unicode (or a sequence
200 # consisting of a base character and other combining characters) to
201 # cause it to be treated in a special way for transcoding. These always
202 # terminate a combining-character sequence.
204 # The transcoding coding hint used in this mapping table is:
205 # 0xF860 group next 2 characters
207 # Then we can map 0x91 as follows:
208 # 0xD5 -> 0xF860+0x0A38+0x0A3C
210 # We could also have used a variant tag such as 0xF87F and mapped it
212 # 0xD5 -> 0x0A36+0xF87F
214 # 4. Additional loose mappings from Unicode
216 # These are not preserved in roundtrip mappings.
218 # 0A59 -> 0xB4+0xE9 # GURMUKHI LETTER KHHA
219 # 0A5A -> 0xB5+0xE9 # GURMUKHI LETTER GHHA
220 # 0A5B -> 0xBA+0xE9 # GURMUKHI LETTER ZA
221 # 0A5E -> 0xC9+0xE9 # GURMUKHI LETTER FA
223 # 0A70 -> 0xA2 # GURMUKHI TIPPI
225 # Loose mappings from Unicode should also map U+0A71 (GURMUKHI ADDAK)
226 # followed by any Gurmukhi consonant to the equivalent ISCII-91
227 # consonant plus halant plus the consonant again. For example:
229 # 0A71+0A15 -> 0xB3+0xE8+0xB3
230 # 0A71+0A16 -> 0xB4+0xE8+0xB4
233 # Details of mapping changes in each version:
234 # -------------------------------------------
236 # Changes from version b02 to version b03/c01:
238 # - Change mapping of 0x91 from 0xF860+0x0A21+0x0A3C to 0x0A5C GURMUKHI
239 # LETTER RRA, now that the canonical decomposition of 0x0A5C to
240 # 0x0A21+0x0A3C has been deleted
242 # - Change mapping of 0xD5 from 0x0A36 GURMUKHI LETTER SHA to
243 # 0xF860+0x0A38+0x0A3C, now that a canonical decomposition of 0x0A36
244 # to 0x0A38+0x0A3C has been added.
248 0x00 - 0x7F = 0x0000 -
305 #0xD5 = 0xF860+0x0A38+0x0A3C
319 #0xE8+0xE8 = 0x0A4D+0x200C
320 #0xE8+0xE9 = 0x0A4D+0x200D