xref: /freebsd-src/share/i18n/csmapper/APPLE/ARABIC%UCS.src (revision d0b2dbfa0ecf2bbc9709efc5e20baf8e4b44bbbf)
1
2TYPE		ROWCOL
3NAME		ARABIC/UCS
4SRC_ZONE	0x00-0xFF
5OOB_MODE	ILSEQ
6DST_ILSEQ	0xFFFE
7DST_UNIT_BITS	16
8
9BEGIN_MAP
10#=======================================================================
11#   File name:  ARABIC.TXT
12#
13#   Contents:   Map (external version) from Mac OS Arabic
14#               character set to Unicode 2.1 and later.
15#
16#   Copyright:  (c) 1994-2002, 2005 by Apple Computer, Inc., all rights
17#               reserved.
18#
19#   Contact:    charsets@apple.com
20#
21#   Changes:
22#
23#       c02  2005-Apr-04    Update header comments. Matches internal xml
24#                           <c1.2> and Text Encoding Converter 2.0.
25#      b3,c1 2002-Dec-19    Add comments about character display and
26#                           direction overrides. Update URLs, notes.
27#                           Matches internal utom<b4>.
28#       b02  1999-Sep-22    Update contact e-mail address. Matches
29#                           internal utom<b1>, ufrm<b1>, and Text
30#                           Encoding Converter version 1.5.
31#       n10  1998-Feb-05    Show required Unicode character
32#                           directionality in a different way. Matches
33#                           internal utom<n4>, ufrm<n21>, and Text
34#                           Encoding Converter version 1.3. Update
35#                           header comments; include information on
36#                           loose mapping of digits.
37#       n07  1997-Jul-17    Update to match internal utom<n2>, ufrm<n17>:
38#                           Change standard mapping for 0xC0 from U+066D
39#                           to U+274A. Add direction overrides to
40#                           mappings for 0x25, 0x2C, 0x3B, 0x3F. Add
41#                           information on variants.
42#       n03  1995-Apr-18    First version (after fixing some typos).
43#                           Matches internal ufrm<n11>.
44#
45# Standard header:
46# ----------------
47#
48#   Apple, the Apple logo, and Macintosh are trademarks of Apple
49#   Computer, Inc., registered in the United States and other countries.
50#   Unicode is a trademark of Unicode Inc. For the sake of brevity,
51#   throughout this document, "Macintosh" can be used to refer to
52#   Macintosh computers and "Unicode" can be used to refer to the
53#   Unicode standard.
54#
55#   Apple Computer, Inc. ("Apple") makes no warranty or representation,
56#   either express or implied, with respect to this document and the
57#   included data, its quality, accuracy, or fitness for a particular
58#   purpose. In no event will Apple be liable for direct, indirect,
59#   special, incidental, or consequential damages resulting from any
60#   defect or inaccuracy in this document or the included data.
61#
62#   These mapping tables and character lists are subject to change.
63#   The latest tables should be available from the following:
64#
65#   <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/>
66#
67#   For general information about Mac OS encodings and these mapping
68#   tables, see the file "README.TXT".
69#
70# Format:
71# -------
72#
73#   Three tab-separated columns;
74#   '#' begins a comment which continues to the end of the line.
75#     Column #1 is the Mac OS Arabic code (in hex as 0xNN).
76#     Column #2 is the corresponding Unicode (in hex as 0xNNNN),
77#       possibly preceded by a tag indicating required directionality
78#       (i.e. <LR>+0xNNNN or <RL>+0xNNNN).
79#     Column #3 is a comment containing the Unicode name.
80#
81#   The entries are in Mac OS Arabic code order.
82#
83#   Control character mappings are not shown in this table, following
84#   the conventions of the standard UTC mapping tables. However, the
85#   Mac OS Arabic character set uses the standard control characters at
86#   0x00-0x1F and 0x7F.
87#
88# Notes on Mac OS Arabic:
89# -----------------------
90#
91#   This is a legacy Mac OS encoding; in the Mac OS X Carbon and Cocoa
92#   environments, it is only supported via transcoding to and from
93#   Unicode.
94#
95#   1. General
96#
97#   The Mac OS Arabic character set is intended to cover Arabic as
98#   used in North Africa, the Arabian peninsula, and the Levant. It
99#   also contains several characters needed for Urdu and/or Farsi.
100#
101#   The Mac OS Arabic character set is essentially a superset of ISO
102#   8859-6. The 8859-6 code points that are interpreted differently
103#   in the Mac OS Arabic set are as follows:
104#    0xA0 is NO-BREAK SPACE in 8859-6 and right-left SPACE in Mac OS
105#         Arabic; NO-BREAK is 0x81 in Mac OS Arabic.
106#    0xA4 is CURRENCY SIGN in 8859-6 and right-left DOLLAR SIGN in
107#         Mac OS Arabic.
108#    0xAD is SOFT HYPHEN in 8859-6 and right-left HYPHEN-MINUS in
109#         Mac OS Arabic.
110#   ISO 8859-6 specifies that codes 0x30-0x39 can be rendered either
111#   with European digit shapes or Arabic digit shapes. This is also
112#   true in Mac OS Arabic, which determines from context which digit
113#   shapes to use (see below).
114#
115#   The Mac OS Arabic character set uses the C1 controls area and other
116#   code points which are undefined in ISO 8859-6 for additional
117#   graphic characters: additional Arabic letters for Farsi and Urdu,
118#   some accented Roman letters for European languages (such as French),
119#   and duplicates of some of the punctuation, symbols, and digits in
120#   the ASCII block. The duplicate punctuation, symbol, and digit
121#   characters have right-left directionality, while the ASCII versions
122#   have left-right directionality. See the next section for more
123#   information on this.
124#
125#   Mac OS Arabic characters 0xEB-0xF2 are non-spacing/combining marks.
126#
127#   2. Directional characters and roundtrip fidelity
128#
129#   The Mac OS Arabic character set was developed in 1986-1987. At that
130#   time the bidirectional line layout algorithm used in the Mac OS
131#   Arabic system was fairly simple; it used only a few direction
132#   classes (instead of the 19 now used in the Unicode bidirectional
133#   algorithm). In order to permit users to handle some tricky layout
134#   problems, certain punctuation and symbol characters were encoded
135#   twice, one with a left-right direction attribute and the other with
136#   a right-left direction attribute.
137#
138#   For example, plus sign is encoded at 0x2B with a left-right
139#   attribute, and at 0xAB with a right-left attribute. However, there
140#   is only one PLUS SIGN character in Unicode. This leads to some
141#   interesting problems when mapping between Mac OS Arabic and Unicode;
142#   see below.
143#
144#   A related problem is that even when a particular character is
145#   encoded only once in Mac OS Arabic, it may have a different
146#   direction attribute than the corresponding Unicode character.
147#
148#   For example, the Mac OS Arabic character at 0x93 is HORIZONTAL
149#   ELLIPSIS with strong right-left direction. However, the Unicode
150#   character HORIZONTAL ELLIPSIS has direction class neutral.
151#
152#   3. Behavior of ASCII-range numbers in WorldScript
153#
154#   Mac OS Arabic also has two sets of digit codes.
155#
156#   The digits at 0x30-0x39 may be displayed using either European
157#   digit forms or Arabic digit forms, depending on context. If there
158#   is a "strong European" character such as a Latin letter on either
159#   side of a sequence consisting of digits 0x30-0x39 and possibly comma
160#   0x2C or period 0x2E, then the characters will be displayed using
161#   European forms (This will happen even if there are neutral characters
162#   between the digits and the strong European character). Otherwise, the
163#   digits will be displayed using Arabic forms, the comma will be
164#   displayed as Arabic thousands separator, and the period as Arabic
165#   decimal separator. In any case, 0x2C, 0x2E, and 0x30-0x39 are always
166#   left-right.
167#
168#   The digits at 0xB0-0xB9 are always displayed using Arabic digit
169#   shapes, and moreover, these digits always have strong right-left
170#   directionality. These are mainly intended for special layout
171#   purposes such as part numbers, etc.
172#
173#   4. Font variants
174#
175#   The table in this file gives the Unicode mappings for the standard
176#   Mac OS Arabic encoding. This encoding is supported by the Cairo font
177#   (the system font for Arabic), and is the encoding supported by the
178#   text processing utilities. However, the other Arabic fonts actually
179#   implement slightly different encodings; this mainly affects the code
180#   points 0xAA and 0xC0. For these code points the standard Mac OS
181#   Arabic encoding has the following mappings:
182#     0xAA -> <RL>+0x002A ASTERISK, right-left
183#     0xC0 -> <RL>+0x274A EIGHT TEARDROP-SPOKED PROPELLER ASTERISK,
184#                         right-left
185#   This mapping of 0xAA is consistent with the normal convention for
186#   Mac OS Arabic and Hebrew that the right-left duplicates have codes
187#   that are equal to the ASCII code of the left-right character plus
188#   0x80. However, in all of the other fonts, 0xAA is MULTIPLY SIGN, and
189#   right-left ASTERISK may be at a different code point. The other
190#   variants are described below.
191#
192#   The TrueType variant is used for most of the Arabic TrueType fonts:
193#   Baghdad, Geeza, Kufi, Nadeem.  It differs from the standard variant
194#   in the following way:
195#     0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
196#     0xC0 -> <RL>+0x002A ASTERISK, right-left
197#
198#   The Thuluth variant is used for the Arabic Postscript-only fonts:
199#   Thuluth and Thuluth bold. It differs from the standard variant in
200#   the following way:
201#     0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
202#     0xC0 -> 0x066D ARABIC FIVE POINTED STAR
203#
204#   The AlBayan variant is used for the Arabic TrueType font Al Bayan.
205#   It differs from the standard variant in the following way:
206#     0x81 -> no mapping (glyph just has authorship information, etc.)
207#     0xA3 -> 0xFDFA ARABIC LIGATURE SALLALLAHOU ALAYHE WASALLAM
208#     0xA4 -> 0xFDF2 ARABIC LIGATURE ALLAH ISOLATED FORM
209#     0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left
210#     0xDC -> <RL>+0x25CF BLACK CIRCLE, right-left
211#     0xFC -> <RL>+0x25A0 BLACK SQUARE, right-left
212#
213# Unicode mapping issues and notes:
214# ---------------------------------
215#
216#   1. Matching the direction of Mac OS Arabic characters
217#
218#   When Mac OS Arabic encodes a character twice but with different
219#   direction attributes for the two code points - as in the case of
220#   plus sign mentioned above - we need a way to map both Mac OS Arabic
221#   code points to Unicode and back again without loss of information.
222#   With the plus sign, for example, mapping one of the Mac OS Arabic
223#   characters to a code in the Unicode corporate use zone is
224#   undesirable, since both of the plus sign characters are likely to
225#   be used in text that is interchanged.
226#
227#   The problem is solved with the use of direction override characters
228#   and direction-dependent mappings. When mapping from Mac OS Arabic
229#   to Unicode, we use direction overrides as necessary to force the
230#   direction of the resulting Unicode characters.
231#
232#   The required direction is indicated by a direction tag in the
233#   mappings. A tag of <LR> means the corresponding Unicode character
234#   must have a strong left-right context, and a tag of <RL> indicates
235#   a right-left context.
236#
237#   For example, the mapping of 0x2B is given as <LR>+0x002B; the
238#   mapping of 0xAB is given as <RL>+0x002B. If we map an isolated
239#   instance of 0x2B to Unicode, it should be mapped as follows (LRO
240#   indicates LEFT-RIGHT OVERRIDE, PDF indicates POP DIRECTION
241#   FORMATTING):
242#
243#     0x2B ->  0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF)
244#
245#   When mapping several characters in a row that require direction
246#   forcing, the overrides need only be used at the beginning and end.
247#   For example:
248#
249#     0x24 0x20 0x28 0x29 -> 0x202D 0x0024 0x0020 0x0028 0x0029 0x202C
250#
251#   If neutral characters that require direction forcing are already
252#   between strong-direction characters with matching directionality,
253#   then direction overrides need not be used. Direction overrides are
254#   always needed to map the right-left digits at 0xB0-0xB9.
255#
256#   When mapping from Unicode to Mac OS Arabic, the Unicode
257#   bidirectional algorithm should be used to determine resolved
258#   direction of the Unicode characters. The mapping from Unicode to
259#   Mac OS Arabic can then be disambiguated by the use of the resolved
260#   direction:
261#
262#     Unicode 0x002B -> Mac OS Arabic 0x2B (if L) or 0xAB (if R)
263#
264#   However, this also means the direction override characters should
265#   be discarded when mapping from Unicode to Mac OS Arabic (after
266#   they have been used to determine resolved direction), since the
267#   direction override information is carried by the code point itself.
268#
269#   Even when direction overrides are not needed for roundtrip
270#   fidelity, they are sometimes used when mapping Mac OS Arabic
271#   characters to Unicode in order to achieve similar text layout with
272#   the resulting Unicode text. For example, the single Mac OS Arabic
273#   ellipsis character has direction class right-left,and there is no
274#   left-right version. However, the Unicode HORIZONTAL ELLIPSIS
275#   character has direction class neutral (which means it may end up
276#   with a resolved direction of left-right if surrounded by left-right
277#   characters). When mapping the Mac OS Arabic ellipsis to Unicode, it
278#   is surrounded with a direction override to help preserve proper
279#   text layout. The resolved direction is not needed or used when
280#   mapping the Unicode HORIZONTAL ELLIPSIS back to Mac OS Arabic.
281#
282#   2. Mapping the Mac OS Arabic digits
283#
284#   The main table below contains mappings that should be used when
285#   strict round-trip fidelity is required. However, for numeric
286#   values, the mappings in that table will produce Unicode characters
287#   that may appear different than the Mac OS Arabic text displayed on
288#   a Mac OS system using WorldScript. This is because WorldScript
289#   uses context-dependent display for the 0x30-0x39 digits.
290#
291#   If roundtrip fidelity is not required, then the following
292#   alternate mappings should be used when a sequence of 0x30-0x39
293#   digits - possibly including 0x2C and 0x2E - occurs in an Arabic
294#   context (that is, when the first "strong" character on either side
295#   of the digit sequence is Arabic, or there is no strong character):
296#
297#     0x2C	0x066C	# ARABIC THOUSANDS SEPARATOR
298#     0x2E	0x066B	# ARABIC DECIMAL SEPARATOR
299#     0x30	0x0660	# ARABIC-INDIC DIGIT ZERO
300#     0x31	0x0661	# ARABIC-INDIC DIGIT ONE
301#     0x32	0x0662	# ARABIC-INDIC DIGIT TWO
302#     0x33	0x0663	# ARABIC-INDIC DIGIT THREE
303#     0x34	0x0664	# ARABIC-INDIC DIGIT FOUR
304#     0x35	0x0665	# ARABIC-INDIC DIGIT FIVE
305#     0x36	0x0666	# ARABIC-INDIC DIGIT SIX
306#     0x37	0x0667	# ARABIC-INDIC DIGIT SEVEN
307#     0x38	0x0668	# ARABIC-INDIC DIGIT EIGHT
308#     0x39	0x0669	# ARABIC-INDIC DIGIT NINE
309#
310# Details of mapping changes in each version:
311# -------------------------------------------
312#
313#   Changes from version n03 to version n07:
314#
315#   - Change mapping for 0xC0 from U+066D to U+274A.
316#
317#   - Add direction overrides (required directionality) to mappings
318#     for 0x25, 0x2C, 0x3B, 0x3F.
319#
320##################
3210x00 - 0x7F = 0x0000 -
3220x80 = 0x00C4
3230x81 = 0x00A0
3240x82 = 0x00C7
3250x83 = 0x00C9
3260x84 = 0x00D1
3270x85 = 0x00D6
3280x86 = 0x00DC
3290x87 = 0x00E1
3300x88 = 0x00E0
3310x89 = 0x00E2
3320x8A = 0x00E4
3330x8B = 0x06BA
3340x8C = 0x00AB
3350x8D = 0x00E7
3360x8E = 0x00E9
3370x8F = 0x00E8
3380x90 = 0x00EA
3390x91 = 0x00EB
3400x92 = 0x00ED
3410x93 = 0x2026
3420x94 = 0x00EE
3430x95 = 0x00EF
3440x96 = 0x00F1
3450x97 = 0x00F3
3460x98 = 0x00BB
3470x99 = 0x00F4
3480x9A = 0x00F6
3490x9B = 0x00F7
3500x9C = 0x00FA
3510x9D = 0x00F9
3520x9E = 0x00FB
3530x9F = 0x00FC
3540xA0 = 0x0020
3550xA1 = 0x0021
3560xA2 = 0x0022
3570xA3 = 0x0023
3580xA4 = 0x0024
3590xA5 = 0x066A
3600xA6 = 0x0026
3610xA7 = 0x0027
3620xA8 = 0x0028
3630xA9 = 0x0029
3640xAA = 0x002A
3650xAB = 0x002B
3660xAC = 0x060C
3670xAD = 0x002D
3680xAE = 0x002E
3690xAF = 0x002F
3700xB0 = 0x0660
3710xB1 = 0x0661
3720xB2 = 0x0662
3730xB3 = 0x0663
3740xB4 = 0x0664
3750xB5 = 0x0665
3760xB6 = 0x0666
3770xB7 = 0x0667
3780xB8 = 0x0668
3790xB9 = 0x0669
3800xBA = 0x003A
3810xBB = 0x061B
3820xBC = 0x003C
3830xBD = 0x003D
3840xBE = 0x003E
3850xBF = 0x061F
3860xC0 = 0x274A
3870xC1 = 0x0621
3880xC2 = 0x0622
3890xC3 = 0x0623
3900xC4 = 0x0624
3910xC5 = 0x0625
3920xC6 = 0x0626
3930xC7 = 0x0627
3940xC8 = 0x0628
3950xC9 = 0x0629
3960xCA = 0x062A
3970xCB = 0x062B
3980xCC = 0x062C
3990xCD = 0x062D
4000xCE = 0x062E
4010xCF = 0x062F
4020xD0 = 0x0630
4030xD1 = 0x0631
4040xD2 = 0x0632
4050xD3 = 0x0633
4060xD4 = 0x0634
4070xD5 = 0x0635
4080xD6 = 0x0636
4090xD7 = 0x0637
4100xD8 = 0x0638
4110xD9 = 0x0639
4120xDA = 0x063A
4130xDB = 0x005B
4140xDC = 0x005C
4150xDD = 0x005D
4160xDE = 0x005E
4170xDF = 0x005F
4180xE0 = 0x0640
4190xE1 = 0x0641
4200xE2 = 0x0642
4210xE3 = 0x0643
4220xE4 = 0x0644
4230xE5 = 0x0645
4240xE6 = 0x0646
4250xE7 = 0x0647
4260xE8 = 0x0648
4270xE9 = 0x0649
4280xEA = 0x064A
4290xEB = 0x064B
4300xEC = 0x064C
4310xED = 0x064D
4320xEE = 0x064E
4330xEF = 0x064F
4340xF0 = 0x0650
4350xF1 = 0x0651
4360xF2 = 0x0652
4370xF3 = 0x067E
4380xF4 = 0x0679
4390xF5 = 0x0686
4400xF6 = 0x06D5
4410xF7 = 0x06A4
4420xF8 = 0x06AF
4430xF9 = 0x0688
4440xFA = 0x0691
4450xFB = 0x007B
4460xFC = 0x007C
4470xFD = 0x007D
4480xFE = 0x0698
4490xFF = 0x06D2
450END_MAP
451