PageRenderTime 19ms CodeModel.GetById 13ms app.highlight 3ms RepoModel.GetById 1ms app.codeStats 0ms

/share/i18n/csmapper/APPLE/ARABIC%UCS.src

https://bitbucket.org/freebsd/freebsd-head/
Unknown | 451 lines | 449 code | 2 blank | 0 comment | 0 complexity | bfdd202553b66768bf4298aba48bb1f3 MD5 | raw file
  1# $FreeBSD$
  2
  3TYPE		ROWCOL
  4NAME		ARABIC/UCS
  5SRC_ZONE	0x00-0xFF
  6OOB_MODE	ILSEQ
  7DST_ILSEQ	0xFFFE
  8DST_UNIT_BITS	16
  9
 10BEGIN_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##################
3220x00 - 0x7F = 0x0000 -
3230x80 = 0x00C4
3240x81 = 0x00A0
3250x82 = 0x00C7
3260x83 = 0x00C9
3270x84 = 0x00D1
3280x85 = 0x00D6
3290x86 = 0x00DC
3300x87 = 0x00E1
3310x88 = 0x00E0
3320x89 = 0x00E2
3330x8A = 0x00E4
3340x8B = 0x06BA
3350x8C = 0x00AB
3360x8D = 0x00E7
3370x8E = 0x00E9
3380x8F = 0x00E8
3390x90 = 0x00EA
3400x91 = 0x00EB
3410x92 = 0x00ED
3420x93 = 0x2026
3430x94 = 0x00EE
3440x95 = 0x00EF
3450x96 = 0x00F1
3460x97 = 0x00F3
3470x98 = 0x00BB
3480x99 = 0x00F4
3490x9A = 0x00F6
3500x9B = 0x00F7
3510x9C = 0x00FA
3520x9D = 0x00F9
3530x9E = 0x00FB
3540x9F = 0x00FC
3550xA0 = 0x0020
3560xA1 = 0x0021
3570xA2 = 0x0022
3580xA3 = 0x0023
3590xA4 = 0x0024
3600xA5 = 0x066A
3610xA6 = 0x0026
3620xA7 = 0x0027
3630xA8 = 0x0028
3640xA9 = 0x0029
3650xAA = 0x002A
3660xAB = 0x002B
3670xAC = 0x060C
3680xAD = 0x002D
3690xAE = 0x002E
3700xAF = 0x002F
3710xB0 = 0x0660
3720xB1 = 0x0661
3730xB2 = 0x0662
3740xB3 = 0x0663
3750xB4 = 0x0664
3760xB5 = 0x0665
3770xB6 = 0x0666
3780xB7 = 0x0667
3790xB8 = 0x0668
3800xB9 = 0x0669
3810xBA = 0x003A
3820xBB = 0x061B
3830xBC = 0x003C
3840xBD = 0x003D
3850xBE = 0x003E
3860xBF = 0x061F
3870xC0 = 0x274A
3880xC1 = 0x0621
3890xC2 = 0x0622
3900xC3 = 0x0623
3910xC4 = 0x0624
3920xC5 = 0x0625
3930xC6 = 0x0626
3940xC7 = 0x0627
3950xC8 = 0x0628
3960xC9 = 0x0629
3970xCA = 0x062A
3980xCB = 0x062B
3990xCC = 0x062C
4000xCD = 0x062D
4010xCE = 0x062E
4020xCF = 0x062F
4030xD0 = 0x0630
4040xD1 = 0x0631
4050xD2 = 0x0632
4060xD3 = 0x0633
4070xD4 = 0x0634
4080xD5 = 0x0635
4090xD6 = 0x0636
4100xD7 = 0x0637
4110xD8 = 0x0638
4120xD9 = 0x0639
4130xDA = 0x063A
4140xDB = 0x005B
4150xDC = 0x005C
4160xDD = 0x005D
4170xDE = 0x005E
4180xDF = 0x005F
4190xE0 = 0x0640
4200xE1 = 0x0641
4210xE2 = 0x0642
4220xE3 = 0x0643
4230xE4 = 0x0644
4240xE5 = 0x0645
4250xE6 = 0x0646
4260xE7 = 0x0647
4270xE8 = 0x0648
4280xE9 = 0x0649
4290xEA = 0x064A
4300xEB = 0x064B
4310xEC = 0x064C
4320xED = 0x064D
4330xEE = 0x064E
4340xEF = 0x064F
4350xF0 = 0x0650
4360xF1 = 0x0651
4370xF2 = 0x0652
4380xF3 = 0x067E
4390xF4 = 0x0679
4400xF5 = 0x0686
4410xF6 = 0x06D5
4420xF7 = 0x06A4
4430xF8 = 0x06AF
4440xF9 = 0x0688
4450xFA = 0x0691
4460xFB = 0x007B
4470xFC = 0x007C
4480xFD = 0x007D
4490xFE = 0x0698
4500xFF = 0x06D2
451END_MAP