The Arabic Mac|
Programs for the Arabic Mac
Even if you have "activated" Arabic on your Mac (see
the previous page), you may find that not all
the programs you have put on it can actually be used in Arabic. Some programs cannot "see" the Arabic fonts at all: you will not find them listed in the font list,
and if you try to type in Arabic you either get English letters or just boxes and
question marks, in Times or another Roman font. These programs do not
have the resources to "register" the Arabic script or fonts.
It may be surprising that they may display Chinese and Korean,
but Apple provided special adaptations for these scripts, while for
Arabic, Hebrew, and most other non-European scripts, the
application must be able to handle the general
system, and some, particularly older, programs do not do so.
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:
A review of word processors: How well do they do Arabic?
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.
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.
Mellel has most of the same functions as NisusWriter, but lacks some of
the text-handling capabilities of the larger program, e.g. a macro language
(although the old NisusWriter of the Classic period in some ways outshines both).
It also feels less "Mac-like" in some ways, there is no
Fonts menu, and its method of letting all formatting be handled through
styles, while sophisticated, may feel constraining for many Mac users,
at least until you get used to it. However, its "double font" approach may be
quite useful for mixed Arabic-Roman text.
(If your Mac is from 2005 or earlier, Mellel behaves better than Nisus, and on
Macs from 2005-2007 it could use more fonts; today these differences have largely gone away. See below for a more details.)
"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
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).
>> Further detail: a comparative review of Arabic word processors
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.)
Quark also boasts a Middle Eastern edition of its XPress 8, but only for
Windows. As far as I can see from their website, the Mac version of XPress has only partial
support for Unicode, thus not for right-to-left scripts. There are however several
add-ons ("XTensions") that can add Arabic capability to it, the most
widespread is probably Arabic XT. While these often claim to support
import and export to "regular" Mac Arabic, they are in effect
non-standard ways to "trick" the English system to display
right-left text, and use their own fonts that are incompatible with normal Mac Arabic.
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
(Notice that it is copy-protected with a dongle.)
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:
Sunrise, and even old
as well as DevonAgent,
(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:
Page layout / Desktop publishing
- YES: In addition to the larger InDesign ME
programs discussed above, a couple of others also support Arabic:
- Create is a
graphics-cum-DTP/Web program that supports Arabic in the same way as
- A smaller DTP package called
Publisher, this one from the Ukraine, has a similar basic
support for Arabic. Suitable for making fliers and pamphlets, its text
handling is comparable to TextEdit, but with the added DTP functions.
It costs around $35.
- NO LONGER?: Orxtra Publisher, a mid-level
DTP program at $295, clearly intends to support Arabic, it has right-to-left commands for reversing paragraphs; Hindi and Farsi numerals, etc. Earlier versions also worked well. However, in the current version, 1.6.0, Arabic is broken: All glyphs are displayed from left to right (maktab as btkm, but with the "right" shapes). It also used to let you
choose between Arabic and English (and French) menus.
- A package called Arabworx, from
the Arab Emirates, advertises a simple DTP-cum-wordprocessor called Horuf. It did work for me under system 10.3, but not on newer Macs, and the download site (where it is listed at $200) no longer works. The site appears not to be updated since 2004, so it may no longer be supported.
- NO: As mentioned, Quark XPress 8 has only partial support for
Unicode and none for Arabic, except through third-party extensions. As they have an Arabic-capable version for Windows, we will see if a Mac version will appear in the future.
-- The venerable ReadySetGo, the "English" counterpart
of al-Nashir, has appeared in an OS X version (7.6.5), but this does
not support Unicode.
-- Apple's own Pages (09) supports Unicode and does in part display Arabic text, but you cannot really work with Arabic there.
-- Even more so for MLayout (2.11): Unicode (and East Asian)
support, but Arabic characters are inverted.
-- Viva Designer (5.1), also has Unicode support, but not Arabic at all.
-- The same with the opensource program Scribus (1.3.5svn).
-- A special program is Papyrus, a combination of word processor and DTP program. In an early version, it did support
Arabic, although in a weird and limited way, and it still has Arabic-related commands. But the current version (13.10, "2008") no longer works with Arabic text, Arabic letters do not combine.
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,
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",
- 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".
a straightforward text editor partially supports Arabic, but is not
- NO: The programming tool jEdit (4.2) has Unicode,
but not Arabic support.
-- The same is true for BBEdit (9.2) and
-- Mariner Write (3.8, see below) does not support Unicode.
-- The shareware text editor LightWay (4.1.7) does not support Unicode,
-- 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
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
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.
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.
Data (3.8.0), also allows entry and editing of Arabic text in
a simple list view.
(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.
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
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
(c. $90 each) and
So does the image editor (paint) program
(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
has the same Arabic support as its sibling Omni Outliner ($80).
- The drawing modules of
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.
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.
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).
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.*
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,
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
- 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">.
iPhone and iPod Touch
- 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.
- 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
- 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
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
OpenOffice and NeoOffice (per page), and
Mellel (universally for the
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.
Remember the font on the other side
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
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.
Changing fonts in a mixed Arabic-English text
A related issue concerns editing an existing text that contains both Arabic and
English words, for example the English in Helvetica and the Arabic in al-Bayan.
What if you want to change the English to Times, but leave the Arabic in al-Bayan?
In Nisus Classic, you could just select all the text and choose "Times" from the Fonts
menu, only the English changed and the Arabic was unaffected. Alas, no longer possible.
In most cases, any Arabic in the selection will now change to the Arabic default font
Geeza Pro. OpenOffice is worse here, it may present the Arabic in disconnected
letters (NeoOffice does not).
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.
|In 10.3, however, more programs seem to mess it up,
it is hard to get consistent behaviour, but these seems to be some
of the issues there:|
In TextEdit, if a parenthesized Arabic word appears on a line break, both parentheses
may join up, on one line, very confusingly. The parentheses may also
behave as if they were Latin, unlike under 10.4. -- Create
shows some of the same behaviour. -- AbiWord reverses all parentheses under 10.3. -- NisusWriter Express under 10.3 may
appear 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.
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
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.
Making Arabic PDF files
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.
Writing and editing Arabic in Word 2011
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:
Next time you open a new document, Arabic Text will be available as a style and work correctly, even if you have not imported anything into that document.
- 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).
- Open that file in Word 2011. Arabic will appear correctly (although perhaps left-adjusted instead of right).
- 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:
Notice, then, that the Microsoft Office 2011 programs handle Arabic quite differently. In PowerPoint and Excel, you can only use "Apple-compatible fonts not made by Apple", that is the X-fonts and SIL's Scheherazade-AAT and Lateef-AAT fonts (not those without the -AAT suffix); you cannot use OpenType fonts. In Word, if you get Arabic to work at all, you can only use OpenType fonts, and not at all those that Excel and PowerPoint demand.
- 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.
Receiving Windows Word files
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.
Web browser note: Safari under 10.4
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)
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.
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.
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.
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.
Arabic programs for Classic