Fourth Dimension and Arabic

Now, 4D has come out with a "lite" version called 4D First (4DF), which unlike 4D is not copy-protected, less complicated to use - the ads compare it to Filemaker - but still relational and fairly powerful, and costs about $150. It may thus become a database of choice for Mac Arabists. I have recently acquired 4DF, and have spent the last couple of weeks working on a database application for registration of Arabic manuscripts. Thus, a brief report about 4DF may be in order. (I have never worked with 4D full version, but understand that most of my comments also will be valid for the larger cousin).

First point; yes, 4DF is Arabic compatible. You can enter, edit, search and sort on Arabic data. This is not, however, because it has any particular awareness of the existence of non-Roman scripts, but mainly because 4DF's text handling is so restricted. It mainly uses the operating system's TextEdit routines, which of course are Arabic based in the Arabic system. Thus, 4DF still does have some quirks when you run it in Arabic.

A field is set for Arabic input or display by setting its format to an Arabic font in the layout editor. Unlike in Filemaker Pro, you cannot set the font individually for characters or words inside a field. Thus, once a field is set up for an English font, you cannot have Arabic in it, and when it is set up for Arabic, you can only have English within the limits of the operating system. Happily, the Mac script system includes English A-Z (and some of the European accents) as a part of any non-English script, so that any single-font application or field can still contain both the non-English script (Arabic) and English. The font for this English default is set in the operating system controls, and is thus system-wide.

4DF also falls short of Filemaker in other layout features, e.g. skipping empty lines on a layout when printing. This can be done in 4DF only by concatenating the fields into a text variable, but then that text variable must be set in one particular font and size, so that you cannot have Arabic and English together, beyond the System provisions described above. For many purposes, this is sufficient, but the A-Z range does not include all the characters in my language (like those in my name), and the limitation in size is also hampering (Baghdad, which is really the only proper text font in the standard Arabic package, is exceedingly small for its font size. To get properly sized text, you must preferably print in 16 pt or 18 pt. Any English text in the same field would thus also be in 16 or 18 pt, and would loom over the Arabic.) In our case, we solved all of this by not printing the final result from 4DF, but instead exporting them as text files to be formated in Nisus for final layouts etc. Putting self-made formatting codes into 4DF calculations, for later find/replace with formats in Nisus, works fine.

Another layout quirk that may be noticed, concerns text alignment. Arabic fields is normally aligned to the right margin, and the tabbing order set to run from right to left on a line. However, whenever you put a cursor in a field to type something, the contents of the field and the cursor jumps to what 4DF thinks is a "normal" adjustment, which depends on the System default for "text direction". In a English -based system, this is of course left to right, so the cursor jumps to the left edge of the field. You should set the System text direction to right -> left, at least during data entry. This is done in the Control Panel "Text".

On the other hand, it does of course provide greater database functionality than Filemaker, being a proper relational database. Arabic can be used in any fields - a number field will require Roman numerals, but by setting the system default to Shakl al-'arabi li'l-arqam and the field to an Arabic font, they will still display in Arabic. Finding seems to work fine, except of course that a text with short vowels is different from a text without short vowels, searching for one will not find the other.

Sorting and script dominance

When you install an Arabic system on a Mac, you can do it on three different levels:

Thus you end up with three options that all allow you to type in Arabic, but makes thecomputer behave differently: Arabic dominant, Arabic localized / Arabic dominant, English localized / English dominant, English localized. The important element here is which script is the dominant one, as this governs the way the computer works. Localization is mainly a cosmetic matter, whether it is says "File" or "Malaff" on the Finder menu. You govern which script is dominant by the Apple control panel Script Switcher [part of Apple's Arabic Language Kit], or a program such as Nisus Script Exchange.

All this relates to 4DF, because it has no real awareness of a multiplicity of scripts. It blindly uses the sorting order of the dominant script, Arabic if that is it, or the European language your machine is set for in Roman. In the latter case, it will look at the character values, not the font of each field. Some Arabic characters, like m, n and h have the same character values as Roman A, I and U with accent aigu or accent grave, thus 4DF will sort them as A, I and U (ahead of all Arabic).

I am basing this on the International version of 4DF, the only one I have. I do not know whether the US one will sort straight on the basis of character values, which will work fine for Arabic (as long as you do have any short vowel markers or other symbols in the text); or whether it simply ignores them (as Filemaker does).

One thing to note: when you design your database, you must run under English default. The text editor of the design environment gets terribly confused with the right-left shift of text blocks under Arabic default, and tends to delete everything. Permanently.

4D First and performance

I can evidently not compare 4D First to 4D the full version, but the power of 4DF was more than enough for me, a notorious non-programmer.

It is not terribly demanding in memory or disk space, taking about one and half MB of each. However, it does suffer from lack of speed. I originally worked on a PowerBook 140 and an SE/30, both small to medium-range Macs in today's world, and on both the program straight from the box was terribly slow, in particular on screen updates. Clicking on a tool produces no effect, one must hold down the button for a second or two before it is registered. Similarly "scrolling" which is more like "jumping"; and on moving from one screen to another, bits of the new screen will be interposed with the old for a couple of second before the new screen shows up properly.

Updating typing doesn't appear quite as bad, but I type Arabic so slowly that I would not really notice. Nor have I put in so much data that I can say anything about the speed of sorting and finding, yet. This will in any case be affected by the efficiency of the procedures I write, unlike the screen display I noticed. I do not know if this is endemic to 4D, or whether it comes from 4DF being version 1.0, perhaps not yet optmized for speed on smaller Macs. The slowness of the screen display is so marked, however, that even if it does not affect the functionality of the database I would still recommend using a fast computer for any extended work with 4DF. "Fast" meaning at least a 68040 computer. When I changed to an LC475 (the slowest 040 on the market), the speed was acceptable.

Thus, on the whole my conclusion is that 4D First is not my database of choice; for general work I would much rather work with FileMaker. However, taking into account the quirks and slowness I have mentioned, 4DF still is useable for handling of data in Arabic script, and will probably become the database of choice for such tasks, just as Nisus is becoming the word processor of choice.

Knut S. Vikør, November 1994
Archived 14.4.95.