Programs for Arabic in OS X

• YES: Jedit X (not to be confused with jEdit, below) supports Arabic in the same way as TextEdit ($28).
• Omni Outliner supports Arabic in the same way ($40).
• A more specialized text editor for "creative writers", Ulysses, also has the "TextEdit type" of Arabic support. ($100).
• The notepad replacement X Pad supports Arabic text as TextEdit; also, setting text to "Right-to-left" also right-adjusts it ($10).
• NOT REALLY: 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 (8.2.4) and TextMate (1.5.3). -- Mariner Write (see below) does not support Unicode. -- Nor does TexEdit Plus in its OS X version (4.9.6), in spite of its claims to the contrary. -- 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 bibliography organizer EndNote (9) allows you to enter, edit and sort Arabic items.
• MORE OR LESS: A few smaller databases or rather list managers also have basic and fairly similar support for Arabic:
  iList Data (3.2.0), allows entry and editing of Arabic text (with vowels) but only in a small-size default font (and no double-click).
  EagleData handles Arabic much the same way, but allows you to display (but not edit) in a slightly more readable size.
  iData (2.1) has a the most text-friendly interface of the three, but the functionality is much the same.
  None of these three sort vocalized text correctly (see below). EagleData is freeware, the other two around $70.
• WELL, NOT PROPERLY: FileMaker (8) does allow you to enter and display Arabic text, up to a point, and it sorts whatever is there correctly. But it is so limited in editing that it cannot really be said to support Arabic: you cannot type harakat, you can hardly select and edit text once entered, and it does not support Apple's fonts.
• NO: Panorama (5.0) does not support Unicode.

• PARTIALLY: Excel (2004) will display Arabic, although Apple's Arabic fonts will not appear in its font list, you can e.g. use the X or SIL fonts (see below). Editing is however limited.
• PRESUMABLY: The "Arabworx" package mentioned above also contains a simple spreadsheet, "Arqam" (not tested).
• 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. -- Apple's Numbers (08) behaves like its sibling "Pages" above, it allows some Arabic text entry, but it is unstable and you cannot edit any entered text.

• NOT REALLY: I have actually been able to type some letters in Arabic in PowerPoint '04, but they tend to break up on editing, so basically: no real Arabic support. -- Apple's Keynote (part of iWork 08) allows some typing and display, but not editing of 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 paint program SeaShore (free).
• The flowchart program OmniGraffle has the same Arabic support as its sibling Omni Outliner ($80).
• NO: The draw program Compositor (2.9) and paint program TuxPaint (0.9.15) do not support Unicode. Expression (a paint program, 3.3b) does Unicode, but not Arabic in Tiger.

• YES: RapidWeaver is a simple web editor ($40) in which you can write Arabic text as in a text editor. It does not allow you to manipulate the html code (unless you have chosen "HTML Code" as page type), and it does not convert Arabic to html code points, but most browsers that support Arabic will probably display the text properly.
• KIND OF: Another small web editor, GoodPage ($99), does not actually support Arabic editing. But Arabic text copied into it from e.g. TextEdit will be coded as html entities, so that it will appear properly in a browser.
• The freeware TacoEdit is an html editor (i.e. you edit the code directly) which allows you to write and edit Arabic text. It does not convert the Arabic to html code or insert the relevant headers for direct display, so you must know how to add these manually.
• PERHAPS? Dreamweaver does not support Unicode or Arabic in its version 6, but there are reports that it does support Unicode in more recent versions.

• YES: NeoOffice discussed above is an integrated program (wp, spreadsheet, presentation, drawing). So is Papyrus (wp, database), which as discussed does not really support Arabic well.
• NO: AppleWorks does not support Unicode, and thus no Arabic (it is partially replaced by the "iWork" package containing Keynote, Numbers and Pages, which may display Arabic but does not really allow editing Arabic text, see separately). -- The latest version of RagTime, vs. 6 (currently in beta form) supports Unicode, but not Arabic. The current full version (5.6.4), does not support Unicode. -- Nor does the Mariner package (Mariner Write 3.7.1). -- ThinkFree Office (2.3) has Unicode, but Arabic does not work.

• 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 direction Arabic/English.
• A trial version of an Arabic spelling checker has recently been released. It works under the CocoAspell engine, you must install both. Then many programs, such as TextEdit and Mellel (but not NisusWriter) may use this Arabic dictionary for spelling checking (comprehensiveness to be confirmed).

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 gives 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 may use an external Arabic 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.
• A special problem that has cropped up is with parenthesis, which should operate logically.

This is a short list. Let us see how of the word processing programs mentioned measure up (under 10.3.9 and 10.4.3):

Right-to-left paragraphs

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. However, this does not allow you to use a "justified" paragraph format, where both left and right margins are straight. The program will then align the last line of the paragraph to the left, not to the right as we want. Furthermore, in such fake right-aligned paragraphs, tabs and first-line indentation will also be from the left, as if the text was in English. And, if you have a mixture of English and Arabic text on a line, the first Arabic words will confusingly appear to the left of the English words, and the last part of the line to the right: the program arranges the "blocks of text" from the two scripts from left to right.

Instead, the program must therefore have a function to mirror all commands for the paragraph to the right, so that last line, first-line indent and tabs all run from the right, as well as organizing text blocks correctly.
Mellel, NisusWriter, AbiWord*, Horuf, NeoOffice, Papyrus, InDesign ME, Nashir, Orxtra, Create as well as Jedit, Swift Publisher, Ulysses, and TextEdit all have some form of right-to-left reversal, although it does not work as expected in all of them.
(* As mentioned above, AbiWord cannot handle Arabic display yet, but still has commands for right-to-left, which may become effective when the display errors have been corrected.)

The problems are greater in OS X 10.3 than in 10.4. As mentioned above, 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. 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.

In 10.4, the situation for these is quite different: In Nisus it all now works as it should, justified text, tabs and first-line indentation all run properly from the right. -- In TextEdit and those that follow it (SwiftPublisher, etc.), the situation has also improved: choosing right-to-left in the contextual menu will now also make the last line of a justified paragraph be properly right-aligned. The tab and indent settings on the ruler in these programs appear to go from the left, but the tabs will actually run correctly from the right. A bit disconcerting, but it works.

Some problems remain in both system versions: In Papyrus, the "RTL" (right-to-left) command works only on the paragraph level, and as mentioned governs text direction as well, uniquely. This means that you cannot mix English and Arabic text in a paragraph, except by "typing backwards". -- In Horuf, tabs do not work in either script, but justification and indentations are fine. However, Horuf seems, in my brief testing, to be rather more unstable in 10.4 than 10.3: choosing a menu would now freeze the program. This is to be confirmed, but caution is adviced. -- 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.

Proper right-to-left paragraphs including tabs and indents appear to work as they should in both system versions in Mellel, InDesign ME, Orxtra, AbiWord and NeoOffice.

Nisus, Mellel, InDesign, Orxtra and AbiWord have an additional function for right-to-left dominance of the entire document, not just each paragraph (NeoOffice for each page): this will also reverse left-right headers, margins, gutters and/or other document settings.

Footnotes

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, NeoOffice, InDesign and Papyrus.
Can footnote numbers be in Arabic? Yes in Nisus and Mellel, in both cases as a style setting (not individually as in Nisus Classic), and in NeoOffice (as universal default), No in AbiWord and Papyrus. In InDesign numbers seems to be only in Arabic. But it does have both Roman i-ii-iii and abjad numbering. (Neo-Office 1.2 also has abjad numbering.)
Can the footnote separator line run from the right? Yes in Nisus, Mellel (universally for the document) and NeoOffice (per page), No in AbiWord, in Papyrus you can "fake" it. InDesign again only from the right, but you can set the offset.

Typography

As for what fonts you can use, see below: Mellel, AbiWord, InDesign, Orxtra and Horuf are able to use some "OpenType" fonts that the others cannot. However, this comes at a price: Some fonts have included special typographical features beyond the basic display. If you write lam-mim-jim in al-Bayan, for example, the two first letters will be "stacked" vertically. These features do not work in the OpenType programs, but in all the others.

A small feature of this works, among my fonts, only in al-Bayan: Type "Allah" straight without harakat (alif-lam-lam-ha) and the system will replace it with the "llah" ligature, with shadda and dagger alif. Works in all tested programs except the OpenType ones: TextEdit, Nisus, Swift, NeoOffice and Papyrus. But only in Bayan, not in the other fonts that have the samme "[A]llah" ligature such as Kamran. Notice you must type the alif, "Allah", although only "llah" appears.
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.

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 (Swift Publisher, Jedit, Ulysses, now also Nisus) allow access to this menu. Orxtra does not give access to these tools, but allows you to switch from Roman to Arabic to Persian shapes of the numerals through a separate menu.

Remember the font on the other side

When you switch between English and Arabic 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 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. Nisus Classic did it, but no program does it now, at least automatically. There are three types of behaviour:

(1) When you switch script, it always goes to the deault fonts of either script: LucidaGrande for English, Geeza Pro for Arabic. You must set the font each time manually: TextEdit, Horuf, Swift Publisher, Create, Jedit and Ulysses do this under 10.3.

(2) When you have selected an Arabic font, like Baghdad, it stays with it until you manually select another. The other script will appear in the default LucidaGrande, but when you switch back, you will still be in the Arabic font you selected, if you did not visit the Font menu in the meantime: thus Nisus, AbiWord, Nashir, InDesign, Orxtra, and Papyrus [in Papyrus, it does not switch to the default font of the other script in the first place, but you cannot mix English and Arabic anyway, as we have seen]. TextEdit and its sisters also work this way in 10.4.

(3) Mellel and NeoOffice allow you to set a combination as "primary" and "secondary" font, one for each script (in different sizes, better than Nisus Classic). Once that is done, you will switch to these fonts when you Command-click to the other script. Nisus has a similar option, accessed through its style menu, it can provide the same function.

Parentheses

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. Often this causes the Arabic parentheses to function as if they were English characters.

How to these programs tackle this? In 10.3, they mostly mess it up, so it is hard to get consistent behaviour, but these seems to be some of the issues:
In TextEdit, Shift-0 gives a left (English-opening) parenthesis, even in an Arabic font. When you start typing the text inside it, its appearance changes to a right parenthesis. When you close it, the opposite happens. However, if the word appears on a line break, both parentheses may join up, on one line, very confusingly. The parenthesis sometimes behaves as if it was a block of "English" text, even if it is all in Arabic text, at other times, they may appear OK. -- Create shows some of the same. The others that do not have actual right-to-left paragraphs, Swift Publisher and Ulysses seem however to work as they should. -- Nashir has only right-left paragraphs, and thus also works fine -- Jedit, Orxtra and NeoOffice mostly work fine, but sometimes parenthesis appear reversed under left dominance (particularly starting a paragraph, it seems).

Among those that set right-dominant paragraphs, Mellel and InDesign seem to work fine -- NisusWriter Express also appears to be OK, until you add an English word to the document. Then you may suddenly see parantheses, even in other paragraphs, change appearance, left becomes right and vice versa, or they just flicker left and right. -- AbiWord reverses the parenthesis, both when the paragraph is left and right dominant. You may "fake" the correct behaviour by typing the Shift-9 before and Shift-0 after, rather than the opposite. -- 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 can fake it like in AbiWord. -- In Papyrus, putting a word in parenthesis will cause the Arabic letters of the word to run from left to right.

In my brief testing under 10.4, I was not able to produce the problems mentioned in either TextEdit or Nisus; so it may be that the problem has been solved for these programs.
However, these parenthesis problems appear intermittently, so it may be for all those I have "cleared" above that I have simply not stumbled onto the problem in these programs.

Sorting

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, some programs treat harakat (short vowels) as if they were separate characters, which we do not want in Arabic: Ahmad should appear in the same place in the list whether it is written with vowels or not.

NeoOffice does it almost correctly, the shadda is sorted as a letter after ya, but the other harakat are ignored. -- NisusWriter does not sort correctly, short vowels are sorted after ya. -- The same is true for Jedit X. -- Mellel and AbiWord do not have sorting capabilities.

Interestingly, BBEdit, although it cannot display Arabic properly, does sort correctly - 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 Arabic items almost correctly; as in NeoOffice, the shadda is placed after ya. The same is even true with Word, it sorts almost correctly, although you cannot see the result!

Of the database programs, FileMaker sorts Arabic correctly ignoring short vowels (perhaps linked to the fact that you cannot type them). -- EndNote also sorts correctly, ignoring all harakat. -- The three list managers iList, iData and EagleData all sort short vowels as separate characters, all after ya, so that Ahmad with vowel over the initial alif is sorted between unvocalized Ayman and Badr. (Papyrus's integrated database does not allow right-left text entry. Both it and the text module sort harakat separately.)

Text handling in other programs

Databases
While EndNote shows - and respects - the contextual Writing Direction menu, FileMaker is locked to left-right ordering of text blocks in a field. FileMaker's biggest problem that it does not select Arabic correctly, the selection "runs from left" of the line when the text runs from right, so that double-clicking the left-most word selects the right-most on the line. It allows pasting of vocalized text, but you cannot type short vowels directly in the program. It does not recognize Apple's Arabic fonts, except Geeza Pro, but it will work with the SIL and X fonts.

Of the three list managers, iData allows most manipulation of the text, and supports the Writing Direction menu. The other two do not, and follow the "first element priority" system. EagleData and iList allow you to set fonts for display (iList also for editing, but only overall, not field by field). Like FileMaker, these three do not recognize Apple's Arabic fonts except the system font Geeza Pro, but do use X and SIL fonts.

-.-

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 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.
Apple's own Pages program (a part of the "iWork" package) is actually better: You can type Arabic text there, and it appears correctly. But you cannot position the mouse inside the Arabic nor select anything smaller than a paragraph (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 is clearly not intended to work with Arabic, nor can you really use it for this purpose.