our approach started by testing Arabic behavior using the provided testing platforms by Posiflex. Multiple issues were recognized; among many; below are just a few samples:
- Font; even though an Arabic font was already burned on the device, characters were not representing the complete alphabet/shapes.
- Unlike English characters, the same Arabic letter has different shapes that of course could not be generated/printed because the English driver was not capable to handle such criteria.
Example, the following tow shapes are for the same letter: ـب ب
- Code Page; different applications not necessarily use the same Arabic code page. For example, some legacy applications might use different code page(s) than the Windows Applications.
- Different POS model has multiple drivers and thus different behaviors while Arabic handling.
a Report was shared with the development/support team in Taiwan for different scenarioswith Pros and Cons trying to address the diversified challenges and how can we enable the Arabic POS devices. The selection was between:
We decided to develop a solution with which changes are either made ones or centralized (in one place) without modifying each driver for each model.
The solution was simply to develop Arabic libraries with APIs (Application Programming Interface) to enable different applications to use Posiflex device drivers without replacing/changing the device drivers. These libraries were capable to handle:
- Different code pages (Unicode, CP 864 …etc.)
- Arabic display characteristics; e.g., Automatic Character shaping, wrapping, Reading Order and alignment.
- Bilingual printing (Arabic / English text and receipts).
Multi-platforms, different versions for Java.Net and Windows 32 were delivered.