Understanding InPage Files (.INP & .QPS): From Proprietary Legacy Encodings to Modern Unicode Standards
For more than three decades, InPage Urdu has served as the dominant desktop publishing (DTP) software for newspaper typesetting, book publication, court legal petitions, and government records across Pakistan, India, and the South Asian diaspora. However, opening an .INP or .QPS document on modern operating systems (such as Windows 11, macOS, iPadOS, iOS, Android, or Linux) is nearly impossible without archaic hardware dongles or legacy virtual machines. Here is how modern in-browser conversion bridges that gap.
1. Why Can Modern Computers Not Open .INP Files Directly?
When InPage was first engineered in 1994, the modern Unicode Transformation Format (UTF-8 / UTF-16) standard had not yet been widely adopted for complex Perso-Arabic scripts. To solve the complex rendering challenges of Noori Nastaliq (a highly sloping, contextual calligraphic script where letterforms shift drastically based on adjacent characters), the developers designed a proprietary 16-bit binary encoding schema.
0x04 0x81 → Hex:
-04-81 (Internal InPage Glyph Table Index)// Modern Universal Unicode Code Point
U+0627 (ARABIC LETTER ALEF) → UTF-8:
0xD8 0xA7
Because typical software like Microsoft Word, Adobe Acrobat, and Google Chrome expects standard UTF-8 code points, feeding an unparsed .INP file into Word results in complete corruption: either unreadable gibberish, mojibake symbols (e.g. ÔÚ‰), or an immediate file format error. SwiftUtils parses the raw binary stream directly, identifies the text segment boundaries, and remaps every byte sequence to its authentic Unicode character.
2. The Linguistic Mechanics: Ligature Reconstruction & Diacritics
Converting InPage text is significantly more complex than a simple 1:1 character lookup table. Perso-Arabic scripts require advanced contextual rules:
- Noon Ghunna (ں) Disambiguation InPage often encodes the nasalized Noon identically regardless of whether it appears at word-end or inside a stem. Our engine analyzes word boundaries to ensure terminal ں is properly detached.
- Chhoti Yee vs. Bari Yee (ی / ے) Urdu utilizes two distinct Yee letters with completely different grammatical roles. InPage's custom font encoding often blurs these into glyph positions; our converter disambiguates them correctly.
- Heh Variants (Gol Heh ہ vs. Do-Chashmi Heh ھ) Crucial for aspirated Urdu consonants (بھ، پھ، تھ). Conflating Gol Heh and Do-Chashmi Heh alters the semantic meaning of words. Our algorithm preserves authentic orthography.
-
Honorifics & Religious Symbols
Automatically maps complex ligature ligatures such as
ﷺ(PBUH),ﷲ(Allah),ؑ(AS), andؓ(RA) to their official Unicode presentation forms.
3. Microsoft Word (DOCX) & Google Docs Formatting Guide
When you click "Download Word (.docx)" on SwiftUtils, the generated document contains full OpenXML WordprocessingML markup with Right-to-Left bidirectional attributes:
<w:rPr><w:rFonts w:ascii="Jameel Noori Nastaleeq" w:cs="Jameel Noori Nastaleeq"/><w:sz w:val="32"/><w:rtl/></w:rPr>
This means the file opens automatically with right-aligned text, standard 16pt font sizing (ideal for Nastaliq ascenders and descenders), and references the free, widely-installed Jameel Noori Nastaleeq font family. If you do not have Jameel Noori Nastaleeq installed locally, Word and Google Docs seamlessly fall back to Microsoft's built-in Urdu Typesetting or Noto Nastaliq Urdu with zero ligature breakage.
4. Format Comparison: InPage (.inp / .qps) vs. Modern Unicode (DOCX & PDF)
| Feature | InPage (.inp / .qps) | Microsoft Word (.docx) | Portable Document (.pdf) |
|---|---|---|---|
| Cross-Platform Compatibility | Windows only (with dongle) | Universal (Mac, PC, iOS, Android) | Universal across all devices |
| Encoding Standard | Proprietary 16-bit code table | UTF-8 / UTF-16 Unicode | Embedded OpenType vector glyphs |
| Searchability & Copy/Paste | Fails (copies as gibberish) | Full text search & indexing | Full text search & highlighting |
| Web & AI Integration | Incompatible with LLMs/AI | 100% compatible with ChatGPT/Claude | Directly indexable by search engines |
5. In-Browser Conversion Workflow & Client-Side Processing Architecture
SwiftUtils executes 100% of the extraction and conversion logic inside your device's browser sandbox using standard client-side JavaScript, FileReader, and typed array APIs. No files or text data are ever transmitted to any remote server:
Using the HTML5 FileReader.readAsArrayBuffer() API, the file stream is ingested directly into browser RAM. The engine parses the proprietary InPage header offsets and traverses the linked text record blocks without executing native InPage binaries.
The 16-bit InPage character codes are mapped through an exhaustive dictionary of Urdu, Arabic, and Persian glyph definitions to standard Unicode UTF-8 points (U+0600–U+06FF), correctly resolving contextual letterforms and ligatures.
Text runs are structured with strict right-to-left (dir="rtl") attributes. Urdu punctuation (Urdu full-stop ۔, comma ،, and question mark ؟) is normalized alongside embedded English words or numbers.
The normalized text is assembled on-the-fly: for Word, an OpenXML ZIP package (.docx) is built in memory with RTL styles; for PDF, a print document is rendered with embedded Google Noto Nastaliq Urdu typography.
6. Tested Capabilities & Known Technical Limitations
To provide complete transparency for publishing professionals, legal researchers, and archivists, here is the verified capability and limitation matrix of the client-side conversion engine:
| Component / Feature | Support Status | Verified Empirical Behavior & Practical Guidance |
|---|---|---|
| Standard Urdu Text & Nastaliq Ligatures | 100% Supported | Accurately extracts all body text, titles, poetry, and prose. Verified on files exceeding 130,000 words without memory leaks. |
| Numeral Transliteration (Urdu vs. Western) | Configurable | Users can toggle between retaining Eastern Urdu numerals (۱, ۲, ۳) or standard Western numerals (1, 2, 3) in the options panel. |
| InPage Publication Files (.QPS) | Supported | Extracts text across complex newspaper and multi-page publication templates into continuous editable DOCX flow. |
| Multi-Column Floating Frames (.QPS) | Sequential Flow | Text across multiple unlinked layout frames is extracted sequentially rather than preserving desktop publishing absolute XY coordinates. |
| Proprietary InPage Vector Graphics | Not Converted | Custom bezier shapes, proprietary borders, and decorative vector rules unique to InPage are skipped during text extraction. |
| Password-Protected / Corrupted Files | Safe Rejection | Damaged headers or proprietary encryption triggers a clear in-browser validation alert without crashing the page. |
How to Open, Format & Archive InPage (.INP & .QPS) Files in Word & PDF
Read our in-depth technical tutorial on font installation (Jameel Noori Nastaleeq), Word typography settings, and legal document archival.