Programs for the Arabic Mac
And even those that do support Unicode, do not necessarily support Arabic, or support it badly, not taking into consideration the special needs that come with writing from right to left. Happily, the situation is improving, both in terms of the programs and for the Mac itself, the more recent computer and program versions you have, the greater your choice of Arabic-capable programs will be. However, we will on this page look at some of the most important types of software that exists and how they deal with Arabic script:
Notice that this survey is based on software I have got access to, or brief surveys of demos.
Word processing and text editing
This is probably the most important type of software for most of us; and most of us have - voluntarily or otherwise - tended to settle for Microsoft Word as our word processor. So, let us state up front and straight away: no version of Microsoft Word for the Mac fully supports Arabic, and no version before Word 2011 supports any Arabic at all. The latest 2011 version does however have some limited (and unacknowledged) possibility to write and edit Arabic text. The reason they have held back is technical and relates to the relation between the Windows and Mac versions of Word, so it is not clear if they will continue adding Arabic support in the future or not. (Below, you will find some tips on how to use Word 2011 for Arabic.)
Basically, however, Microsoft Word is out, and if we are using Arabic seriously, we must look for alternative programs for our word processing. And preferably some that let us cooperate with colleagues that do use Microsoft products on that other platform. Happily, there are many such alternatives out there.
We can group our choices in three categories: Simple and free program, large and also free packages, or mid-range and not very expensive.
The simplest answer, in many ways, is already on your computer: The TextEdit application provided with your machine does read Arabic, and it does read Microsoft Word's .doc files. If you get a Word file from Windows that supposedly contains Arabic, drop it on the TextEdit icon, and the Arabic will appear OK.
However, TextEdit is a very simple tool, not really a "word processor", there are e.g. no footnotes there, tables or anything. So, we can go beyond this, in two directions: One towards the "mid-range", to products created specifically with Middle Eastern languages in mind, the other to some very large "challengers" to Microsoft that include very powerful word processors, mostly distributed freely, and which include full support for Arabic text handling. Like TextEdit, these all open and save Microsoft Word documents, including Windows Arabic.
Apple's own word processor cum DTP program, Pages, long had lousy or no support for right to left languages. Happily, that is now over, and Pages has OK support for Arabic, except for an issue with footnotes, and you may have to coax it a little to make it appear however, see more below.
Arabic-oriented products: NisusWriter vs. Mellel
In the first group, there are basically two competitors. One has a long history on the Mac, NisusWriter, which dominated the field in earlier years (under the Classic system). Today's program is not an upgrade, but a new program written from scratch. It comes in a smaller Express and a larger Pro variant, the latter is the one that most resembles old NW, but the support for Arabic is basically identical in the Pro and Express versions.
The other is Mellel, from
an Israeli company called RedLex, and is geared directly at Middle Eastern
word processing concerns.
Both NisusWriter and Mellel are commercial, at around $50-90.
"Office packages": Free alternatives to Microsoft
The last category consists of programs that more specifically aim at being "Microsoft Word / Office replacements", with combinations of text processing, database, graphics, spreadsheets or other modules. Generally, they are not created specifically for the Mac, but "ported", that is adapted, from products created under Unix or other systems, under the idea of "open-source" software. This means they are distributed for free, and that they are not the result of one company's work, but a collective effort by enthusiasts. This is ideologically sound, but it also means that these sometimes are slightly less Mac-like than the commercial products. They are also very large, and may tax an older machine, if you have many programs running concurrently. However, the two mentioned below appear quite mature and fast, and thus cost only the time to download and space on your hard disk.
The most "ideological" of these efforts is called OpenOffice, which is seen as a real alternative to Microsoft on many platforms. It appeared in 2009 in a fully Mac-based version (OpenOffice.org version 3), with modules for text, spreadsheet, drawing, presentation, and database. It is thus a fairly hefty program, it takes up almost 400 MB, many times what Microsoft Office uses for its various modules, but it does seem to work fine with Arabic. In this version, it has also become quite "Mac-like", and a normal Mac user should not have much problem with its interface (although you must, e.g., Control-click a style name to edit it, which may not be self-evident to all regular users; and you must "enable Complex Text Layout" in the Preferences to activate some Arabic features, like in Windows). In spite of its size, it opens and works with OK speed on my fairly normal Mac, but performance may vary with each user's set-up (OpenOffice requires Intel Macs, that is, Macs from 2006 or later, which are already quite fast). That possible concern aside, OpenOffice seems to have become a useful application for Arabic on the Mac, not just in word processing, but also in other of its modules like web publishing, graphics and presentation where there are not too many other options for Arabic. A variant of this that looks and apparently behaves quite like OpenOffice.org is LibreOffice.
Another variant of OpenOffice for the Mac is called NeoOffice with word processing, spreadsheet, presentation, drawing and database modules. It also handles Arabic well in all its modules, in some respects better than OpenOffice.org. Its earlier version (2.1) was rather un-Mac-like, but the new version 3 is both faster and with an interface and capabilities quite similar to OpenOffice. It also weighs in at just over 400 MB (but opens fairly quickly on my machine, at least).
Desktop Publishing (DTP) / Page layout
DTP programs are text-intensive, and sometimes used for word processing.
The main competitors here in the "general market" are Quark
XPress and Adobe's InDesign. Neither of these support Arabic
in their standard versions (yet, see below). However, InDesign does have a separate Middle Eastern version,
InDesign CS4 Middle East, which is made and distributed by
the French company WinSoft. It is fairly expensive, from $1,200 up, but is also very advanced and has excellent support for Arabic, at least from the brief look at it that I allowed myself.
It also supports footnotes, unlike the smaller, but less expensive DTP programs checked.
(You can get it from a reseller like FontWorld.)
The main competitor in the Arabic field is a DTP program specifically
geared for the Arabic market,
al-Sahafi. actually a translation of the English program ReadySetGo.
Priced at a bit over half what InDesign asks (from $700, with fonts), it is also
in a different class and looks very dated, minimally updated from the
OS 9 version. Thus, it does not really support Unicode, although Unicode
fonts appear in the menus, you cannot actually use them. It
accepts only its own fonts and the pre-Unicode fonts from OS 9, including
Apple's own, but no other Arabic fonts. There are no specific settings
for right-to-left formatting, it simply reverses the formatting of ReadySetGo.
Which works fine for an Arabic-only text, of course. Nashir has Arabic-language
Apart from layout elements in the integrated programs, a few other, small and medium-sized DTP programs which of course only have a fraction of the versatility of the behemoths, support Arabic to some extent, see the list below.
This is the good news: On a current Mac, you do not have to worry much about it. Most web browsers today display Arabic web pages fine, and without any action on your part: Safari, Firefox, Chrome, Camino, iCab, SeaMonkey, Shiira, Sunrise, and even old Netscape, as well as DevonAgent, Desktop Browser and AOL Desktop. (A couple still have problems with some Arabic web pages, depending on the fonts used, thus Opera has a few problems, but most are OK, while in OmniWeb many pages freeze.)
Some older browsers may have more problems. Microsoft Internet Explorer does not display Arabic at all on the Mac. But this browser has not been supported on the Mac for many years now, so there are probably not so many of it around. Under the older Mac OS 10.4 or older, Safari may have problems in some circumstances, see here how to solve them.
Most email programs, including Apple's Mail work fine with Arabic. See below for a few alternatives, as well as for programs to create web pages.
Other programs: What works and what does not
This is an open slot, where people can report to me what works and not! Below is some of what I have noted in my experience (or been told). If anyone has updates or additions to report, I am happy to include it. Otherwise, these are a selection of relevant programs:
How well is Arabic supported? The detail
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.
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, Pages, 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, Pages, 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.
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 text editors and DTP programs, except InDesign, do not have footnotes.
In those that do, some relevant questions are:
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.)
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.
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; Pages, 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, Pages, 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 Pages or 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?
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:
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:
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.
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.
After languishing behind the compteition for many years, Apple's own programs for word processing, spreadsheets and presentations now all have pretty full Arabic support. They have a right-left button for paragraph orientation to the right of the alignment buttons in the Style panel (on the right in all programs). However, I could not see this initially. This button will only appear if you have an Arabic keyboard activated. You will of course normally have that already if you are an Arabic user, but I use a non-standard Arabic keyboard of my own making, and that did not trigger Pages' right-to-left button. If that is the case for you, go to System Preferences keyboards panel and add one of the standard Apple Arabic keyboards. That will make the button appear, whether you use that standard keyboard or not.
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:
There are some restrictions and peculiarities, however:
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.
Footnote on InDesign
As mentioned, regular InDesign (from Adobe) does not support Arabic or Hebrew script. However, rumour has it that they were close to adding this in version CS4. This version will display Arabic correctly, but as they did not finalize the text editing bit, it is deactivated in shipping versions. However, you can add a free "script", available at the Adobe website which will allow (limited) Arabic text entry in regular, English InDesign. But for serious and extensive work, the Middle East version is still to be recommended.
Although they deal with text, none of the email programs are up to the TextEdit level of text formatting. Even Mail, surprisingly, falls short in font handling. The main issues are:
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.
Under system 10.4 and earlier, there was a bug that could cause Safari some problems: In some cases, you may find that Arabic characters are disconnected in Safari, while they may be fine in Firefox and others. This is, surprisingly, caused by Microsoft Office 2004. If you install that package, it also installs new versions of the fonts Times New Roman and Arial. These have Arabic characters that do not work on the Mac 10.4 (they are "OpenType" Arabic), but Safari tries to display the Arabic pages in them anyway. Throw these two fonts out (or replace them with older, non-Microsoft versions), and Safari will again display Arabic properly. This bug or problem does not affect system 10.5 or higher, which accept Times NR Arabic.
FileMaker Middle East has thus full support for Arabic, except that it does not recognize Apple's Arabic fonts. In the regular, "English" version of Filemaker, you can write unvocalized Arabic text, and you can also paste in vocalized text written in other programs. But you cannot type short vowels or other harakat directly in the program. In this English version, selecting text does also not work quite as it should. That is; when you double-click an Arabic word or drag across a text segment, it is actually selected. But the selection is not highlighted, so you cannot see what you are changing. (All of this, of course, works correctly in the Middle East version, which unfortunately is twice as expensive). Neither version recognizes Apple's Arabic fonts, except Geeza Pro, but do work with the SIL and X fonts; the ME version also with all OpenType fonts, even under OS 10.4.
-- Bento works fine, again with the restriction that you are limited to Geeza Pro, and cannot set the font size freely.
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)
The others types of program mentioned have mostly Arabic support at the same level as TextEdit. The graphics programs all support the same fonts as TextEdit, but e.g. their handling of Latin/Arabic text blocks vary: EazyDraw and Bezier Primer both use the "first element decides" system, i.e. that if the paragraph starts in English it will be organized left-right; if an Arabic word comes first, right-left. BezierPrimer lets you override this in the contextual menu, EazyDraw does not. Intaglio shows the contextual menu, but it has no effect, it is locked to left-right order of text blocks. EazyDraw and Intaglio both allow some manipulation of the Arabic text as graphic (or Bezier) objects that can be stretched, coloured etc. But binding text to a path does not work for Arabic in either program: either the letters break up, or the path goes wild. Open- and NeoOffice also allow manipulation of Arabic type in their Drawing modules, including bending and stretching text (OpenOffice allows a few more options). The pre-formatted gallery forms are mostly unusable (only work in system 10.4, not 10.5, and are stuck to GeezaPro), but you can transform manually typed text in any Arabic font.
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.