]> CyberLeo.Net >> Repos - FreeBSD/releng/10.0.git/blob - share/i18n/csmapper/APPLE/UCS%ARABIC.src
- Copy stable/10 (r259064) to releng/10.0 as part of the
[FreeBSD/releng/10.0.git] / share / i18n / csmapper / APPLE / UCS%ARABIC.src
1 # $FreeBSD$
2
3 TYPE            ROWCOL
4 NAME            UCS/ARABIC
5 SRC_ZONE        0x0000-0xFB02
6 OOB_MODE        INVALID
7 DST_INVALID     0x100
8 DST_UNIT_BITS   16
9
10 BEGIN_MAP
11 #=======================================================================
12 #   File name:  ARABIC.TXT
13 #
14 #   Contents:   Map (external version) from Mac OS Arabic
15 #               character set to Unicode 2.1 and later.
16 #
17 #   Copyright:  (c) 1994-2002, 2005 by Apple Computer, Inc., all rights
18 #               reserved.
19 #
20 #   Contact:    charsets@apple.com
21 #
22 #   Changes:
23 #
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>.
45 #
46 # Standard header:
47 # ----------------
48 #
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
54 #   Unicode standard.
55 #
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.
62 #
63 #   These mapping tables and character lists are subject to change.
64 #   The latest tables should be available from the following:
65 #
66 #   <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/>
67 #
68 #   For general information about Mac OS encodings and these mapping
69 #   tables, see the file "README.TXT".
70 #
71 # Format:
72 # -------
73 #
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.
81 #
82 #   The entries are in Mac OS Arabic code order.
83 #
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
87 #   0x00-0x1F and 0x7F.
88 #
89 # Notes on Mac OS Arabic:
90 # -----------------------
91 #
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
94 #   Unicode.
95 #
96 #   1. General
97 #
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.
101 #
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
108 #         Mac OS Arabic.
109 #    0xAD is SOFT HYPHEN in 8859-6 and right-left HYPHEN-MINUS in
110 #         Mac OS Arabic.
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).
115 #
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.
125 #
126 #   Mac OS Arabic characters 0xEB-0xF2 are non-spacing/combining marks.
127 #
128 #   2. Directional characters and roundtrip fidelity
129 #
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.
138 #
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;
143 #   see below.
144 #
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.
148 #
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.
152 #
153 #   3. Behavior of ASCII-range numbers in WorldScript
154 #
155 #   Mac OS Arabic also has two sets of digit codes.
156 #
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
167 #   left-right.
168 #
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.
173 #
174 #   4. Font variants
175 #
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,
185 #                         right-left
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.
192 #
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
198 #
199 #   The Thuluth variant is used for the Arabic Postscript-only fonts:
200 #   Thuluth and Thuluth bold. It differs from the standard variant in
201 #   the following way:
202 #     0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
203 #     0xC0 -> 0x066D ARABIC FIVE POINTED STAR
204 #
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
213 #
214 # Unicode mapping issues and notes:
215 # ---------------------------------
216 #
217 #   1. Matching the direction of Mac OS Arabic characters
218 #
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.
227 #
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.
232 #
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.
237 #
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
242 #   FORMATTING):
243 #
244 #     0x2B ->  0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF)
245 #
246 #   When mapping several characters in a row that require direction
247 #   forcing, the overrides need only be used at the beginning and end.
248 #   For example:
249 #
250 #     0x24 0x20 0x28 0x29 -> 0x202D 0x0024 0x0020 0x0028 0x0029 0x202C
251 #
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.
256 #
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
261 #   direction:
262 #
263 #     Unicode 0x002B -> Mac OS Arabic 0x2B (if L) or 0xAB (if R)
264 #
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.
269 #
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.
282 #
283 #   2. Mapping the Mac OS Arabic digits
284 #
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.
291 #
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):
297 #
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
310 #
311 # Details of mapping changes in each version:
312 # -------------------------------------------
313 #
314 #   Changes from version n03 to version n07:
315 #
316 #   - Change mapping for 0xC0 from U+066D to U+274A.
317 #
318 #   - Add direction overrides (required directionality) to mappings
319 #     for 0x25, 0x2C, 0x3B, 0x3F.
320 #
321 ##################
322 0x0000 - 0x007F = 0x00 -
323 0x00A0 = 0x81
324 0x00AB = 0x8C
325 0x00BB = 0x98
326 0x00C4 = 0x80
327 0x00C7 = 0x82
328 0x00C9 = 0x83
329 0x00D1 = 0x84
330 0x00D6 = 0x85
331 0x00DC = 0x86
332 0x00E0 = 0x88
333 0x00E1 = 0x87
334 0x00E2 = 0x89
335 0x00E4 = 0x8A
336 0x00E7 = 0x8D
337 0x00E8 = 0x8F
338 0x00E9 = 0x8E
339 0x00EA = 0x90
340 0x00EB = 0x91
341 0x00ED = 0x92
342 0x00EE = 0x94
343 0x00EF = 0x95
344 0x00F1 = 0x96
345 0x00F3 = 0x97
346 0x00F4 = 0x99
347 0x00F6 = 0x9A
348 0x00F7 = 0x9B
349 0x00F9 = 0x9D
350 0x00FA = 0x9C
351 0x00FB = 0x9E
352 0x00FC = 0x9F
353 0x060C = 0xAC
354 0x061B = 0xBB
355 0x061F = 0xBF
356 0x0621 = 0xC1
357 0x0622 = 0xC2
358 0x0623 = 0xC3
359 0x0624 = 0xC4
360 0x0625 = 0xC5
361 0x0626 = 0xC6
362 0x0627 = 0xC7
363 0x0628 = 0xC8
364 0x0629 = 0xC9
365 0x062A = 0xCA
366 0x062B = 0xCB
367 0x062C = 0xCC
368 0x062D = 0xCD
369 0x062E = 0xCE
370 0x062F = 0xCF
371 0x0630 = 0xD0
372 0x0631 = 0xD1
373 0x0632 = 0xD2
374 0x0633 = 0xD3
375 0x0634 = 0xD4
376 0x0635 = 0xD5
377 0x0636 = 0xD6
378 0x0637 = 0xD7
379 0x0638 = 0xD8
380 0x0639 = 0xD9
381 0x063A = 0xDA
382 0x0640 = 0xE0
383 0x0641 = 0xE1
384 0x0642 = 0xE2
385 0x0643 = 0xE3
386 0x0644 = 0xE4
387 0x0645 = 0xE5
388 0x0646 = 0xE6
389 0x0647 = 0xE7
390 0x0648 = 0xE8
391 0x0649 = 0xE9
392 0x064A = 0xEA
393 0x064B = 0xEB
394 0x064C = 0xEC
395 0x064D = 0xED
396 0x064E = 0xEE
397 0x064F = 0xEF
398 0x0650 = 0xF0
399 0x0651 = 0xF1
400 0x0652 = 0xF2
401 0x0660 = 0xB0
402 0x0661 = 0xB1
403 0x0662 = 0xB2
404 0x0663 = 0xB3
405 0x0664 = 0xB4
406 0x0665 = 0xB5
407 0x0666 = 0xB6
408 0x0667 = 0xB7
409 0x0668 = 0xB8
410 0x0669 = 0xB9
411 0x066A = 0xA5
412 0x066D = 0xC0
413 0x0679 = 0xF4
414 0x067E = 0xF3
415 0x0686 = 0xF5
416 0x0688 = 0xF9
417 0x0691 = 0xFA
418 0x0698 = 0xFE
419 0x06A4 = 0xF7
420 0x06AF = 0xF8
421 0x06BA = 0x8B
422 0x06D2 = 0xFF
423 0x06D5 = 0xF6
424 0x2026 = 0x93
425 0x274A = 0xC0
426 END_MAP