InPage to Unicode Conversion: The Deep Engineering Architecture

1. The Rise of InPage in South Asian Typography

For decades, typesetting the Perso-Arabic Nastaliq (نستعلیق) calligraphy style was one of the most computationally complex challenges in digital typography. Unlike linear scripts such as Latin or Arabic Naskh, Nastaliq is diagonally sloped, cursive, and deeply contextual: a single word descends cascadingly from top-right to bottom-left.

In 1994, Indian software company Concept Software Systems, in collaboration with Pakistani publishers, developed InPage Urdu. InPage achieved typographic brilliance by pre-compiling tens of thousands of handwritten calligraphic ligatures into an internal font called Noori Nastaliq.

It instantly became the undisputed industry standard across newspapers (Daily Jang, Express, Nawa-i-Waqt), book publishing houses, government offices, and legal institutions throughout Pakistan and India.

2. The Engineering Problem: Proprietary 8-Bit Encodings

Because InPage was engineered in the early 1990s—before Unicode had widespread adoption or robust OpenType contextual shaping engines—it bypassed character-based encoding entirely.

Instead of storing abstract letters, InPage stored glyph indices. When an operator pressed keys on an Urdu Phonetic keyboard, InPage's internal layout engine converted keystrokes into specific 8-bit glyph tokens ranging between 0x80 and 0xFF.

3. How Algorithmic InPage-to-Unicode Conversion Works

Modern conversion algorithms—including the in-memory engine running on iloveunicode.com—do not perform a naive byte-for-byte lookup. A naive lookup fails because Urdu orthography has context-sensitive positional forms, non-joining letters, and unique diacritic attachments.

The conversion engine executes in three strict phases:

Phase A: Binary Token Parsing & Normalization

The input stream is inspected. If copied raw text contains extended ASCII byte markers, each character code is converted into its canonical InPage index. Escaped entities, carriage returns, and line feeds (\r\n) are normalized.

Phase B: Contextual Ligature Decomposition

InPage stores multi-letter combinations as singular composite glyph codes. For example:

• Composite glyph for "Allah" (اللہ) decomposed into U+0627 U+0644 U+0644 U+0647
• Honorific ligatures (ﷺ, علیہ السلام, رحمتہ اللہ علیہ) mapped to standard Unicode presentation forms or spelled out sequences.
• Isolated and medial forms of dual letters (e.g., Baa + Alif, Noon Ghunna + Choti Yeh) are decomposed into fundamental Arabic code points.

Phase C: Nastaliq OpenType Harmonization

Once raw letters are generated, they are mapped into the official Unicode 16.0 Arabic block (U+0600 to U+06FF) and Arabic Supplement (U+0750 to U+077F). Modern fonts like Jameel Noori Nastaliq, Mehr Nastaliq, or Noto Nastaliq Urdu use OpenType glyph tables (GSUB/GPOS) to dynamically connect the letters with authentic calligraphy on any modern device.

4. Code Point Mapping Reference Table