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