Typing, Unicode, Search, and Digital Jawi

A Jawi word that looks right in one screenshot may still be broken data. Digital correctness depends on the stored Unicode characters, their logical order, and bidirectional rendering—not on manually arranging attractive glyphs. A reliable workflow therefore tests typing, copying, searching, and font fallback separately.

Type characters, not pictures or presentation forms

Unicode stores an Arabic-script letter once and lets the shaping engine select its contextual glyph. For example, you type the base character ڤ (U+06A4) and the font shapes it inside ڤاڤن papan. Do not choose isolated, initial, medial, or final glyphs from an “Arabic presentation forms” palette. The joining guide explains why the contextual shapes differ.

The Unicode character names are technical labels, not a Malay teaching taxonomy; the apparently surprising name “VEH” does not change the Malaysian use of ڤ as pa. There is also a real interoperability wrinkle around ga: older Malaysian data may use ڬ U+06AC, while the Unicode Standard recommends ݢ U+0762 for Jawi and current DBP dictionary data uses ݢ. They may look alike in some fonts but are not the same code point. This guide therefore uses ݢ in contemporary spellings. A database should preserve an older source faithfully while mapping a known variant only in a documented derived search key.

Keyboard layouts are input maps, not encodings

Operating systems and mobile keyboards place Jawi letters differently. Install a Malay/Jawi-capable layout, open its on-screen keyboard, and learn the positions actually shown on your device. Switching to an “Arabic” layout may omit چ ڠ ڤ ݢ ۏ ڽ, forcing unsafe copy-and-paste from random pages. A layout that offers only legacy ڬ for ga can still read older material, but it does not produce the contemporary ݢ used below.

Whatever layout you use, the output should be ordinary Unicode text. Review the inventory in the Malay-specific letters guide, then try this five-word exercise:

After typing, copy the text into a plain-text editor and back. If a letter turns into a box, the underlying character may still be correct—the destination font may lack a glyph. If it turns into another letter, the input or conversion pipeline changed the data.

Logical order and mixed Rumi–Jawi text

Jawi is stored in reading order even though it displays right to left. A word such as جاوي is stored as jim, alif, wau, ya; software performs the visual reordering. Never reverse its code points manually.

Mixed text is harder because filenames, Latin abbreviations, numbers, slashes, parentheses, and punctuation create directional runs. For example, a logical filename might be:

latihan-جاوي-v2.docx

and a label might be:

Fail Jawi: latihan-جاوي-v2.docx

Do not “fix” a strange visual order by moving letters until one application looks good. First isolate the runs in the user interface: HTML offers dir="rtl", dir="ltr", and dir="auto"; application code can use directional isolation. Keep the lexical Jawi itself clean.

Modern directional controls are invisible format characters. The most useful to recognize are U+2066 LEFT-TO-RIGHT ISOLATE, U+2067 RIGHT-TO-LEFT ISOLATE, and U+2069 POP DIRECTIONAL ISOLATE. Older marks such as U+200E LEFT-TO-RIGHT MARK and U+200F RIGHT-TO-LEFT MARK also occur. Put such controls in layout code only when you understand their scope; hidden controls inside dictionary headwords can make equality and search fail.

Joining controls and copy-and-paste hazards

U+200C ZERO WIDTH NON-JOINER (ZWNJ) deliberately blocks joining; U+200D ZERO WIDTH JOINER (ZWJ) encourages a joining form. They are not invisible spaces for ordinary word division. Contemporary orthographic guidance may require a non-joining boundary in a specialized spelling—for example, certain final consonant clusters—but most Jawi words need neither control.

Copy-and-paste can introduce four common contaminants:

• Arabic presentation-form characters such as ﺡ rather than base ح;
• invisible directional marks copied from a richly formatted page;
• ZWNJ or ZWJ inserted merely to force a preferred glyph;
• visually similar Arabic-script characters with different code points.

NFC normalization composes canonically equivalent sequences but does not convert every compatibility presentation form to its base letter. NFKC can fold many compatibility forms, yet applying it blindly to a whole multilingual corpus may change data beyond Jawi. Normalize through a documented, tested import process; never assume one “normalize” button solves every problem.

Fonts: rendering is not data

Test in at least two fonts with broad Jawi coverage, such as Noto Naskh Arabic and Scheherazade New, plus the production font used by your application. A font may support Arabic but lack a good glyph for ڽ or ۏ. A tofu box indicates missing font support; it does not justify replacing the character with an image.

Pay attention to ڽ in initial and medial position. Unicode explicitly allows its dots to appear below in those contexts so that it remains distinct from ث. A tester unfamiliar with Jawi may incorrectly report this contextual shaping as corruption.

Search and comparison

Search usually compares character sequences, not visual glyphs. A query containing U+06AC will not necessarily match a record containing U+0762, even if the current font makes them look similar. Likewise, text with a hidden ZWNJ differs from text without it.

For a production search system, keep the original spelling for display and create a separate indexed form according to an explicit policy. Log transformations; do not silently overwrite source text. Search can optionally map known encoding variants at query time, but exact search should remain available for diagnosis.

Debugging checklist

When Jawi fails digitally, check in this order:

1. Code point: Is it the intended base character, not a presentation form or look-alike?
2. Logical sequence: Are the characters stored in reading order rather than visually reversed?
3. Hidden characters: Are bidi controls, ZWNJ, ZWJ, or non-breaking spaces present?
4. Font coverage: Does a second Jawi-capable font render the same data correctly?
5. Direction container: Is the surrounding UI using appropriate dir isolation for mixed scripts?
6. Normalization: Are compared strings using the same documented normalization policy?
7. Search index: Does the index transform a variant that the display string preserves?
8. Round trip: Does copy → plain text → paste preserve the same code-point sequence?

Common Mistakes

Pasting a presentation-form glyph

Incorrect

Correct

Replacing a missing glyph with an image

Incorrect

Correct

Reversing characters manually

Incorrect

Correct

Hiding layout fixes inside lexical text

Incorrect

Correct

Key Takeaways

• Store base Unicode characters in logical order and let fonts shape them.
• Treat font support, bidirectional layout, normalization, and search as separate engineering layers.
• Keep hidden controls out of lexical data unless an explicit orthographic or layout policy requires them.
• Verify ڤ ݢ ڠ ڽ ۏ by code point, and test legacy ڬ separately when importing older data; then round-trip the text through multiple fonts and a plain-text editor.