• YES: A number of text editors have the same support for Arabic as TextEdit. They include:
• The "rich text editor" or small word processor Bean (freeware).
• The "simple text" word processor for Mac and iOS ByWord ($5).
• The share/freeware word processors iText '0.8 "Pro" ($15) and "Express" (free; 3.1). Both versions also have footnotes, uniquely in this group. (The earlier version iText without '08 (vs. 3.1.7) from the same Japanese producer does not support Arabic.)
• A more pure text editor with some formatting capability, Jedit X (2.15; $28. Not to be confused with jEdit, below).
• The shareware word processor Schreiben, and its sibling text editors in the "myOwnApp" package, myTexts, myRichTexts, myBlogEdit (€14 each).
• Scrivener, a "word processor and project management tool" for researchers i.a. (1.5.1; $40).
• The outliner tool Omni Outliner (3.9.3, $40).
• Another outliner, Opal (1.0.8, $32), a descendant of the Classic "Acta".
• A more minimalist two-pane outliner, Jreepad (1.5, free)
• The "note and idea organizer" NoteTaker (2.2.4, $70).
• The note (and project) organizer Mori (1.6, $40).
• The "journal and blog" editor MacJournal (5.1.1, $35).
• A more specialized editor for "creative writers", Ulysses (1.6; €80).
• Another creator's tool, Jer's Novel Writer (1.1.8; $30).
• The Java-based "novel writing software" WriteItNow (Win/Mac, 4.0, $60)
• The "writer's project manager" CopyWrite (2.2, $25)
• A number of simple text editors or notepads, including NovoEdit (0.5, free), Really Simple Text (1.1, free), JNotepad (0.2, free), X Pad (1.2.6, free), MoosePad (10.3.3, free), and Sidenote (1.7.3, free).
• Programming is seldom done in Arabic, but a few programming editors do have basic Arabic capablities, such as SubEthaEdit (3.2.1; €29), Smultron (3.5.1, free), ForgEdit (1.0.1 $29), and skEdit (4.1.2, shareware, $34.95).
• The "distraction-free" text editors WriteRoom (2.3.7; $25), JDarkRoom (14, free) and FocusWrite ($10) where you write on a blank (or black) screen.
• The opensource "mind-mapping" program FreeMind (0.9rc4).
• The task manager/todo-list Things (AppStore; 1.4.4, €50 for Mac, 10 for iPhone).
• TO SOME EXTENT: A couple of other programs for "creative writing" have disabled most of the formatting commands, which limits right-to-left display, but do allow you to write in Arabic. Such are WriterApp (1.4.3; free) and Manuscript (1.6.1; $25). The first is locked to Geeza, the last allows you to choose another font.
  Two simple text editors also works mostly OK; Plain Text Editor (4.2, €15) and Basic Text, Document (free). They do not display any of the installed Apple Arabic fonts and you cannot double-click to select, but they do accept some outside fonts (the SIL AAT and X fonts). The latter comes also in a version "Basic Global" which does not work with Arabic.
  The other parts of the shareware "myOwnApp" package mentioned, for diaries, recipes, to-do lists, etc. also have some support for Arabic, in text fields where applicable and/or allowing choice of an Arabic default font for each app, some also with default right-to-left choice.
• NOT REALLY: The open-source word processor AbiWord (2.4.5) clearly intends to tackle Arabic; it has several commands letting you set a paragraph or document to right-to-left and other settings relating to Arabic. But the Arab text breaks up with large gaps when you start typing, nor can you properly select Arabic text. (AbiWord is a PowerPC program that does not work in OS 10.7 or higher)
  Two text editors share a bug that hampers Arabic text editing: mEdit (2008r3, free) and Mac Notepad (8, $25). You can enter Arabic text (in mEdit only in the "single style"), but if you edit any word, it separates into isolate characters and will not join up again, it has to be retyped. mEdit does not display Apple's Arabic fonts.
  SernaFree (4.1, free) is an XML editor which allows Arabic text entry, but selection is "backwards".
  Z-Write, a straightforward text editor partially supports Arabic, but is not stable.
• NO: The programming tool jEdit (4.2) has Unicode, but not Arabic support. -- The same is true for BBEdit (9.2) and TextMate (1.5.8). -- Mariner Write (3.8, see below) does not support Unicode. -- The shareware text editor LightWay (4.1.7) does not support Unicode, either. -- Nor does Tex-Edit (4.9.8). -- Some "note pads" have support for Unicode in theory, but do not work properly with Arabic (e.g. Snap Notes, NotePad X, TakeNotes (1.3.2X) etc.).

• YES: The database modules in NeoOffice and OpenOffice work with Arabic. (In some cases, there may be a display problem in OpenOffice's list view, however, see below).
• The regular version of FileMaker (10) does allow you to enter and display Arabic text, but only up to a point. However, there is a separate Middle East version, made and marketed by Winsoft in France, that does handle Arabic fairly well ($475). As for the regular Filemaker, it sorts whatever is there correctly. But you cannot type harakat, you can only with difficulty select and edit text once entered, and it does not support Apple's fonts. Thus, a serious user of Arabic would have to go to the Middle East version.
• A "less complex" program from the same company is Bento (2, $49). It works with set-up layouts and limited choices, to simplify the process, and gives the user no control e.g. over font choice. But you can write and edit Arabic text in it, you are just stuck with the Geeza Pro font, mostly in 12 pt. It accepts harakat.
• iDatabase (2.0, $20), available also in AppStore for Mac and iPhone, is a small and simple database program with basic Arabic support, but with sorting issues (below).
  
• EndNote (X3, $250) allows you to organize, as well as enter and edit, Arabic items in your bibliography.
• So does Sente, another reference and bibliography manager (6.1, $130).
• Another reference (and PDF) manager, Papers (1.9, €30) also handles Arabic references OK.
• BookEnds, a popular reference manager, basically support Arabic (you can only use SIL or X fonts, and drag, not double-click to select - 11.0, $99).
• Reference Tracker, a fairly simple reference manager (1.6.2, $45).
• MORE OR LESS: A few smaller databases or rather list managers also have basic and fairly similar support for Arabic:
  ExLibris (AppStore, free), is a small program for cataloguing your books, and has basic support for Arabic script.
  iList Data (3.8.0), also allows entry and editing of Arabic text in a simple list view.
  EagleData (0.35) is an even simpler databse which also handles Arabic.
  iData (3.1) has the most text-friendly interface of the three, but with the same basic functionality.
  None of these three sort vocalized text correctly (see below). EagleData is freeware, the other two around $70.
• NO: Panorama (5.5.1) does not support Unicode.

Spreadsheets present two issues: Numerals that you want to calculate, and text displayed in cells. No spreadsheet I have found allows you to display calculated numbers in Arabic (Hindi) form, Hindi numerals are treated as text only.(*) Thus, the following only concerns Arabic characters, alif-ya, entered as labels into a spreadsheet.
• YES: NeoOffice and OpenOffice display Arabic text (OpenOffice has the same possible display problem as mentioned above).
• YES, MOSTLY: Excel (2011 and lower) will display Arabic characters, although Apple's Arabic fonts will not appear in its font list, you can e.g. use the X or SIL fonts (but not OpenType, see below). Editing is however limited (selection is "backwards").
• PARTLY: Apple's Numbers (09) handles Arabic slightly better than its DTP sibling "Pages" above, but has fonts issues. Basically, you cannot use actual Arabic fonts, not even Geeza: the characters break up. But if you select a non-Arabic font such as Helvetica or Times, workable Arabic characters appear which you can edit normally. Thus, if font selection does not matter, it can handle Arabic text.
• NO: A spreadsheet alternative, MESA (3.0) appears to handle Unicode and Arabic text entry, but Unicode text is not actually stored in the sheet's cells. -- MarinerCalc (5.6, see below), like its siblings, does not support Unicode. -- The "Arabworx" package mentioned above also contains a simple spreadsheet, "Arqam", but is like it apparently no longer supported.
(*) Most Arabic fonts contain both Western and "Hindi" numerals, and the spreadsheets only recognize the former as actual numbers. Some fonts use Hindi shapes for their "Western" numerals, and these will then both display and calculate in the spreadsheets (see the Arabic fonts page for details).

• YES: The presentation modules of OpenOffice and NeoOffice both accept Arabic text, and have right-to-left orientation of the slides.
• YES, MOSTLY: Microsoft PowerPoint 2011 and 2008 seem to work fine under system 10.6 (while it crashes under 10.5 if you write Arabic). You can only use the SIL and X fonts, not Apple's Arabic fonts (except Kufi!) or OpenType fonts, but you can write and edit, and bullets align to the right. PowerPoint 2004 allows you to type some Arabic characters, but you cannot edit them.
• NOT REALLY: Apple's Keynote (part of iWork 09) allows some typing and display, but you cannot really edit Arabic text, similar to its Pages fellow.

• YES: Again, Adobe programs (PhotoShop, Illustrator, Acrobat) have separate Middle East versions, from the same Middle East vendors.
• I have certainly not tested graphics programs systematically, but three smaller draw programs I have looked at, all support Arabic text:
  EazyDraw,
  Intaglio (c. $90 each) and
  BezierPrimer ($20).
  So does the image editor (paint) program SeaShore (based on Gimp, free).
• If you use the X11 environment, Inkscape (0.46) is an open-source [free] vector drawing program that is OK with Arabic; so is the Gimp for OS X image manipulation program.
• The flowchart program OmniGraffle has the same Arabic support as its sibling Omni Outliner ($80).
• The drawing modules of OpenOffice and NeoOffice handle Arabic text.
• NO: The draw program Compositor (2.9) and paint program TuxPaint (0.9.15) do not support Unicode (although TuxPaint has Arabic dialogues). Nor does the technical drawing program CADintosh (6.1). Expression (a paint program, 3.3b) does Unicode, but not Arabic in Tiger.

Email does not require much formatting, and all the programs are simpler than TextEdit in this respect. To be useful for Arabic emails, a program should allow us to write and edit the text we send, but also to display correctly incoming Arabic emails in various formats.
• YES: Many Mac users do not go beyond Mail, which comes installed on the machine. It works well with Arabic.
• Outspring (1.0.8, $49), a commercial email program (heir to QuickMail) handles Arabic well.
• Eudora (beta version 8.0b6, previously "Penelope") is a continuity of the widespread 1990s program. Old Eudora does not support Arabic, but this trial version of the new one does.
• MailForge (1.3, $40, previously "Oddyseus") is another continuation of Eudora's "look and feel", which has support for Arabic text.
• The web browser Opera also contains a simple mail client, which handles Arabic OK.
• GyazMail (1.5.8, shareware, $18) handles Arabic reasonably OK within its limited formatting.
• YES, IN REALITY: Thunderbird (2.0.0, free), the email client of Firefox, actually handles Arabic OK. Apple's Arabic fonts do not appear in the Fonts list, but if you select the Arabic keyboard you can write and edit OK in Arabic. It can also (like Eudora 8 and SeaMonkey) correct incoming mis-encoded mail.
• SeaMonkey (1.1.16, free) is a combined web browser, html editor and mail program and handles Arabic just like Thunderbird: you can write, even if the fonts do not appear in the menu.
• Surprisingly, Microsoft Entourage is also in this category, both 2004 and 2008: Switch to the Arabic keyboard, and you can write and edit Arabic text, but in the SIL-AAT and X fonts only, and using right-aligned rather than right-dominant paragraphs.
• ALMOST: Mulberry (4.0.8), an opensource mail client, receives Arabic fine, and you can write almost like in Entourage and Thunderbird. However, some display issues can cause problems (particularly parentheses break up Arabic words).
• NO: Powermail (6.0.2) displays incoming Arabic HTML, but not plaintext emails, and does not support Unicode keyboards. -- Mailsmith (2.1.5) also does not support Unicode.

  See below for more detail on email programs.

Web design programs are of two types: One is "graphical" editors where you write the text as in a word processor, and the program creates the html code for you invisibly. The other is html editors where you edit the code manually. "Arabic support" means that you can write and edit Arabic text, and that the program codes it correctly for the web: It must either convert each Arabic letter to an html "character code entity" (as was required earlier); or it must add a "charset" header that tells the browser to display the text in Unicode.*
• YES: The DTP program Create makes OK Arabic pages based on table layout, with CSS stylesheets and the correct charset header ($150).
• RapidWeaver is a simple "graphical" web editor ($40) that supports Arabic. It shows you the html code, but you cannot edit it (unless you have chosen "HTML Code" as page type). It correctly enters the charset header.
• Another small web editor, GoodPage ($99), uses a more "hands-on" approach, you can either work in a text window or a code window. In the text window, you can write and edit Arabic text, but there is no font choice or other Arabic formatting; Geeza 12 pt. only. Arabic text is coded as html entities, and thus appears correctly in a browser.
• The opensource web editor KompoZer (a continuation of Nvu) basically supports Arabic, but is excruciatingly slow (for me, anyway). You can choose whether the page should have html entities (Latin1 encoding, the default) or Unicode with the correct header.
• The regular version of Dreamweaver supports Unicode, but has only partial support for Arabic: Arabic words break up in the editor window, but if you paste in Arabic text (e.g. written in TextEdit), the result is viewable as Arabic in a browser. Still, for serious work with Arabic in Dreamweaver, the Middle East version (CS4-ME, not tested, €587/$685) is probably required.
• OpenOffice has a web editor module, which is of the word processor type and adds the charset header.
• SeaMonkey, the web browser, also has a "graphical" web editor. It has the same font display issues as the email client (Geeza only), but it adds the charset header.
• Some general word processors also have a "save as/export to HTML" option, which do apply the correct charset header and so can produce Arabic text for the web. Thus TextEdit, NisusWriter, NeoOffice, Jedit, Bean, and iText. The same applies for the programming editors SubEthaEdit and skEdit. (The other programming editors also do html code, but do not add the correct charset header, so the user must do so.)
• NOT QUITE: Taco HTML Edit (2.0.6, $25) is an html code editor which allows you to write and edit Arabic. But it neither converts the Arabic to html entities nor inserts a charset header. It does however warn you to add such a header, but you must do that yourself manually.(*)
  The same is the case for the html code editor Coda (1.6.4, $99), you can write and edit Arabic, but must add the charset header that makes it readable in the browser.
• NO: One cannot really say that the programming editor QuoEdit (1.1.5, shareware $10) supports editing Arabic text, although it correctly enters the html entity code. But it does so as you are typing, at once you type "ب" it turns into the html code "ب", so it becomes unreadable and thus uneditable (but does turn up correctly as "ب" in the browser). -- Page Spinner (5.1) does not support Unicode editing.
  * The header format is: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">.

• YES: OpenOffice and NeoOffice have been discussed in the various program categories above, and seem to have found full use of Arabic, with one or two minor glitches, discussed below. LibreOffice is a variant of OpenOffice.org, and seems to behave pretty much like it in Arabic support (rather than like NeoOffice).
• PRETTY MUCH: GoogleDocs uses a web browser to let you create and edit simple word processing, spreadsheets, presentation and drawing documents. All these have rudimentary Arabic support; that is, you have only a few fonts available, and paragraph layout is left-to-right, but the text itself can be edited OK (tested in Chrome and Safari).
• NO: AppleWorks does not support Unicode, and thus no Arabic (it is partially replaced by the "iWork" package containing Keynote, Numbers and Pages, which has only partial Arabic support, see below). -- RagTime (6.5) supports Unicode, but not Arabic. -- The Mariner package does not support Unicode at all, except for their MacJournal which has full support for Arabic. -- ThinkFree Office (2.3) has Unicode, but Arabic does not work.

• YES: The early versions of iPhone and iPod Touch were fairly limited in their "international" capacities, outside of Europe. However, with software version 3.0 in 2009, iPhones / iTouches finally got Arabic and Persian capabilities. You go to the "Settings : International" panel, and there you will find Arabic listed under "Keyboards" as well as "Language". If you choose Arabic as "Language", that will then become the main lanugage of your iPhone; the apps "Weather" and "Contacts" become "al-Taqs" and "Jihat al-ittisal", etc. Not everything is translated (Mail is still Mail), but many system texts display in Arabic. (Persian is not supported here, but Hebrew is.)
  If you don't want so radical a transformation, leave "Language" unchanged, and only select Arabic under "Keyboards". That adds an Arabic-Persian keyboard layout: Whenever you type on the iPhone/iPod keyboard, you see a little globe key next to Shift. Clicking it switches to the Arabic keyboard, and you can type away. To type the Persian characters, hold e.g. the "b" character for a second, that will display the "p" as an alternative character. The same method for short vowels, press the "nunation" key, and for hamzas, click and hold the carrier letter.
  I have not checked the Arabic in many apps that allow entering text, but it seems to work in most of those I could test (not iDisk app, though). In my Spreadsheet app, I can type Arabic (Hindi) numerals and they are treated as numerals (unlike on the Mac), but the result of calculations appear in Western numerals. Left/right dominance seems to follow the "first character principle", i.e. if the first character in the paragraph is Arabic, the para becomes right-adjusted and right-to-left dominant; if the first character is Latin, it becomes left-adjusted. Thus at least in Mail and Notes. Arabic in Safari seems to appear OK.

• For Arabic spelling checking, you can use CocoAspell, which allows you to increase the number of languages you can spell-check in word processors that follow the Apple standard, such as NisusWriter, Open- and NeoOffice, Mellel, TextEdit, Mail and many others. The dictionaries, which include Arabic, Persian, Hebrew and several dozen other languages, can be downloaded from ftp://ftp.gnu.org/gnu/aspell/dict (CocoAspell is the Mac OS X "face" to the Unix aspell program).
• A small on-line dictionary called WordLookup can do simple translations English-Arabic and, less developed, Arabic-English ($14). It uses a Unix-based dictionary, al-Qamoos (from "Arabeyes"), for the word lists.
• Another on-line translation service, with some synonyms added in context, is Lingo24, in both directions Arabic/English.

  For some links to Arabic teaching tutors and other software, see the Links page.

• I have not discussed X11 programs to any length here, as I have little experience with these types of programs. However, as of OS X 10.5, all Macs have this alternative Unix environment installed by default, so you can download an X11/Mac program (often free) and use it alongside your regular programs. You will notice that it will look quite different from other Mac programs, but many X11 programs work fine with Arabic, so if there is a particular type of program you need that does not seem to exist in regular Mac ("Aqua") versions, you may be able to find an X11/Mac alternative.

  Notice a couple of things, however, for using Arabic in this environment. First, X11 defaults to its own (English) keyboard. You must in "X11 Preferences: Input" check Follow system keyboard layout, to be able to type in Arabic. Notice also that not all X11 programs can see the fonts in your user account fonts folder (which is where FontBook normally places any fonts you install yourself), only the general "[Macintosh HD]: Library: Fonts" folder. If so, move any Arabic font you want to use into that folder.
  X11 does not work with Apple's Arabic fonts, but accepts all OpenType fonts, and can handle some fonts the regular Mac cannot in Leopard, such as Arial Unicode and Tahoma. You would want to add some OpenType fonts to your machine, however, for X11 if you have not already.

How well is Arabic supported? The detail

That is the general overview. But what does it actually mean to "support" Arabic? Above, I have simply listed those programs that give you access to Arabic fonts and combine the letters into words, the very minimum for writing and displaying Arabic. But the ideal is of course that we can produce an Arabic text "just like in English" - some companies even claim that, although no-one has such as thing as a built-in Arabic spell checker (although some allow an external Arabic spelling dictionary). And of course, to write mixed Arabic and English produces special challenges. But, using old NisusWriter under Classic as a baseline, what we would want to see for a realistic "full support for Arabic" would be:

• Right-to-left reversal of paragraphs, not just text, meaning that things like tab stops and first-line indentation run from the right margin, not left.
• Right-to-left footnotes, with the choice of whether footnote numbers are displayed in Arabic or Latin numerals.
• The font selection is remembered when you switch from Arabic to English and back.
• Left and right parentheses and brackets should operate logically.
• Sorting of Arabic text should be correct, ignoring harakat.

This is a short list. Let us see how the word processing programs mentioned measure up:

Every program here will allow you to align a paragraph to the right-hand border, with an uneven left hand margin. Together with Arabic text also running from the right, of course, this can give you an apparent approximation of an Arabic paragraph.
But if this is all the program does, you cannot use a "justified" paragraph format where both left and right margins are straight (the last line of the paragraph will, like in English, align to the left). And, in such fake right-aligned paragraphs, tabs and first-line indentation will also start from the left, as they do in normal English. Furthermore, if you have an English word inside an Arabic sentence, such a limited program will confusingly display the first Arabic bit to the left of the English, and the last to the right, because it arranges the "blocks of text", Arabic and English, according to the English order, from left to right.

So that is not enough for serious work. Instead, the program must have a function to mirror all commands for the paragraph to the right, so that first-line indent, tabs and justified paragraphs all run from the right, as well as organizing text blocks correctly.

All the word processing and text editing programs that we list as supporting Arabic have some form of right-to-left paragraph command. That includes: Mellel, NisusWriter, OpenOffice, NeoOffice, AbiWord*, InDesign ME, Nashir, Horuf*, Create, as well as a group of programs that share the facilities of Text Edit, including: Bean, Jedit X, iText '08, Schreiben and its siblings, Swift Publisher, Ulysses, Jer's Novel Writer and others, also OmniOutliner, EndNote and FileMaker ME. However, the level of control differs between them, and you find the command in different ways, sometimes slightly out of sight.

In this last group of programs that follows the pattern of TextEdit, there is an option "Writing direction: Right-to-left" in the Text menu (or control-click in the paragraph). This will change the paragraph, text blocks, justification, etc. to correctly right-oriented. The tab and indent settings on the ruler do not appear to change, but they do actually indent properly in the text, it is just not visible on the ruler. A bit disconcerting, but it works.

Proper right-to-left paragraphs including tabs and indents appear to work as they should in NisusWriter, Mellel, OpenOffice, NeoOffice, InDesign ME, and AbiWord. You can in these programs set the paragraph to right-to-left by an icon on the ruler, or in a "text" toolbox panel. In Open- and NeoOffice you must however check the preference "Complex Text Layout" to see this icon. All of these also have additional functions for right-to-left dominance of the entire page, section or document, not just each paragraph: this will also reverse left-right headers, margins, gutters and/or other document settings.
-- The two outliners listed, Opal and OmniOutliner are basically in the "sisters of TextEdit" group and share its Arabic handling, but only OmniOutliner has a Writing direction option. Opal uses the "first element decides" system; i.e. paragraphs starting with Arabic will organize mixed Arabic/English text blocks from right to left, those starting with English, left to right, and paragraphs are always left-aligned.

There are some problems, however, in some programs: In Horuf,* tabs do not work in either script, but justification and indentations are fine. -- In FileMaker ME, the first-line indent icon is mirror-imaged; displays at left edge, but works from right, while the general indent icon is not mirror-imaged. Tabs work fine, and FM allows setting left/right dominance of individual fields and records. -- As mentioned above, Nashir Sahafi has only right-to-left paragraphs, tabs etc., with no choice or settings to be made. You can of course left-align a paragraph, just like you can right-align in Word. Tabs seem to work strangely, both in RSG and Nashir -- Command-space does not always work in WriteRoom, but pressing Command shows the keyboard menu. You can set the (universal) font and options in Preferences.

The problems are more pronounced under Mac OS 10.3 (before 2005). A bug in system 10.3 causes the last line of a justified paragraph to run from the left in Nisus even when you have chosen "right to left" (the same is true in TextEdit, Swift Publisher, Jedit X, Ulysses and Create). Nor does indentation or tabs work from the right in any of these under 10.3. They do, however, all have right-to-left ordering of Latin and Arabic text segments; in Nisus in a menu or Tooldrawer, in the others through an option in the contextual menu (control-click in the text) or Format menu. (*) As mentioned above, AbiWord cannot handle Arabic display and has not been upgraded to Lion compatibility. As an open-source product, it is not clear if it is abandoned, but as it has/had Arabic ambitions, we include it here with its current features. -- Horuf, as mentioned above, worked under system 10.3, but not in 10.4: Choosing any menu would freeze the program, which as noted seems no longer to be available on its website. Thus, the comments only refer to testing done under system 10.3.

The text editors and DTP programs, except InDesign, do not have footnotes. In those that do, some relevant questions are:
- Can footnotes run from the right? Yes in Nisus, Mellel, AbiWord, OpenOffice, NeoOffice, InDesign, and iText.
- Can footnote numbers be in Arabic? Yes in Mellel (individually), OpenOffice (by paragraph direction), Nisus (universally for document), and NeoOffice (program default only); No in AbiWord and iText. In InDesign numbers seem to be only in Arabic. But it does have both Roman i-ii-iii and abjad numbering. (Nisus, OpenOffice and NeoOffice also have abjad numbering.)
- Can the footnote separator line run from the right? Yes in Nisus (different per section), OpenOffice and NeoOffice (per page), and Mellel (universally for the document); No in AbiWord and iText. InDesign again only from the right, but you can set the offset.

As for what fonts you can use, this varies with your Mac as well as program. On Macs from 2008 or later, most programs such as TextEdit and its sisters, NisusWriter etc. can display a number of Arabic fonts that did not work in these programs before. Then, these "OpenType" Arabic fonts could only be used by a separate group of programs: Mellel, AbiWord, InDesign, FileMaker ME and Horuf. Thus, the difference there was between these two groups of programs has been evened out. (But some program still cannot use Arabic OpenType fonts, thus OpenOffice and NeoOffice, also regular FileMaker.)
However, the early adaptation to OpenType came at a price: Some regular fonts have special typographical features beyond the basic display. If you for example write lam-mim-jim in al-Bayan, the two first letters will be "stacked" vertically. These features do not work in the OpenType group of programs, but in all the others.

Further, Apple has hidden a nice little tool for us. In TextEdit, open the Fonts panel and make it so wide you can see a little cogwheel menu at the bottom left. Under there is an item called "Typography". It allows you access to hidden features in the font you select. In GeezaPro, you can display numerals in Arabic or Persian varieties, in other fonts a medial ha can be "knotted" (circle above and below baseline) or "hooked" (just going below baseline). What is available changes from font to font, the SIL fonts (see below) allow you to use Sindhi, Urdu, Kurdish, and other ha's as well as numeral forms from this menu. However, only TextEdit and those that follow its lead (Bean, Jedit, iText, Swift Publisher, etc.), as well as Nisus allow access to this menu (Neo- and OpenOffice, which otherwise follow Apple, do not). FileMaker ME has a special command that switches numerals in a field between Arabic and Roman.

A small feature works in a few fonts, not in others: Type "Allah" straight without harakat (alif-lam-lam-ha) and the system will replace it with the "Allah" ligature, with shadda and dagger alif. Works in all tested programs except the OpenType ones: TextEdit and its sisters, Nisus, Open- and NeoOffice. Among the standard fonts, it works only in Bayan and Geeza, but in a number of OpenType fonts under system 10.5. (see Arabic Fonts for a list of which fonts. -- Under 10.4, Geeza does not show this ligature. In those that did, although you had to type the alif: "Allah", only "llah" appeared in 10.4.) One issue puts the two major DTP programs at opposite extremes: the sequence lam-fatha-alif, which should become a lam-alif ligature with the vowel over the lam. Nashir cannot handle this sequence, and does not create the lam-alif ligature at all. InDesign does, and it alone places the fatha correctly over the lam. All others place it over the alif.

When you switch between English and Arabic while typing in a text, it is useful that the program remembers which font you used in the other script: When I write in the Baghdad font, switch to English and choose Helvetica, and return to Arabic by command-space, I want to get back into Baghdad, and then to Helvetica next time I switch back again, otherwise I have to go to the Font menu each time I switch between typing English and Arabic words in the same text. Nisus Classic did it, but this is apparently very difficult now, only two programs do so. There are now three basic types of behaviour:

(1) A single font choice is remembered across scripts. That means that when I have selected Baghdad and keep typing, Baghdad is the font I type in whether I switch to English or not, until I go to the Fonts menu and choose another. Since Baghdad has no English characters, the English word will be displayed in a generic "default font", such as Lucida Grande or Times. If I don't like that, go the fonts menu and change the font to e.g. Helvetica while I am typing, Helvetica will be the font also for any Arabic I type afterwards - and since, vice versa, Helvetica has no Arabic letters, so that text is then displayed in the default GeezaPro. This is the most common behaviour: TextEdit and its sisters like Bean and Jedit; AbiWord, Nashir, and InDesign ME all behave thus.

(2) The font choice is remembered separately for each script. That is the behaviour we want; I type in Baghdad, switch to English and choose Times and type the English word, switch back to Arabic and am still in Baghdad, and in Times again when I again switch over to English. OpenOffice and NeoOffice are the only programs that do this - almost. They do not quite remember the font if you just command-space to English and choose a font in the menu, you must select an English character and set the font for that. But that done, they do remember each script's font choice separately.

(3) The font choice is not remembered automatically, but the user can set up some personal choices for what the default font should be for each script. Both Mellel and NisusWriter as well as Open- and NeoOffice allow you to define such a combination of a "primary" and "secondary" font in different ways: In the Offices, you can set a general default font for the "western" and another for the "complex" (i.e. Arabic) script. In Mellel you can at any time set up a "primary" (Latin) and "secondary" (Arabic) script / font combination, and command-space switches between them until you make another choice. It is like making a double font choice instead of just choosing one font from a normal Fonts menu (which Mellel does not have). In NisusWriter, you can set up "language settings" which include a choice of which "secondary" script with linked font that command-space will take you to in that language. It does not have a default font for the language itself (the primary script), though, and while it will remember any manual font change you make when typing in the secondary script, even after switching to the primary language and back, it will lose track of the font you chose for the primary script, and use a default font for that when you type on. For this reason, it is recommended to link these language choices to character styles. In these programs, the default fonts may be in different sizes, better than in Nisus Classic! and useful in Arabic (in NisusWriter, the size choice is not remembered.)

An even more primitive behaviour was common in the earlier system 10.3: Each time you switched script, the text appeared in the deafult font of either script: Lucida Grande for English, Geeza Pro for Arabic. No font choice was remembered and you had to set the font each time manually. That was the case in TextEdit, Horuf, Swift Publisher, Create, Jedit and Ulysses under 10.3, and may still be the case by less advanced programs today.

Here, Mellel's double font system shows its worth: When you make sure that "secondary font" is turned on, changing the primary font only affects the Latin text, not the Arabic, even when there are several Arabic fonts in the selection. In the other programs, you have basically two other options. One is to create separate "character styles" for Arabic and English text before you write/edit, and apply these styles to all Arabic and English in the document. Then you can change the fonts of one language without affecting the other by modifying the relevant style(s). That approach can be taken in Nisus, Open- and NeoOffice, and AbiWord, as well as in Mellel.

The other is to use "Find-and-Replace". Nisus, Mellel, Open- and NeoOffice allow you to use font as a search criteria in Find-and-Replace, so that you can "find" all (or some) text in Helvetica and "replace" it with the found text, only now in Times, without touching the Arabic or any other font. TextEdit and many, but not all, of its sisters have a similar function hidden away: Select a word in the font to be changed, locate a menu most often called "Style: Other" in the ruler or Format menu and click a "Select by font" button. That allows you to select all occurrences of that font and you can choose another font for the selection, with the Arabic text unaffected. Besides TextEdit, such a function is found in Bean, Jedit X, iText, Schreiben, myRichTexts, Jer's, and Manuscript, but not in Swift Publisher.

Finally something I do not know is a bug or a feature, but it certainly behaves as a rather annoying bug: parentheses and brackets. The problem is: Are the parentheses "opening" or "closing" or are they "left" and "right"? In English, an opening parenthesis is a "left" parenthesis, i.e. it curves to the left. In Arabic, an opening parenthesis is one curving to the right. And this confuses the system no end. What I would think is the correct behaviour in Arabic is: when I start a parenthesis, I type Shift-0 to produce a right-curving, then type the text inside, then Shift-9 for a left parenthesis to close it. Nisus in Classic bears me out, that is how it works there: parentheses are just characters like any other.

In OS X, when you type Shift-0, you get an "opening" parenthesis, and the systems insists on deciding whether it should curve left or right, dependent on whether the paragraph is left-dominant or right-dominant. In some cases this causes the Arabic parentheses to function as if they were English (Latin) characters.

How do the various programs tackle this?
     For one thing, when you type Shift-0 for an opening parenthesis, you will often see a left (i.e. closing) parenthesis appear, until you type the following Arabic letter. Then the parenthesis switches around to become a right curving, as it should, and will proceed correctly. Disconcerting, but not major.
     However, there may be a problem if an Arabic phrase in an English left-right (LTR) paragraph starts with a parenthesis. It seems that parentheses take their "script info" from the letter in front of them. So, the opening parenthesis, with no Arabic letter in front, becomes "English" and stays to the left of the phrase, while the closing remains "Arabic" in its correct placement, and both thus curving left. But only if there is no Arabic letter in front of the opening parenthesis, if there is, all appears correctly, and of course also in a Right-to-left paragraph. Thus in TextEdit and its sisters; NisusWriter, Open- and NeoOffice, also AbiWord. The last four of these allow you to remedy that by inserting a right-to-left direction mark.
     -- In Mellel, both parentheses in this case take their cue from the paragraph direction and become left-to-right - both curve naturally, but the text before the parenthesis appears to its left, and the text after it to the right. Thus, parentheses are then even in Arabic fonts in an Arabic phrase considered Latin characters. Here too you can override this with a Direction command. -- InDesign ME seems to work fine (tested under 10.3 only). -- Horuf reverses the parenthesis under right dominance, but not under left. Under left, however, the parenthesis causes the line to reorganize, as if they were Latin characters. You may "fake" the correct behaviour by typing the Shift-9 before and Shift-0 after, rather than the opposite (under 10.3). -- Nashir has only right-left paragraphs, and thus works fine.

Alphabetical sorting is more of a database issue than word processing, but some word processors have a sorting function. Generally, Arabic will sort correctly, as long as you have unvocalized text. However, there are some features we would want to see for correct sorting:
- Vowel markers, harakat, should be ignored in sorting, so that Ahmad appears in the same place in the list whether it is written with vowels or not.
- Similar with hamza or madda carried on alif or other carrier, they should sort together with the carrier, again so that Ahmad appears in the same place whether or not the hamza is written.
- Arabic ya, farsi yeh and alif maqsura should all sort together, even if a suffix is added to a maqsura rather than a ya, it should not affect the sorting.
- It would be nice to have alternative Persian sorting for waw before ha, as well as proper placement for the Persian characters p, tch, g, etc.

No program unfortunately gets all of this quite right, although two get close. All programs will sort a purely consonantal text correctly. But all of them treat alifs and waws carrying hamza or madda as separate characters, normally placed before regular alif. Most also separate ya, yeh, and maqsura. Only two have a working Persian sorting option, but most programs place the Persian consonants (p, tch, g) correctly anyway. The main difference between them - and this is perhaps also the most important for regular usage - is how they treat the harakat, short vowel markers.

This is how the programs stack up:
OpenOffice, NeoOffice, Mellel and NisusWriter sort harakat correctly. Open- and NeoOffice are the two with a "Farsi" option, and with this selected, waw does sort before ha, as it should in Persian, and ya, alif maqsura and farsi yeh are sorted together, the only place where this happens. The only thing missing is that hamza carriers are still separated, now before alif, so that "awwal" with hamza and "ân" with madda both sort before "ab" with plain alif. Under the "Arabic" options, the three ya shapes are sorted as three different characters. Nisus does also have a Persian language option, but it does not affect sorting. Both it and Mellel (from version 2.8) sort p, tch, g correctly. -- Jedit X sorts Arabic consonants correctly, but not the Persian ones. Short vowels are sorted correctly, but not shadda. -- AbiWord does not have sorting capabilities.

Interestingly, BBEdit, although it cannot display Arabic, does sort Arabic with harakat correctly ignored - you just need to copy the text to another program to see the result. -- The same is true for Microsoft Excel 2004, while it has limited support for Arabic text entry, it does sort vocalized Arabic almost correctly (vowels and sukun are ignored, but not shadda). The same is even true with Word, it sorts almost correctly, although you cannot see the result! Both of these sort ya and maqsura together, but farsi yeh apart (and they organize the internal order of hamza carriers slightly more logically).

Of the database programs, FileMaker sorts like Nisus and the Offices; harakat and Persian consonants are correctly placed (both in the standard and Middle East versions). -- The same is true for Bento and EndNote, all harakat are ignored, Persian consonants are OK, but hamza carriers and the three yas are sorted separately. -- iDatabase and the four list managers ExLibris, iList, iData and EagleData all sort short vowels as separate characters after ya, so that Ahmad with vowel over the initial alif is sorted between unvocalized Ayman and Badr. None of them place Persian characters, hamza or maqsura correctly, so their sorting is only OK for straight Arabic consonontal text. The same is the case for the outliner Opal, while OmniOutliner sorts like Nisus, all correct except hamza, madda and the alternate yas.

Under OS 10.3, Nisus and Jedit also sort all harakat after ya.

You can of course in any program create a PDF (Acrobat) file through the Print dialogue. PDF creation is something of a black magic art, but Apple has made it very easy for us. For Arabic to work in PDFs, the creator must "embed" the Arabic fonts used into the file, so that we do not rely on the reader having the same font of his machine. The Apple PDF maker does so as standard, so Arabic PDFs made through the Print dialogue are viewable on all machines, irrespective of whether they have Arabic or not installed.

However, Arabic PDFs created in this way are not searchable, nor can you extract text from it to a text-only file, as you can in English pdfs (or these functions are patchy, depending on the font and formatting used in the file; right-aligned files are better than justified). This has to do with how Apple creates the PDF. There are reports that PDFs made through other means, as with InDesign or similar, will give more searchable files, but I have not had the chance to test to confirm or deny this. Using Adobe Acrobat, regular ($300) or Middle East ($570) may or may not make a difference. Until such solutions are found or confirmed, assume that Arabic pdf files are fine to read by humans, but not necessarily by computers.

When you get Microsoft Office 2011 with Word installed, you will not find any menus or other reference to Arabic or Right-to-Left, and if you open a new file and try typing Arabic, you will get goobledygook as before, it will seem no different. However, Microsoft has in fact now added some support for typing and editing Arabic, you just have to go through some tricks to get there.

Basically, Word will not let you initiate Arabic text in a new document, but it will let you import Arabic from another application and then allow you to edit it. It seems that for Word, the "Arabic" identity is an aspect of a text item (word, sentence) that Word cannot assign itself, but will recognize when established elsewhere. Thus, if you import a document with mixed Arabic and English, both will appear OK, and you can change and add to the Arabic text that was imported. But if you try to start writing Arabic elsewhere in the document (below the English text, e.g.), you will get separate and confused letters, not OK. However, if you copy some of the good Arabic text that was imported down to the same place, it will still be OK, and you can change it and also keep writing as long as you like: The text has now been "identified" as Arabic, and Word will respect that.

This seems to give us the key to how also to use this consistently:

1. In an Arabic-capable program(*), write a few Arabic words, and save the document (or, find an existing Word for Windows document which contains Arabic text).
2. Open that file in Word 2011. Arabic will appear correctly (although perhaps left-adjusted instead of right).
3. Open the "Styles" dialogue, and create a Style based on that Arabic text - you change the adjustment to what you prefer. Call it e.g. "Arabic text". At the bottom, click on "Add to Template", and OK.

There are some restrictions and peculiarities, however:

• Word does not recognize Apple's Arabic fonts, they do not appear in the font list. You can only use actual OpenType fonts (thus not the X-fonts, even though they appear in the list). However, using the Style trick above, in my case at least the Arabic text intially appears named as "Al-Bayan", a font that Word does not accept!, and I have to select the correct font for it manually (the font that actually appears is Times New Roman, which of course works OK, as it has Arabic OpenType characters).
• Word has no menus for "writing direction" or any way to manipulate Right-to-left editing, as discussed above. However, once a text block (paragraph) has been "set" to Arabic in the manner above, by importing or style choice, it seems that it blindly inherits right-to-left behaviour. There, like in Text-Edit etc., the paragraph settings icons are mirror-image of what happens: Tabs and indents appear on the ruler to run from the left, but in that paragraph they actually run from the right. Similarly, right-adjusted text appear as "left-adjusted" and so on. But fully aligned text appears correctly, with the last line running from the right.
• Word is not happy with mixed Arabic-English text. If you have used an Arabic style, you can add English text into that paragraph, but you cannot then change the font; the English word will appear in the Latin default of the Arabic font (such as Times New Roman). The other way around, however, Arabic words copied into an English paragraph, seems to work, Arabic font changes are accepted.
• (*) Word does not appear to accept just any Arabic-capable program for your "origin" document. If you do not have a Word for Windows document with Arabic to start out with, you may be lucky and get it to accept a TextEdit or NisusWriter file, but often it will not. Saving from Open/NeoOffice (in "proper" .doc format) seems to be a better bet. But once you have hit the jackpot and found a document that works, the Arabic style seems to stick for new documents you create. (If you cannot find such a document, I have added a small "ArabicOrigin" Word document you can use.) Just note that text that is initially "wrong" does not seem to convert into correct Arabic even if you apply the Arabic style to it.

What do you do when a Windows user sends you a Word file with Arabic, which you want to edit and return to her in the same format that she sent it? You cannot open it in Word 2008 or earlier, since you will not be able to read the Arabic there, and opening and saving the file in another Mac program may change the layout or other formatting on her side. In Word 2011 you can then open & edit, experience will show how much that mangles the original text. But certainly until that version is generally used, this is a common situation, and the result of course depends on how she has formatted it, etc. But let us assume the most straightforward case, which is an MS Word file in .doc or .docx format, using Times New Roman as the only font. What is the best program to work with this file on the Mac without having to change any font or other setting?

My choice would be NeoOffice. It can open files the new Windows Word format, .docx, and it saves files back into the original format (it asks you whether to save back into Word format, or to change to its own OpenDocument format). NeoOffice cannot in fact display the Arabic characters of Times New Roman (which is OpenType, the Offices don't handle that), but it displays the Arabic in Geeza which is close enough, and it saves the Arabic back as Times New Roman. Opening, working your changes, and saving back into Word format should make the file format indistinguishable for the original user, with both Arabic and English saved as Times New Roman, OK for the Windows user, unless you changed the font setting manually. This should work fine in system 10.4 and higher.

NisusWriter will do almost the same in system 10.5 (and higher), displaying readable Arabic characters. It saves back into .rtf format, though, which the Windows user can read, but isn't quite the original format. You can also make Nisus do this in 10.4, Nisus will here also display Windows Arabic text readably in Geeza. But if you have ever installed Microsoft Office on your Mac, you will also have got their version of the Times New Roman font, which Nisus will display as disjointed characters (when the Windows file is in the TNR font, which very often they are). If this appears, see the discussion of this font to sort that problem out. -- Mellel and TextEdit will open the file, but both discard the font information, and display and save it in Helvetica and Geeza (from .doc files. They retain the font info from .rtf files). Of course, you can in both programs change the font back to Times New Roman manually. -- OpenOffice does not substitute the fonts, and displays disjointed Arabic from Times New Roman. There you must manually choose a different font for the Arabic. Naturally, you can do that, and change it back to the original font when you return it the Windows person (as she will not have Geeza on her PC!), but it does quickly become tedious.

Other programs

Editing Arabic: Fonts: The only email program that supports OpenType fonts fully under 10.5 is the small GyazMail. Of the others, Mail and Outspring come close, most OpenType fonts can be used without harakat but break up with vowels; others appear as Geeza and are thus readable (in 10.6, performance is much better). The other programs mostly let you edit in Geeza only; MailForge, Entourage and Mulberry also in SIL AAT and X fonts. Normally, if you select any other font, you will see only Geeza, which of course still displays the text correctly. A number of programs do not display Apple's fonts in the Fonts menu, but only third-party fonts (MailForge, Entourage, Mulberry, Eudora 8, Thunderbird, SeaMonkey - the last three are all based on a shared Mozilla basis, so it is not surprising they handle text quite similarly. In MailForge, Entourage and Mulberry, OpenType fonts appear not as Geeza, but disjointed, as in 10.4.) Opera does not allow multiple fonts or font choice. GyazMail as well does not have font menu or allow multiple fonts, but you can set a default font (common to Arabic and English text) in Preferences.

Paragraphs: Mail, Outspring and Opera have a writing direction command, which controls the order of Arabic/English text blocks. This inserts a "direction:rtl" code in html-formatted mail, which is often recognized by the receiving program. The Mozilla trio is locked to left-to-right order of text blocks; MailForge, Entourage, GyazMail and Mulberry follow the "first block of the line determines" principle. All programs follow the "TextEdit behaviour" in the issues discussed on mixed English/Arabic text (remembering font selection, changing fonts, parentheses).

Receiving Arabic email: Formats: All programs discussed here receive Arabic email both in HTML and plaintext ("flowed" or similar) form. In HTML-formatted mail, Mail, Outspring, Eudora, MailForge, Opera and Mulberry recognize included font specification (even though the last two do not let you edit in the same fonts), all except Entourage and Mulberry will recognize the HTML command for right-to-left text.

Text encoding: A specific issue with email concerns "encoding", or character sets. Today, most Arabic you get is in Unicode, so generally the programs have no problem. However, old software may still be using pre-Unicode character sets, and a good program will recognize this - in two ways: If the program that sent the email labelled it correctly as "[old] Macintosh Arabic" (called "iso-8859-6") or "old Windows Arabic ["cp-1256"], the receiving program should automatically recognize this, and display the Arabic text legibly in Unicode, which we use on the Mac today. All these do that (except MailForge, which recognizes iso-8859-6, but not Windows-1256), so no problem there, you will not even know if you receive such an encoding.

However, some old software on the sender's side put in the wrong header. If the mail is actually sent in the Windows Arabic encoding, but labelled incorrectly as regular "iso" or with no label at all, it will appear with incorrect Arabic letters. To correct that, good software should have an "Encoding" or "Character set" menu so that the user can override the automatic choice and choose "Windows Arabic" for an email that clearly was sent in this encoding. Five programs only here allow this, the Mozilla trio: Eudora 8, Thunderbird and SeaMonkey, GyazMail and Mail. In Mail, you must add Arabic to your languages in System Preferences (International: Language, click "Edit List..."). Entourage also has an Encoding menu, but without Middle Eastern language options (the Mozillas go wild in dozens of old and obsolete encodings), Opera has the basic two, Mac and Win, but the menu has no effect. -- You should certainly not today send in such obsolete encodings, but just out of curiosity, do any program allow you to make this choice? Mail, Thunderbird and SeaMonkey do; the latter two warn you that this is a bad idea, but let you override, and they set the appropriate header. Eudora appears to allow it, but ignores your choice and sends in UTF-8 (Unicode) anyway.

As OpenOffice and NeoOffice are developed on the same basis, their database modules are fairly similar, composed of table, form, and query views. OpenOffice does however have an issue concerning the default font in the list view in database and formula bar in spreadsheet. Which font is used seems to be picked at random from fonts on your computer, including some non-Arabic fonts that have Arabic letters but do not combine them properly. Then Arabic will appear disconnected in these boxes in OpenOffice. Under OS 10.4, this includes the system font STSong, but may also include e.g. Arabic OpenType fonts that work in other programs, but not in OpenOffice. If you deactivate these fonts in FontBook, OpenOffice will display Arabic correctly also in these list views. This issue may be more relevant if you tend to stock many Arabic fonts on your computer than otherwise. NeoOffice does not seem to have any problems in this respect.

As for the other relevant programs, EndNote shows - and respects - the contextual Writing Direction menu. (Bento does not, nor regular Filemaker)
Of the three list managers, iData allows most manipulation of the text, you can have one "free-form" field per database where you can use TextEdit-style Arabic text editing, including right-to-left paragraphs (under control-click), but only in that one field. The other two programs display data only in list format. iList allows you to set fonts for display and editing, but only as a default for the database, not field by field. EagleData only allows editing the text in a tiny dialogue box that only shows Geeza 12 pt, but you can display the result in a more readable layout format, where fonts can be set separately for each field. Neither of the last two recognize Apple's Arabic fonts except Geeza, but do allow the SIL and X fonts. They also follow the "first element priority" system of text blocks.

Three programs were mentioned above as "partially / not really" supporting Arabic: Z-Write is a basic text editor, without much formatting. It does display Arabic, but only in some fonts: Of Apple's fonts, only Geeza Pro is listed, but it does work with SIL's AAT fonts and the X Series (see below). It does not have right alignment of the text in any script, nor any right-to-left direction command, but does order text blocks correctly according to the first character in the paragraph: Adding an Arabic letter at the beginning causes English and Arabic segments to be ordered right to left. Parentheses also work as they should. There are however some serious flaws: In the last "final" version, 1.3.1, choosing Undo will turn all Arabic text into question marks. This does not happen in 1.5beta (from 2004 - development is perhaps halted); but sometimes Undo may turn Arabic text irretrievably into Chinese - clearly Z-Write does some internal script conversion that easily goes wrong. Also, while you can insert characters correctly, you cannot select any text by double-clicking when in RtL dominance. This makes it probably unsuitable for Arabic.
ThinkFree Write has even less support for Arabic, although it does list the fonts. But many character shapes - varying from font to font - do not display, nor can you correctly select Arabic text after it is written. No right-to-left-related commands or functions either.

iWork
Apple's iWork package of three programs, Pages (DTP), Numbers (spreadsheet) and Keynote (presentation) has some partial support for Arabic in version 09, but in different ways. Numbers is actually best, you can edit Arabic text in the formula box, if you do not need different fonts: Only the unnamed default font will combine into words, Geeza and all actual Arabic fonts appear left-to-right, while non-Arabic fonts appear correctly! Editing is otherwise OK. Numerals all appear in Roman, as they do in all spreadsheets (see above). In a "text box" it works like Pages:
- Pages and Keynote have other problems: They accept the regular Arabic fonts, and you can type Arabic text, but you cannot edit the text after you have typed it: You cannot position the cursor (mouse) inside a line, nor double-click on a word; only selecting a full line or paragraph works (you can move the cursor with the arrow keys, but cannot see where the cursor is). There are also no right-to-left commands of any sort, so Pages or Keynotes are still not useful for working with Arabic text. You can write and edit your text in TextEdit and paste into either program to use their DTP or presentation functions - and even do some formatting afterwards, on a paragraph-to-paragraph basis - but the programs themselves are not really Arabic capable. (None of them support OpenType fonts.) In sorting, Numbers and Pages are alike: Arabic text sorts correctly, transliteration also sort correctly except for 'ayn and hamza.