Multi-Language Engine — Four Capabilities
How Sparklet handles Unicode, RTL, runtime locale switching, and variable-length text across all supported MCU and MPU platforms.
Full Script Support on Flash-Constrained MCUs
Sparklet's font engine handles Unicode code points across all major scripts: Latin (U+0000–U+024F), Cyrillic (U+0400–U+04FF), Greek (U+0370–U+03FF), Arabic (U+0600–U+06FF and Presentation Forms U+FE70–U+FEFF), Hebrew (U+0590–U+05FF), and CJK Unified Ideographs (U+4E00–U+9FFF). Fonts are compiled from standard TrueType or OpenType files into Sparklet's compressed glyph table format using Flint UI Designer.
Selective glyph compilation
Rather than embedding a complete Unicode font (which would require several megabytes of Flash for a CJK font), Sparklet uses selective glyph compilation. Flint analyses all string table entries across all locales in the project and compiles only the glyphs actually referenced by those strings into the embedded font binary. For a Japanese product with 300 unique kanji in its UI strings, only those 300 glyphs are compiled — not the full JIS set of 6,000+ characters. A full UTF-16 CJK font file is typically 10–30 MB; a Sparklet selective glyph set for a typical Japanese HMI is approximately 300–800 KB — a reduction of over 95%.
Multi-size and anti-aliased rendering
The font binary can include multiple point sizes of the same typeface — for example, 12px body text, 24px headings, and 48px large numeric readouts. All glyphs are rendered with anti-aliasing using Sparklet's AA font renderer (sfont_aa). On platforms with hardware acceleration (DMA2D, D/AVE2D), glyph compositing is offloaded to the accelerator automatically.
Arabic, Hebrew, and Farsi on Any MCU
Arabic, Hebrew, and Farsi are written right-to-left. This creates two distinct challenges: Arabic script shaping (Arabic letters have different glyph forms depending on their position within a word — initial, medial, final, and isolated forms), and bidirectional text (a single string may contain both Arabic and Latin characters, each flowing in the opposite direction).
Design-time Arabic shaping in Flint — zero runtime overhead
For static and semi-static Arabic text — menu labels, unit labels, warning messages, screen titles — Sparklet uses design-time Arabic shaping. Flint pre-shapes all Arabic strings at project export time using Unicode Arabic Presentation Forms (code range U+FE70–U+FEFF). Each Arabic string is stored in the locale string table as a sequence of pre-shaped glyphs in the correct right-to-left glyph order. At runtime, Sparklet's font engine draws the pre-shaped glyph sequence from right to left using the SGUI_TEXT_DIR_RTL text direction flag. No shaping algorithm runs on the MCU — runtime overhead compared to Latin text rendering is minimal. This approach is suitable for all MCU platforms, including Cortex-M0+ class devices.
Runtime shaping for dynamic Arabic strings
For Arabic text generated at runtime — user-entered text, strings received over CAN or MQTT, content from external storage — Sparklet's UTIL layer includes a runtime Arabic shaping module (approximately 300 lines of C, ~1.4 KB of lookup table Flash) for Cortex-M4 and above. For MPU targets running Embedded Linux, full BiDi algorithm support via SheenBidi can be integrated with Sparklet's text pipeline. See Arabic RTL Embedded GUI for the full technical reference.
One Firmware Image, All Languages
Sparklet's multi-language system is based on a string table model. Every text string in the UI — widget labels, unit text, status messages, menu items, warning strings — is defined by a string table key rather than a literal character value. Each locale provides a string table mapping every key to the translated string in that language, in the correct encoding and glyph direction.
Instant locale switch API
At runtime, the application calls a single Sparklet API to switch the active locale. The framework updates all widget text properties by looking up the new locale's string table and re-rendering the affected text regions via dirty-region rendering. No screen rebuild, no widget recreation, no full display clear-and-redraw is required. The locale switch is visually instantaneous — the next rendered frame shows the new language text in all widgets.
Locale definition in Flint
In Flint, locales are defined in the project's locale manager. For Arabic, Flint's locale manager accepts input in standard Unicode Arabic (U+0600–U+06FF) and performs Presentation Form shaping automatically when the project is exported. Flint exports all locale string tables as C constant arrays — switching locales at runtime is a pointer assignment, not a memory allocation. All locales are compiled into the same firmware image with no per-language build variant required.
Variable Length, Auto-Resize, Per-Locale Layout
When locale strings vary significantly in length — German text is typically 30% longer than English equivalents; Arabic text length varies by context — widgets with auto_size enabled expand or contract their bounding box to fit the new text. Containers and layout groups using dynamic sizing reflow accordingly.
Per-locale layout overrides
For fixed-size displays where pixel-perfect layout is required, Sparklet supports per-locale layout override tables — a different widget position or font size can be specified for a specific locale without duplicating the screen definition. This allows a compact CJK font at a slightly larger point size for readability while keeping the same screen layout structure for all other locales.
Supported scripts
Sparklet's multi-language system supports: Latin (all extended variants), Cyrillic, Greek, Arabic (design-time shaping on all MCUs; runtime shaping on Cortex-M4 and above), Hebrew, Farsi/Persian (same shaping mechanism as Arabic), CJK Unified Ideographs (selective glyph compilation), Thai (basic, no ligature in current release), and Devanagari (basic, full support planned). For wearable applications requiring compact multi-language display, see Sparklet for Wearable Displays.
