11 #=======================================================================
12 # File name: ARABIC.TXT
14 # Contents: Map (external version) from Mac OS Arabic
15 # character set to Unicode 2.1 and later.
17 # Copyright: (c) 1994-2002, 2005 by Apple Computer, Inc., all rights
20 # Contact: charsets@apple.com
24 # c02 2005-Apr-04 Update header comments. Matches internal xml
25 # <c1.2> and Text Encoding Converter 2.0.
26 # b3,c1 2002-Dec-19 Add comments about character display and
27 # direction overrides. Update URLs, notes.
28 # Matches internal utom<b4>.
29 # b02 1999-Sep-22 Update contact e-mail address. Matches
30 # internal utom<b1>, ufrm<b1>, and Text
31 # Encoding Converter version 1.5.
32 # n10 1998-Feb-05 Show required Unicode character
33 # directionality in a different way. Matches
34 # internal utom<n4>, ufrm<n21>, and Text
35 # Encoding Converter version 1.3. Update
36 # header comments; include information on
37 # loose mapping of digits.
38 # n07 1997-Jul-17 Update to match internal utom<n2>, ufrm<n17>:
39 # Change standard mapping for 0xC0 from U+066D
40 # to U+274A. Add direction overrides to
41 # mappings for 0x25, 0x2C, 0x3B, 0x3F. Add
42 # information on variants.
43 # n03 1995-Apr-18 First version (after fixing some typos).
44 # Matches internal ufrm<n11>.
49 # Apple, the Apple logo, and Macintosh are trademarks of Apple
50 # Computer, Inc., registered in the United States and other countries.
51 # Unicode is a trademark of Unicode Inc. For the sake of brevity,
52 # throughout this document, "Macintosh" can be used to refer to
53 # Macintosh computers and "Unicode" can be used to refer to the
56 # Apple Computer, Inc. ("Apple") makes no warranty or representation,
57 # either express or implied, with respect to this document and the
58 # included data, its quality, accuracy, or fitness for a particular
59 # purpose. In no event will Apple be liable for direct, indirect,
60 # special, incidental, or consequential damages resulting from any
61 # defect or inaccuracy in this document or the included data.
63 # These mapping tables and character lists are subject to change.
64 # The latest tables should be available from the following:
66 # <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/>
68 # For general information about Mac OS encodings and these mapping
69 # tables, see the file "README.TXT".
74 # Three tab-separated columns;
75 # '#' begins a comment which continues to the end of the line.
76 # Column #1 is the Mac OS Arabic code (in hex as 0xNN).
77 # Column #2 is the corresponding Unicode (in hex as 0xNNNN),
78 # possibly preceded by a tag indicating required directionality
79 # (i.e. <LR>+0xNNNN or <RL>+0xNNNN).
80 # Column #3 is a comment containing the Unicode name.
82 # The entries are in Mac OS Arabic code order.
84 # Control character mappings are not shown in this table, following
85 # the conventions of the standard UTC mapping tables. However, the
86 # Mac OS Arabic character set uses the standard control characters at
89 # Notes on Mac OS Arabic:
90 # -----------------------
92 # This is a legacy Mac OS encoding; in the Mac OS X Carbon and Cocoa
93 # environments, it is only supported via transcoding to and from
98 # The Mac OS Arabic character set is intended to cover Arabic as
99 # used in North Africa, the Arabian peninsula, and the Levant. It
100 # also contains several characters needed for Urdu and/or Farsi.
102 # The Mac OS Arabic character set is essentially a superset of ISO
103 # 8859-6. The 8859-6 code points that are interpreted differently
104 # in the Mac OS Arabic set are as follows:
105 # 0xA0 is NO-BREAK SPACE in 8859-6 and right-left SPACE in Mac OS
106 # Arabic; NO-BREAK is 0x81 in Mac OS Arabic.
107 # 0xA4 is CURRENCY SIGN in 8859-6 and right-left DOLLAR SIGN in
109 # 0xAD is SOFT HYPHEN in 8859-6 and right-left HYPHEN-MINUS in
111 # ISO 8859-6 specifies that codes 0x30-0x39 can be rendered either
112 # with European digit shapes or Arabic digit shapes. This is also
113 # true in Mac OS Arabic, which determines from context which digit
114 # shapes to use (see below).
116 # The Mac OS Arabic character set uses the C1 controls area and other
117 # code points which are undefined in ISO 8859-6 for additional
118 # graphic characters: additional Arabic letters for Farsi and Urdu,
119 # some accented Roman letters for European languages (such as French),
120 # and duplicates of some of the punctuation, symbols, and digits in
121 # the ASCII block. The duplicate punctuation, symbol, and digit
122 # characters have right-left directionality, while the ASCII versions
123 # have left-right directionality. See the next section for more
124 # information on this.
126 # Mac OS Arabic characters 0xEB-0xF2 are non-spacing/combining marks.
128 # 2. Directional characters and roundtrip fidelity
130 # The Mac OS Arabic character set was developed in 1986-1987. At that
131 # time the bidirectional line layout algorithm used in the Mac OS
132 # Arabic system was fairly simple; it used only a few direction
133 # classes (instead of the 19 now used in the Unicode bidirectional
134 # algorithm). In order to permit users to handle some tricky layout
135 # problems, certain punctuation and symbol characters were encoded
136 # twice, one with a left-right direction attribute and the other with
137 # a right-left direction attribute.
139 # For example, plus sign is encoded at 0x2B with a left-right
140 # attribute, and at 0xAB with a right-left attribute. However, there
141 # is only one PLUS SIGN character in Unicode. This leads to some
142 # interesting problems when mapping between Mac OS Arabic and Unicode;
145 # A related problem is that even when a particular character is
146 # encoded only once in Mac OS Arabic, it may have a different
147 # direction attribute than the corresponding Unicode character.
149 # For example, the Mac OS Arabic character at 0x93 is HORIZONTAL
150 # ELLIPSIS with strong right-left direction. However, the Unicode
151 # character HORIZONTAL ELLIPSIS has direction class neutral.
153 # 3. Behavior of ASCII-range numbers in WorldScript
155 # Mac OS Arabic also has two sets of digit codes.
157 # The digits at 0x30-0x39 may be displayed using either European
158 # digit forms or Arabic digit forms, depending on context. If there
159 # is a "strong European" character such as a Latin letter on either
160 # side of a sequence consisting of digits 0x30-0x39 and possibly comma
161 # 0x2C or period 0x2E, then the characters will be displayed using
162 # European forms (This will happen even if there are neutral characters
163 # between the digits and the strong European character). Otherwise, the
164 # digits will be displayed using Arabic forms, the comma will be
165 # displayed as Arabic thousands separator, and the period as Arabic
166 # decimal separator. In any case, 0x2C, 0x2E, and 0x30-0x39 are always
169 # The digits at 0xB0-0xB9 are always displayed using Arabic digit
170 # shapes, and moreover, these digits always have strong right-left
171 # directionality. These are mainly intended for special layout
172 # purposes such as part numbers, etc.
176 # The table in this file gives the Unicode mappings for the standard
177 # Mac OS Arabic encoding. This encoding is supported by the Cairo font
178 # (the system font for Arabic), and is the encoding supported by the
179 # text processing utilities. However, the other Arabic fonts actually
180 # implement slightly different encodings; this mainly affects the code
181 # points 0xAA and 0xC0. For these code points the standard Mac OS
182 # Arabic encoding has the following mappings:
183 # 0xAA -> <RL>+0x002A ASTERISK, right-left
184 # 0xC0 -> <RL>+0x274A EIGHT TEARDROP-SPOKED PROPELLER ASTERISK,
186 # This mapping of 0xAA is consistent with the normal convention for
187 # Mac OS Arabic and Hebrew that the right-left duplicates have codes
188 # that are equal to the ASCII code of the left-right character plus
189 # 0x80. However, in all of the other fonts, 0xAA is MULTIPLY SIGN, and
190 # right-left ASTERISK may be at a different code point. The other
191 # variants are described below.
193 # The TrueType variant is used for most of the Arabic TrueType fonts:
194 # Baghdad, Geeza, Kufi, Nadeem. It differs from the standard variant
195 # in the following way:
196 # 0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
197 # 0xC0 -> <RL>+0x002A ASTERISK, right-left
199 # The Thuluth variant is used for the Arabic Postscript-only fonts:
200 # Thuluth and Thuluth bold. It differs from the standard variant in
202 # 0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
203 # 0xC0 -> 0x066D ARABIC FIVE POINTED STAR
205 # The AlBayan variant is used for the Arabic TrueType font Al Bayan.
206 # It differs from the standard variant in the following way:
207 # 0x81 -> no mapping (glyph just has authorship information, etc.)
208 # 0xA3 -> 0xFDFA ARABIC LIGATURE SALLALLAHOU ALAYHE WASALLAM
209 # 0xA4 -> 0xFDF2 ARABIC LIGATURE ALLAH ISOLATED FORM
210 # 0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
211 # 0xDC -> <RL>+0x25CF BLACK CIRCLE, right-left
212 # 0xFC -> <RL>+0x25A0 BLACK SQUARE, right-left
214 # Unicode mapping issues and notes:
215 # ---------------------------------
217 # 1. Matching the direction of Mac OS Arabic characters
219 # When Mac OS Arabic encodes a character twice but with different
220 # direction attributes for the two code points - as in the case of
221 # plus sign mentioned above - we need a way to map both Mac OS Arabic
222 # code points to Unicode and back again without loss of information.
223 # With the plus sign, for example, mapping one of the Mac OS Arabic
224 # characters to a code in the Unicode corporate use zone is
225 # undesirable, since both of the plus sign characters are likely to
226 # be used in text that is interchanged.
228 # The problem is solved with the use of direction override characters
229 # and direction-dependent mappings. When mapping from Mac OS Arabic
230 # to Unicode, we use direction overrides as necessary to force the
231 # direction of the resulting Unicode characters.
233 # The required direction is indicated by a direction tag in the
234 # mappings. A tag of <LR> means the corresponding Unicode character
235 # must have a strong left-right context, and a tag of <RL> indicates
236 # a right-left context.
238 # For example, the mapping of 0x2B is given as <LR>+0x002B; the
239 # mapping of 0xAB is given as <RL>+0x002B. If we map an isolated
240 # instance of 0x2B to Unicode, it should be mapped as follows (LRO
241 # indicates LEFT-RIGHT OVERRIDE, PDF indicates POP DIRECTION
244 # 0x2B -> 0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF)
246 # When mapping several characters in a row that require direction
247 # forcing, the overrides need only be used at the beginning and end.
250 # 0x24 0x20 0x28 0x29 -> 0x202D 0x0024 0x0020 0x0028 0x0029 0x202C
252 # If neutral characters that require direction forcing are already
253 # between strong-direction characters with matching directionality,
254 # then direction overrides need not be used. Direction overrides are
255 # always needed to map the right-left digits at 0xB0-0xB9.
257 # When mapping from Unicode to Mac OS Arabic, the Unicode
258 # bidirectional algorithm should be used to determine resolved
259 # direction of the Unicode characters. The mapping from Unicode to
260 # Mac OS Arabic can then be disambiguated by the use of the resolved
263 # Unicode 0x002B -> Mac OS Arabic 0x2B (if L) or 0xAB (if R)
265 # However, this also means the direction override characters should
266 # be discarded when mapping from Unicode to Mac OS Arabic (after
267 # they have been used to determine resolved direction), since the
268 # direction override information is carried by the code point itself.
270 # Even when direction overrides are not needed for roundtrip
271 # fidelity, they are sometimes used when mapping Mac OS Arabic
272 # characters to Unicode in order to achieve similar text layout with
273 # the resulting Unicode text. For example, the single Mac OS Arabic
274 # ellipsis character has direction class right-left,and there is no
275 # left-right version. However, the Unicode HORIZONTAL ELLIPSIS
276 # character has direction class neutral (which means it may end up
277 # with a resolved direction of left-right if surrounded by left-right
278 # characters). When mapping the Mac OS Arabic ellipsis to Unicode, it
279 # is surrounded with a direction override to help preserve proper
280 # text layout. The resolved direction is not needed or used when
281 # mapping the Unicode HORIZONTAL ELLIPSIS back to Mac OS Arabic.
283 # 2. Mapping the Mac OS Arabic digits
285 # The main table below contains mappings that should be used when
286 # strict round-trip fidelity is required. However, for numeric
287 # values, the mappings in that table will produce Unicode characters
288 # that may appear different than the Mac OS Arabic text displayed on
289 # a Mac OS system using WorldScript. This is because WorldScript
290 # uses context-dependent display for the 0x30-0x39 digits.
292 # If roundtrip fidelity is not required, then the following
293 # alternate mappings should be used when a sequence of 0x30-0x39
294 # digits - possibly including 0x2C and 0x2E - occurs in an Arabic
295 # context (that is, when the first "strong" character on either side
296 # of the digit sequence is Arabic, or there is no strong character):
298 # 0x2C 0x066C # ARABIC THOUSANDS SEPARATOR
299 # 0x2E 0x066B # ARABIC DECIMAL SEPARATOR
300 # 0x30 0x0660 # ARABIC-INDIC DIGIT ZERO
301 # 0x31 0x0661 # ARABIC-INDIC DIGIT ONE
302 # 0x32 0x0662 # ARABIC-INDIC DIGIT TWO
303 # 0x33 0x0663 # ARABIC-INDIC DIGIT THREE
304 # 0x34 0x0664 # ARABIC-INDIC DIGIT FOUR
305 # 0x35 0x0665 # ARABIC-INDIC DIGIT FIVE
306 # 0x36 0x0666 # ARABIC-INDIC DIGIT SIX
307 # 0x37 0x0667 # ARABIC-INDIC DIGIT SEVEN
308 # 0x38 0x0668 # ARABIC-INDIC DIGIT EIGHT
309 # 0x39 0x0669 # ARABIC-INDIC DIGIT NINE
311 # Details of mapping changes in each version:
312 # -------------------------------------------
314 # Changes from version n03 to version n07:
316 # - Change mapping for 0xC0 from U+066D to U+274A.
318 # - Add direction overrides (required directionality) to mappings
319 # for 0x25, 0x2C, 0x3B, 0x3F.
322 0x00 - 0x7F = 0x0000 -