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 452