Adding Arabic language support to an embedded GUI is significantly more complex than adding European language support. Where European languages require only a font with the correct Unicode glyphs, Arabic requires three additional layers of processing: contextual shaping (the same Arabic letter has four different forms depending on its position in a word), right-to-left text direction (the display engine must render glyphs from right to left), and bidirectional text (BiDi) (Arabic text mixed with English numbers or labels must correctly interleave RTL and LTR segments). Each layer adds complexity and ROM cost. This guide explains the trade-offs and the practical implementation approaches for embedded systems.
Layer 1: Arabic Script and Contextual Shaping
Arabic is a cursive script — letters connect to neighbouring letters and change shape based on their position in a word (isolated, initial, medial, final). The Unicode standard encodes each Arabic letter in its base abstract form (U+0600–U+06FF), separate from its contextual presentation forms. Rendering software is responsible for selecting the correct presentation form for each letter based on context.
For example, the letter Ain (ع) has four forms:
- Isolated: ع (U+0639)
- Final: ـع (connects to the right)
- Initial: عـ (connects to the left)
- Medial: ـعـ (connects both sides)
In full Unicode rendering (used in desktop applications), a text shaping engine performs this contextual substitution at runtime. On a constrained MCU, a full runtime shaping engine adds 50–200 KB of ROM — unacceptable for many embedded targets.
Layer 2: Right-to-Left Text Direction
Arabic text is written right-to-left: the first character of a string is drawn at the rightmost position, and subsequent characters are placed to the left. This requires the text rendering loop to run in the opposite direction compared to LTR text. Additionally, text alignment changes meaning: "left-aligned" in RTL is visually right-aligned (text aligns to the right edge of its bounding box). Layout containers (labels, text areas) must support RTL layout direction to correctly position text within their bounds.
Layer 3: Bidirectional Text (BiDi)
Real-world Arabic content frequently mixes Arabic (RTL) and Latin characters or numbers (LTR). For example: "سرعة 120 km/h" — the Arabic word "سرعة" (speed) reads right-to-left, but the number and unit "120 km/h" read left-to-right within the same string. The Unicode BiDi algorithm determines the correct visual ordering and direction for each run of characters within a mixed string. A full BiDi implementation (Unicode Standard Annex #9) requires approximately 3,000–10,000 lines of C and 30–50 KB of ROM — suitable for MPUs running Linux but challenging on MCU targets.
Implementation Strategies for Embedded Systems
Given the ROM cost constraints, embedded Arabic implementations use one of three strategies depending on the target platform and application requirements:
Strategy A: Design-Time Shaping (Recommended for MCU targets)
Arabic text is shaped at design time in the GUI design tool (Flint UI Designer) rather than at runtime on the device. The designer enters Arabic text in its abstract Unicode form; Flint performs Arabic contextual shaping at design time and exports the resulting presentation-form glyphs, eliminating the need for runtime shaping on MCU targets.
ROM cost: Near-zero — only the required Arabic presentation-form glyphs need to be included in the font. No runtime Arabic shaping engine is required.
Limitation: Only works for static Arabic text (UI labels, menu items, button text entered at design time). Does not work for dynamic Arabic text entered at runtime (user input, text received from a network, variable string substitution).
Suitable for: Most HMI applications where Arabic is used for UI labels and static menus — which is the majority of industrial, automotive, and consumer embedded GUI applications.
Strategy B: Runtime Lightweight Shaping (~1.4 KB ROM)
A compact runtime Arabic shaping module (~300 lines of C) maps abstract Arabic code points to their presentation forms based on adjacent character context. This covers standard Arabic shaping for the basic Arabic block (U+0600–U+06FF) without full OpenType feature support (no ligature substitution beyond mandatory ligatures, no complex diacritical mark positioning). ROM cost approximately 1.4 KB for the shaping table.
Suitable for: Applications displaying simple dynamic Arabic text (temperature sensor names, product labels fetched from a database) on mid-range MCUs where 1.4 KB is affordable.
Limitation: Does not handle all Arabic script variants (Persian, Urdu extended characters), complex ligatures, or diacritical marks (tashkeel) precisely. Full Arabic typography quality requires Strategy C.
Strategy C: Full Runtime Shaping + BiDi (MPU targets)
Embed a full Unicode text shaping engine together with a Unicode Bidirectional (BiDi) implementation. This approach provides desktop-quality rendering for dynamic Arabic text but requires significantly more ROM and RAM, making it suitable for Linux-based MPUs rather than resource-constrained MCUs.
Font Selection for Arabic Embedded GUI
The embedded Arabic font must include:
- Arabic Presentation Forms-A (U+FB50–U+FDFF) — for Strategy A design-time shaping
- Arabic Presentation Forms-B (U+FE70–U+FEFF) — additional presentation forms
- Arabic block (U+0600–U+06FF) — for Strategy B runtime shaping input
- Latin characters (U+0020–U+007F) — for mixed Arabic/English text
Suitable open-source Arabic fonts for embedded use: Noto Naskh Arabic (clean, multi-weight, good readability at small sizes), Amiri (traditional calligraphic style, complex ligatures — heavier ROM footprint), Cairo (geometric Arabic, pairs well with Latin geometric sans-serifs). Subsetting the font to only required Unicode ranges reduces the font ROM footprint by 60–80% compared to the full font file.
Testing Arabic RTL Implementation
Validate Arabic text rendering with these test cases:
- A word containing all four letter forms (initial, medial, final, isolated) — verify correct shaping
- Text alignment: right-aligned Arabic text must visually align to the right edge of the container
- A string with Arabic word + English number + Arabic suffix — verify correct visual ordering
- Long Arabic string that wraps to a second line — verify wrap point is a word boundary and the second line also displays RTL
- Arabic text in a button — verify the button's hit area corresponds to the correct visual text position
Arabic RTL in Sparklet
Sparklet provides efficient Arabic RTL support for static UI text through Flint UI Designer. Arabic text is shaped during the design phase, enabling lightweight rendering on resource-constrained MCU platforms with virtually no runtime overhead. See the Arabic RTL support page for current implementation status and the multi-language support overview for Unicode font engine details. Request the evaluation to test Arabic rendering on your target hardware.