1 2TYPE ROWCOL 3NAME UCS/FARSI 4SRC_ZONE 0x0000-0xF8FF 5OOB_MODE INVALID 6DST_INVALID 0x100 7DST_UNIT_BITS 16 8 9BEGIN_MAP 10#======================================================================= 11# File name: FARSI.TXT 12# 13# Contents: Map (external version) from Mac OS Farsi 14# character set to Unicode 2.1 and later. 15# 16# Copyright: (c) 1997-2002, 2005 by Apple Computer, Inc., all rights 17# reserved. 18# 19# Contact: charsets@apple.com 20# 21# Changes: 22# 23# c02 2005-Apr-05 Update header comments. Matches internal xml 24# <c1.1> 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<b3>. 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# n04 1998-Feb-05 Show required Unicode character 32# directionality in a different way. Matches 33# internal utom<n3>, ufrm<n9>, and Text 34# Encoding Converter version 1.3. Update 35# header comments; include information on 36# loose mapping of digits, and changes to 37# mapping for the TrueType variant. 38# n01 1997-Jul-17 First version. Matches internal utom<n1>, 39# ufrm<n2>. 40# 41# Standard header: 42# ---------------- 43# 44# Apple, the Apple logo, and Macintosh are trademarks of Apple 45# Computer, Inc., registered in the United States and other countries. 46# Unicode is a trademark of Unicode Inc. For the sake of brevity, 47# throughout this document, "Macintosh" can be used to refer to 48# Macintosh computers and "Unicode" can be used to refer to the 49# Unicode standard. 50# 51# Apple Computer, Inc. ("Apple") makes no warranty or representation, 52# either express or implied, with respect to this document and the 53# included data, its quality, accuracy, or fitness for a particular 54# purpose. In no event will Apple be liable for direct, indirect, 55# special, incidental, or consequential damages resulting from any 56# defect or inaccuracy in this document or the included data. 57# 58# These mapping tables and character lists are subject to change. 59# The latest tables should be available from the following: 60# 61# <http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/> 62# 63# For general information about Mac OS encodings and these mapping 64# tables, see the file "README.TXT". 65# 66# Format: 67# ------- 68# 69# Three tab-separated columns; 70# '#' begins a comment which continues to the end of the line. 71# Column #1 is the Mac OS Farsi code (in hex as 0xNN) 72# Column #2 is the corresponding Unicode (in hex as 0xNNNN), 73# possibly preceded by a tag indicating required directionality 74# (i.e. <LR>+0xNNNN or <RL>+0xNNNN). 75# Column #3 is a comment containing the Unicode name. 76# 77# The entries are in Mac OS Farsi code order. 78# 79# Control character mappings are not shown in this table, following 80# the conventions of the standard UTC mapping tables. However, the 81# Mac OS Farsi character set uses the standard control characters at 82# 0x00-0x1F and 0x7F. 83# 84# Notes on Mac OS Farsi: 85# ---------------------- 86# 87# This is a legacy Mac OS encoding; in the Mac OS X Carbon and Cocoa 88# environments, it is only supported via transcoding to and from 89# Unicode. 90# 91# 1. General 92# 93# The Mac OS Farsi character set is based on the Mac OS Arabic 94# character set. The main difference is in the right-to-left digits 95# 0xB0-0xB9: For Mac OS Arabic these correspond to right-left 96# versions of the Unicode ARABIC-INDIC DIGITs 0660-0669; for 97# Mac OS Farsi these correspond to right-left versions of the 98# Unicode EXTENDED ARABIC-INDIC DIGITs 06F0-06F9. The other 99# difference is in the nature of the font variants. 100# 101# For more information, see the comments in the mapping table for 102# Mac OS Arabic. 103# 104# Mac OS Farsi characters 0xEB-0xF2 are non-spacing/combining marks. 105# 106# 2. Directional characters and roundtrip fidelity 107# 108# The Mac OS Arabic character set (on which Mac OS Farsi is based) 109# was developed in 1986-1987. At that time the bidirectional line 110# layout algorithm used in the Mac OS Arabic system was fairly simple; 111# it used only a few direction classes (instead of the 19 now used in 112# the Unicode bidirectional algorithm). In order to permit users to 113# handle some tricky layout problems, certain punctuation and symbol 114# characters were encoded twice, one with a left-right direction 115# attribute and the other with a right-left direction attribute. This 116# is the case in Mac OS Farsi too. 117# 118# For example, plus sign is encoded at 0x2B with a left-right 119# attribute, and at 0xAB with a right-left attribute. However, there 120# is only one PLUS SIGN character in Unicode. This leads to some 121# interesting problems when mapping between Mac OS Farsi and Unicode; 122# see below. 123# 124# A related problem is that even when a particular character is 125# encoded only once in Mac OS Farsi, it may have a different 126# direction attribute than the corresponding Unicode character. 127# 128# For example, the Mac OS Farsi character at 0x93 is HORIZONTAL 129# ELLIPSIS with strong right-left direction. However, the Unicode 130# character HORIZONTAL ELLIPSIS has direction class neutral. 131# 132# 3. Behavior of ASCII-range numbers in WorldScript 133# 134# Mac OS Farsi also has two sets of digit codes. 135 136# The digits at 0x30-0x39 may be displayed using either European 137# digit forms or Persian digit forms, depending on context. If there 138# is a "strong European" character such as a Latin letter on either 139# side of a sequence consisting of digits 0x30-0x39 and possibly comma 140# 0x2C or period 0x2E, then the characters will be displayed using 141# European forms (This will happen even if there are neutral characters 142# between the digits and the strong European character). Otherwise, the 143# digits will be displayed using Persian forms, the comma will be 144# displayed as Arabic thousands separator, and the period as Arabic 145# decimal separator. In any case, 0x2C, 0x2E, and 0x30-0x39 are always 146# left-right. 147# 148# The digits at 0xB0-0xB9 are always displayed using Persian digit 149# shapes, and moreover, these digits always have strong right-left 150# directionality. These are mainly intended for special layout 151# purposes such as part numbers, etc. 152# 153# 4. Font variants 154# 155# The table in this file gives the Unicode mappings for the standard 156# Mac OS Farsi encoding. This encoding is supported by the Tehran font 157# (the system font for Farsi), and is the encoding supported by the 158# text processing utilities. However, the other Farsi fonts actually 159# implement a somewhat different encoding; this affects nine code 160# points including 0xAA and 0xC0 (which are also affected by font 161# variants in Mac OS Arabic). For these nine code points the standard 162# Mac OS Farsi encoding has the following mappings: 163# 0x8B -> 0x06BA ARABIC LETTER NOON GHUNNA (Urdu) 164# 0xA4 -> <RL>+0x0024 DOLLAR SIGN, right-left 165# 0xAA -> <RL>+0x002A ASTERISK, right-left 166# 0xC0 -> <RL>+0x274A EIGHT TEARDROP-SPOKED PROPELLER ASTERISK, 167# right-left 168# 0xF4 -> 0x0679 ARABIC LETTER TTEH (Urdu) 169# 0xF7 -> 0x06A4 ARABIC LETTER VEH (for transliteration) 170# 0xF9 -> 0x0688 ARABIC LETTER DDAL (Urdu) 171# 0xFA -> 0x0691 ARABIC LETTER RREH (Urdu) 172# 0xFF -> 0x06D2 ARABIC LETTER YEH BARREE (Urdu) 173# 174# The TrueType variant is used for the Farsi TrueType fonts: Ashfahan, 175# Amir, Kamran, Mashad, NadeemFarsi. It differs from the standard 176# variant in the following ways: 177# 0x8B -> 0xF882 Arabic ligature "peace on him" (corporate char.) 178# 0xA4 -> 0xFDFC RIAL SIGN (added in Unicode 3.2) 179# 0xAA -> <RL>+0x00D7 MULTIPLICATION SIGN, right-left 180# 0xC0 -> <RL>+0x002A ASTERISK, right-left 181# 0xF4 -> <RL>+0x00B0 DEGREE SIGN, right-left 182# 0xF7 -> 0xFDFA ARABIC LIGATURE SALLALLAHOU ALAYHE WASALLAM 183# 0xF9 -> <RL>+0x25CF BLACK CIRCLE, right-left 184# 0xFA -> <RL>+0x25A0 BLACK SQUARE, right-left 185# 0xFF -> <RL>+0x25B2 BLACK UP-POINTING TRIANGLE, right-left 186# 187# Unicode mapping issues and notes: 188# --------------------------------- 189# 190# 1. Matching the direction of Mac OS Farsi characters 191# 192# When Mac OS Farsi encodes a character twice but with different 193# direction attributes for the two code points - as in the case of 194# plus sign mentioned above - we need a way to map both Mac OS Farsi 195# code points to Unicode and back again without loss of information. 196# With the plus sign, for example, mapping one of the Mac OS Farsi 197# characters to a code in the Unicode corporate use zone is 198# undesirable, since both of the plus sign characters are likely to 199# be used in text that is interchanged. 200# 201# The problem is solved with the use of direction override characters 202# and direction-dependent mappings. When mapping from Mac OS Farsi 203# to Unicode, we use direction overrides as necessary to force the 204# direction of the resulting Unicode characters. 205# 206# The required direction is indicated by a direction tag in the 207# mappings. A tag of <LR> means the corresponding Unicode character 208# must have a strong left-right context, and a tag of <RL> indicates 209# a right-left context. 210# 211# For example, the mapping of 0x2B is given as <LR>+0x002B; the 212# mapping of 0xAB is given as <RL>+0x002B. If we map an isolated 213# instance of 0x2B to Unicode, it should be mapped as follows (LRO 214# indicates LEFT-RIGHT OVERRIDE, PDF indicates POP DIRECTION 215# FORMATTING): 216# 217# 0x2B -> 0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF) 218# 219# When mapping several characters in a row that require direction 220# forcing, the overrides need only be used at the beginning and end. 221# For example: 222# 223# 0x24 0x20 0x28 0x29 -> 0x202D 0x0024 0x0020 0x0028 0x0029 0x202C 224# 225# If neutral characters that require direction forcing are already 226# between strong-direction characters with matching directionality, 227# then direction overrides need not be used. Direction overrides are 228# always needed to map the right-left digits at 0xB0-0xB9. 229# 230# When mapping from Unicode to Mac OS Farsi, the Unicode 231# bidirectional algorithm should be used to determine resolved 232# direction of the Unicode characters. The mapping from Unicode to 233# Mac OS Farsi can then be disambiguated by the use of the resolved 234# direction: 235# 236# Unicode 0x002B -> Mac OS Farsi 0x2B (if L) or 0xAB (if R) 237# 238# However, this also means the direction override characters should 239# be discarded when mapping from Unicode to Mac OS Farsi (after 240# they have been used to determine resolved direction), since the 241# direction override information is carried by the code point itself. 242# 243# Even when direction overrides are not needed for roundtrip 244# fidelity, they are sometimes used when mapping Mac OS Farsi 245# characters to Unicode in order to achieve similar text layout with 246# the resulting Unicode text. For example, the single Mac OS Farsi 247# ellipsis character has direction class right-left,and there is no 248# left-right version. However, the Unicode HORIZONTAL ELLIPSIS 249# character has direction class neutral (which means it may end up 250# with a resolved direction of left-right if surrounded by left-right 251# characters). When mapping the Mac OS Farsi ellipsis to Unicode, it 252# is surrounded with a direction override to help preserve proper 253# text layout. The resolved direction is not needed or used when 254# mapping the Unicode HORIZONTAL ELLIPSIS back to Mac OS Farsi. 255# 256# 2. Mapping the Mac OS Farsi digits 257# 258# The main table below contains mappings that should be used when 259# strict round-trip fidelity is required. However, for numeric 260# values, the mappings in that table will produce Unicode characters 261# that may appear different than the Mac OS Farsi text displayed on 262# a Mac OS system using WorldScript. This is because WorldScript 263# uses context-dependent display for the 0x30-0x39 digits. 264# 265# If roundtrip fidelity is not required, then the following 266# alternate mappings should be used when a sequence of 0x30-0x39 267# digits - possibly including 0x2C and 0x2E - occurs in an Arabic 268# context (that is, when the first "strong" character on either side 269# of the digit sequence is Arabic, or there is no strong character): 270# 271# 0x2C 0x066C # ARABIC THOUSANDS SEPARATOR 272# 0x2E 0x066B # ARABIC DECIMAL SEPARATOR 273# 0x30 0x06F0 # EXTENDED ARABIC-INDIC DIGIT ZERO 274# 0x31 0x06F1 # EXTENDED ARABIC-INDIC DIGIT ONE 275# 0x32 0x06F2 # EXTENDED ARABIC-INDIC DIGIT TWO 276# 0x33 0x06F3 # EXTENDED ARABIC-INDIC DIGIT THREE 277# 0x34 0x06F4 # EXTENDED ARABIC-INDIC DIGIT FOUR 278# 0x35 0x06F5 # EXTENDED ARABIC-INDIC DIGIT FIVE 279# 0x36 0x06F6 # EXTENDED ARABIC-INDIC DIGIT SIX 280# 0x37 0x06F7 # EXTENDED ARABIC-INDIC DIGIT SEVEN 281# 0x38 0x06F8 # EXTENDED ARABIC-INDIC DIGIT EIGHT 282# 0x39 0x06F9 # EXTENDED ARABIC-INDIC DIGIT NINE 283# 284# 3. Use of corporate-zone Unicodes (mapping the TrueType variant) 285# 286# The following corporate zone Unicode character is used in this 287# mapping: 288# 289# 0xF882 Arabic ligature "peace on him" 290# 291# Details of mapping changes in each version: 292# ------------------------------------------- 293# 294# Changes from version b02 to version b03/c01: 295# 296# - Update mapping of 0xA4 in TrueType variant to use new Unicode 297# character U+FDFC RIAL SIGN addded for Unicode 3.2 298# 299# Changes from version n01 to version n04: 300# 301# - Change mapping of 0xA4 in TrueType variant (just described in 302# header comment) from single corporate character to use 303# grouping hint 304# 305################## 306 3070x0000 - 0x007F = 0x00 - 3080x00A0 = 0x81 3090x00AB = 0x8C 3100x00BB = 0x98 3110x00C4 = 0x80 3120x00C7 = 0x82 3130x00C9 = 0x83 3140x00D1 = 0x84 3150x00D6 = 0x85 3160x00DC = 0x86 3170x00E0 = 0x88 3180x00E1 = 0x87 3190x00E2 = 0x89 3200x00E4 = 0x8A 3210x00E7 = 0x8D 3220x00E8 = 0x8F 3230x00E9 = 0x8E 3240x00EA = 0x90 3250x00EB = 0x91 3260x00ED = 0x92 3270x00EE = 0x94 3280x00EF = 0x95 3290x00F1 = 0x96 3300x00F3 = 0x97 3310x00F4 = 0x99 3320x00F6 = 0x9A 3330x00F7 = 0x9B 3340x00F9 = 0x9D 3350x00FA = 0x9C 3360x00FB = 0x9E 3370x00FC = 0x9F 3380x060C = 0xAC 3390x061B = 0xBB 3400x061F = 0xBF 3410x0621 = 0xC1 3420x0622 = 0xC2 3430x0623 = 0xC3 3440x0624 = 0xC4 3450x0625 = 0xC5 3460x0626 = 0xC6 3470x0627 = 0xC7 3480x0628 = 0xC8 3490x0629 = 0xC9 3500x062A = 0xCA 3510x062B = 0xCB 3520x062C = 0xCC 3530x062D = 0xCD 3540x062E = 0xCE 3550x062F = 0xCF 3560x0630 = 0xD0 3570x0631 = 0xD1 3580x0632 = 0xD2 3590x0633 = 0xD3 3600x0634 = 0xD4 3610x0635 = 0xD5 3620x0636 = 0xD6 3630x0637 = 0xD7 3640x0638 = 0xD8 3650x0639 = 0xD9 3660x063A = 0xDA 3670x0640 = 0xE0 3680x0641 = 0xE1 3690x0642 = 0xE2 3700x0643 = 0xE3 3710x0644 = 0xE4 3720x0645 = 0xE5 3730x0646 = 0xE6 3740x0647 = 0xE7 3750x0648 = 0xE8 3760x0649 = 0xE9 3770x064A = 0xEA 3780x064B = 0xEB 3790x064C = 0xEC 3800x064D = 0xED 3810x064E = 0xEE 3820x064F = 0xEF 3830x0650 = 0xF0 3840x0651 = 0xF1 3850x0652 = 0xF2 3860x066A = 0xA5 3870x0679 = 0xF4 3880x067E = 0xF3 3890x0686 = 0xF5 3900x0688 = 0xF9 3910x0691 = 0xFA 3920x0698 = 0xFE 3930x06A4 = 0xF7 3940x06AF = 0xF8 3950x06BA = 0x8B 3960x06D2 = 0xFF 3970x06D5 = 0xF6 3980x06F0 = 0xB0 3990x06F1 = 0xB1 4000x06F2 = 0xB2 4010x06F3 = 0xB3 4020x06F4 = 0xB4 4030x06F5 = 0xB5 4040x06F6 = 0xB6 4050x06F7 = 0xB7 4060x06F8 = 0xB8 4070x06F9 = 0xB9 4080x2026 = 0x93 4090x274A = 0xC0 410END_MAP 411