Arabic on MS Handhelds

WAL - Windows Mobile Arabization

WAL User Key licences can be generated in the WAL Serial application. Over 7000 licences generated.

Mobile business applications for Pocket PC handheld devices for retail, van sales, data capture industries... are in high demand because of their flexibility and the increased productivity that they bring to companies.

In the Middle East market, the Arabic language support is once again mandatory. Hence, building Arabic VB, VC++, ASP, ASP .NET, VB .NET and C# .NET applications, running on a Pocket PC or on WindowsCE is a challenging task due to the many problems related to the Arabic language specifications that developers have to cope with.

To avoid these problems, Mughamrat has developed WAL (WinCE Arabic Layer), which is a Software Development Kit for arabizing applications for PocketPC PDAs.

WAL helps developers to build and integrate fast and operational mobile arabized native (build with EVB or EVC++) applications as well as web applications (built with ASP language or ASP .NET language).

Software Arabization Services

International analysis group IDC estimates that Middle East and North Africa (MENA) IT market is set to grow from $6.9 bln in 2003 to around $13.4 bln by 2008. The MENA region is currently the third fastest growing IT area in the world after India and China. Accordingly, IT companies of all sizes are setting the focus to develop their business in Arab countries.

Yet, most organizations in the Middle East, as clients, stress on the fact that incoming new IT products and related software should be supporting the local language of the region. Thus, Arabic language localization has become a sine-qua-non condition to penetrate the Arabic IT Market.

As experts in Arabic Technologies since 1998, Mughamrat has a rich offering in Arabization services.

Developing Mobile Applications for the Arabic Market

1 Introduction

Goods Distribution, Route Accounting, Stock Warehouses Management, Data Collecting, Maintenance Control, Fleet Management, and other similar on-the-field activities are operations that are always costly in money and in time, due to the organization, centralization and reporting efforts involved in managing distributed agents and processes.

With the introduction of new powerful, transportable, battery-efficient, communicating and user-friendly computing devices, opportunities to reduce costs and delay involved in on-the-field operations by intensive usage of information technologies, started to popup everywhere.

In the Middle East region, where the oil-fuelled rapid growth has initiated numerous and recent large scale projects (oil plants, sea water desalination plants, large scale distribution and collecting, port operation, e-government initiative, military equipping, ...), new mobile computing technologies appeared to fit perfectly.

Furthermore, in this region, final users of on-the-field applications are more often middle or low qualified agents (trucks driver, warehouse controller, supermarket agent, customs and frontiers officer, military, ..), and are not generally educated in foreign languages. Therefore they can only work in their native language, thus the need for mobile computing with user interface in Arabic language.

This article will go into the details of mobile computing and of the vertical applications market, then will go through the specificities of Arabic language and how it is supported on mobile devices. We will then conclude how Arabic in mobile projects has to work beyond the simple device and has to insure compatibility with back-end hosts and peripherals.

2 Mobile Vertical Applications Market

Since the first portable computers like the Osborne-1 in 1981, weighing 23.5 pounds (12 kg), and the first graphical handheld, the Apple Newton, a long path has been covered in mobility. While we can apply “mobile computing” label to today laptops and PDAs, the general-purpose work (such as document writing, notes taking, contacts gathering, agenda, ...) done on these devices doesn't fit the current meaning of the term which is more about on-the-field activity in a relation with a specific type of business or industry.

Mobile vertical applications handle the business logic and requirements associated with a specific industry, such as plants operating, route accounting for a distribution business, inventory management, meter data collecting in a water & electricity company, maintenance control, ...

Mobile vertical applications run on handheld computers on the field then are used by a number of agents. The mass of data collected by the agents on the field is periodically centralized to a host server, for reporting or analysis needs. Handheld computers are also often ruggedized to stand to the eventually tough environment constraints: working in dusty environment, should stand a drop on the ground, heat, ...

Historically, first mobile vertical applications were in the eighties and were running on DOS-based power-limited machines. With the flexibility brought by the GUI-based applications running on new powerful devices (PalmOS, WindowsCE, Symbian, ...), added to the large reduction of cost induced by replacing slow manual processes by IT communicating processes, every industry happened to have its specific mobile application, and the market of mobile computing grew in a big way.

Examples of mobile applications are as follow:

Route Accounting

Route accounting mobile applications are for businesses such as distribution of goods to shops, or collecting milk from farmers. The software permits to program the best route to go through all the stop points with minimum time and distance.

It also permits keeping track of the quantities shipped or collected directly on the device and have them centralized at the end of the tour to a main server for statistics.

The shopper or the farmer can even get at the end a receipt dynamically printed from the inputted data if the agent carries with him a mobile printer.

Data Collecting

Data collecting mobile applications are very useful for utility companies such a Water & Electricity providers. The agents on the field can do meter reading with the device and centralize the information back to the central servers.

Another application is for polling companies, in conducting a survey, where a team of agents can asks people on the street a set of prepared questions using mobile software to guide them. The collected data is automatically validated during the input of the answers and is centralized back in the office when the agents are back to the office.

Maintenance

Maintenance mobile applications are very used in delivery business when the agent that ships the goods can make the receiver sign directly on the device. The sender can be then updated by the confirmation of the delivery.

These applications are also practical for reparation document and checklist document in plan maintenance for example.

E-Government

Police for example can have mobile devices with mobile applications for parking fines collecting or road infraction fines. A police agent with his device can be on a patrol tour. If a car is in infraction, he can do plate reading on the device then fill in the description and fee of the infraction. Within days, the information is processed and the faulty car driver receives by mail the fine to pay.

3 Support of Arabic on Mobile Devices

Analyses estimate that the Middle East and North Africa IT market is set to grow to around $13.4 billions by 2008. The MENA region is currently the third fastest growing IT region in the world after India and China, and the mobility is supposed to have a non-negligible share.

Mobile software and hardware companies are actively targeting this market. However, the common thought in having a mobile solution (usually originally in English) to support Arabic is a straightforward operation of translation since Arabic support is common on desktop computers based on Windows. But in most mobile platforms, Arabic is not supported by default. Therefore the Arabic issue arises generally in advanced stages of mobile projects and projects managers have to rewrite plans and secure extra budgets in last minutes.

The following section explains why the Arabic language needs extra technical processing, and how it can be handled on mobile platforms.

3.1 Arabic Characteristics

In comparison to a Latin-based language, Arabic needs extra processing because of  characteristics such as :

• Glyph Shaping: Within Arabic words, letters change their shape depending on their position. Each Arabic letter can have 4 shapes (isolated form, initial form, medial form and final form). However some Arabic letters such as “Dal” or “Zayn” can have only 2 shapes.
• Right-to-Left Alignment: In Arabic, text is inputted and written from right to left, while in English, text is inputted and written from left to right.

Since the computer industry has started in English, all low level assumptions for string and drawing text have been made for left-to-right isolated languages.

Solution to support Arabic in computing was to add some processing algorithms to the standard text processing to address the specificities: For internal processing, Arabic is handled as any other language, i.e.: in an isolated shape and in left-to-right alignment, this form is called logical form; then when the Arabic text is about to be displayed, it goes under Arabic specific algorithms that convert it to a text ready to be displayed to the screen, this form is called visual form.

For example, the word “hello” (“Salam”) is stored in its logical form (from left to right : “Seen” -> “Alef” -> “Lam” -> “Alef” -> “Meem”), and is displayed in its visual form (from left to right : “Isolated Seen” -> “Final Alef” -> “Medial Lam” -> “Initial Seen”).

Other minor specificities are involved (encoding, bidirectionality, ...) and need their own processing. If there is not specific support, trying to work with Arabic will show only garbage.

In mobile platforms, manufacturers simply overlook this issue and do not implement any particular Arabic support. For example, even for the support of Arabic on Windows desktop, it has been implemented years after the first English release. Recently because the market is starting to grow thanks to some dynamic markets (Dubai & Saudi Arabia), Microsoft started to make available some support of Arabic language in its latest release of Windows CE.

In mobile platforms, Arabic can be supported by 2 ways:

• by a third party through a system-patch
• by a third party through a SDK

 3.2 System Patch

System patch codes the needed Arabic algorithms into the system installed upon. It is supposedly eases the integration for the consumer. The purpose is to add Arabic support but wrap it in a way that is transparent for the user who is supposed to have the impression that the Arabic is built-in with the device.

Therefore any Arabic data he will manipulate, it will be displayed correctly because the system will take care of all the processing.

However, by principle, system patches bring many flaws and instabilities to the device:

• A system patch implies to identify the system libraries that take charge of the text display, and inject into them Arabic processing. However, the information about the underlying system is usually confidential to the device manufacturer of to the operating system provider. So the developer of a system patch has to work by trials and errors to guess where to inject the arabisation code. Thus the risk of errors, and of unwanted modifications.
• System libraries are used everywhere in the device, even in places where Arabic is not needed. So any extra code added by a system patch will be executed everywhere even if not needed. This can increase considerably the risk of error propagation, and of instability, and causes a general slowdown.

 3.3 SDK (Software Development Kit)

An arabisation SDK is a development kit that is provided to mobile application developers who can use it to arabise their own applications, while having a control over the process.

An arabisation SDK usually contains graphical controls and libraries that have been redeveloped with Arabic support integrated. Basically, the developer just replaces the original English graphical controls of its in-development application, with the equivalent Arabic graphical controls. He then has to do a work of integration, by paying attention to the printing process, to the host communication, and to the compatibility with the database as explained in the next section.

The advantage is that the arabisation is applied only at the level of the developer's application, not elsewhere in the system. Thus the developer has more control over mobile application and over the process of arabisation.

 4 Arabic Integration in Mobile Projects

Having Arabic language working on the devices is just part of the solution. Mobile solutions need also to synchronize data with a central host for validation, analysis and reporting, and also need to communicate with the paper world via mobile printers.

Support and compatibility of Arabic on printers have to be insured. Synchronization in Arabic with back-end server, compatibility of mappings between host database and mobile database has to be guaranteed.

The following sections will cover the details of Arabic support on mobile printers and the details of database connectivity in Arabic.

 4.1 Arabic Support in Printers

While in desktop PC, printers drivers provided by printers manufacturers hide the technical details of printing (user just selects on “Print”), in mobile computing and printing, there is no such drivers.

Mobile printers only provide support of low-level printing languages such as ESC/P or PCL, along with a limited set of resident fonts. That means that for the user to print from mobile devices, he has to manipulate such languages either manually or through a library.

Main reasons of this lack of high-level drivers are first because of the fact that devices have usually not enough capacity, and second because of the multiplicity of the platforms (Symbian, PalmOS, Windows CE, Linux, ...), mobile printers manufacturers are reluctant to provide a driver for each mobile platform.

So, the printing work is done only using the PCL or ESC/P languages (or a close proprietary variant) using the set of resident fonts which are for Latin only usually. You can find for some platforms, tools and libraries that serve as simplification middle layer.

For printing Arabic text, either the printer does contain a Arabic font built-in, it can then be chosen and enabled (using PCL or ESC/P commands); or the printer does not contains Arabic font, Arabic font has then to be developed and downloaded to the printer (again using PCL or ESC/P commands).

Another issue to deal with while printing in Arabic is the encoding type to use. If the device is enabled to work in Arabic either with a system patch or with a SDK, the encoding used is usually the classical 1-byte CP1256 or the 2-bytes Unicode. But on the printer side, because of even more memory restriction, encodings used are even smaller such as the IBM code page Arabic-864 that contains only 2 variations per Arabic letter instead of the standard 4 variations (isolated, initial final, medial, ...). Designers of this mapping considered that 2 variations are enough to produce a readable Arabic output. In this case, the printing process should take care of the conversion from the device mapping (CP1256 or Unicode) to the printer mapping (IBM-864).

 4.2 Synchronisation with Hosts

Arabic Mobile projects also involve synchronization between the devices and the host. Each platform brings its own protocol (ActiveSync for WindowsCE, HotSync for PalmOS, ...),

For support of Arabic between hosts and devices, special care should brought to Arabic encoding compatibility between the 2 machines by making sure either the Arabic encoding is the same in both sides, or to provide a conversion layer that does the matching job.

 4.3 Arabic support in databases

The database is also a sensitive issue, since mobile projects usually deal a lot with databases. We have first to be sure the database does support Arabic (or a least has the option to be enabled) Such databases are Access, Oracle, SQL 2000/CE, ...

Then we have to pay attention to the encodings used for Arabic between the device and server to be sure they are compatible or at least are properly converted during transfer or before display.

For example, a database in the host made with Microsoft Access and filled with Arabic CP1256 encoded data will be showed as garbage in a device supporting only Unicode Arabic.

5 Conclusion

This is how Arabic language is integrated to the field of mobile computing both at the mobile terminal level, and at the project level of communicating with peripherals and hosts. Our experience in this arena has reveal that the process of adding Arabic to a mobile project should be considered itself as a massive project, for which, resources, budget, choice of tools and training should be planned at early stages. Not to mention the necessity of being supported by an arabisation expert and partner that can provide strong technical support. For example, products (devices, printers, ...) sold by major IT companies can be marked as Arabic enabled, but in reality Arabic being relatively a niche market still, there is usually no dedicated department team, and therefore it is hard to obtain help to effectively have the Arabic working on these products. In Mughamrat we more than often ended up doing for our clients technical support and investigation on software and hardware provided by others.