Ahsan Mehmood — Dev Blog

We Let AI Build SketchUp Models With Nothing But an API

Ahsan Mehmood — Thu, 20 Aug 2026 13:45:47 GMT

OpenSKP's writer API has no Chair class. No Table builder, no furniture module, nothing that knows what a chair is. It exposes materials, layers, groups, component definitions, and faces — the same primitives SketchUp itself is built from — and nothing above that. Which raised an obvious question once the writer shipped: could an AI coding agent, given only that low-level API and a plain-English description of an object, produce a real, correctly-structured .skp file?

We ran the experiment with two different AI coding agents, independently, with no shared prompt engineering between the runs. Both were pointed at the same generic API and asked to build furniture. Neither was given examples of chair geometry or table dimensions to crib from.

Chair, table, and an armchair

Output from an AI agent's own generated Python script, loaded straight into the OpenSKP web viewer with no manual cleanup.

The first run produced a scene with a dining chair, a side table, and an armchair — nine component definitions, thirty-eight geometry primitives in total, organized across three layers with four distinct materials. That structure wasn't hand-specified; the agent decided the layer and material breakdown itself, deriving it from how it reasoned about the objects (seat vs. legs vs. backrest as separate faces sharing a wood material, for instance).

Here's a representative excerpt of what the agent actually wrote, generating a chair leg as an extruded rectangular profile:

def add_leg(group, x, y, z, width, height, material):
    """Add a single tapered leg as a box primitive."""
    pts = [
        (x, y, z),
        (x + width, y, z),
        (x + width, y + width, z),
        (x, y + width, z),
    ]
    top = [(px, py, z + height) for px, py, _ in pts]
    face_bottom = group.add_face(pts, material=material)
    face_top = group.add_face(top, material=material)
    for i in range(4):
        side = [pts[i], pts[(i + 1) % 4], top[(i + 1) % 4], top[i]]
        group.add_face(side, material=material)
    return face_bottom, face_top

Nothing in that function is chair-specific — it's a general box-extrusion routine, the kind of primitive-geometry reasoning you'd expect from someone who understands 3D coordinate systems, not someone who was handed a chair template. The agent built its own mental model of "chair" out of boxes and faces, the same way a human modeler would work from scratch in SketchUp's own polygon tools.

An executive desk

A more complex single object: a desk with a drawer unit, modeled as nested component groups.

The second test pushed further into nested structure: a desk with an attached drawer unit, modeled as a component group nested inside the desk's top-level group — mirroring how a careful human SketchUp modeler would organize the same object, with the drawer as its own reusable component rather than geometry welded directly into the desktop.

A phone, viewed from both sides

Front and back views of the same AI-generated phone model — face winding and normals came out correct on the first attempt.

The third object, from the second independent agent run, was a simplified phone: a thin rounded body, a screen face, and a camera module. What's notable here isn't the object's complexity — it's the simplest of the three — but that face winding order came out correct without being told about it explicitly. Get winding backward and a face renders as invisible or inside-out from the "wrong" side; the model shown above renders correctly from both front and back, which means the agent's geometry reasoning implicitly respected consistent counter-clockwise winding, not just "some points that happen to form a face."

What this does and doesn't prove

This isn't a claim that AI agents can replace a SketchUp modeler for genuinely complex or organic geometry — everything shown here is bounded, rectilinear furniture-and-electronics geometry, well within what an LLM can reason about symbolically in coordinates and box-extrusions. What it does show is that OpenSKP's writer API is low-level enough, and clean enough, that an agent with no domain-specific tooling can drive it correctly: valid component hierarchies, sane material and layer organization, and geometry SketchUp itself opens without complaint.

That's the actual target for the API design — not "convenient for humans typing by hand," but "reasonable for a coding agent to drive from a plain description," since increasingly, that's who's calling it.

Try it yourself: github.com/iamahsanmehmood/openskp — MIT licensed, available for Python, TypeScript, .NET, Dart, and C++.

OpenSKP 1.1.0: A Native .skp Writer, Now in All Five Languages

Ahsan Mehmood — Thu, 20 Aug 2026 13:37:27 GMT

Until 1.1.0, OpenSKP was a read path. You could parse a .skp file — either container format, all five languages — and get materials, layers, geometry, and metadata out of it. What you couldn't do was make a new one. 1.1.0 closes that gap: a real writer, producing files SketchUp itself opens without complaint, shipped in Python, TypeScript, .NET, Dart, and C++ at the same time.

Why write support is a different problem than read support

Parsing forgives sloppiness in a way writing doesn't. A parser that mishandles an obscure edge case just gets slightly wrong data for that one field — annoying, but survivable, and often invisible unless you're specifically checking. A writer that gets the container format wrong produces a file that SketchUp refuses to open at all, or worse, opens with silently corrupted geometry. There's no partial credit.

That asymmetry shaped how the writer got built. It targets the modern VFF container exclusively — the ZIP-based, TLV-tree format used by SketchUp 2021 and later — rather than also targeting the legacy MFC stream format, because VFF is what every current SketchUp install expects by default and where new files should live going forward. Every writer feature was validated the same way the parser's correctness was validated originally: produce a file, open it with the real SketchUp SDK, and confirm the SDK's own reading of geometry, materials, and layer assignments matches what was intended, field by field — not just "the file has a size greater than zero and doesn't crash on open."

What the writer actually does

The API surface is intentionally generic rather than shaped around specific object types. There's no Chair class or Table builder baked into the library — you compose scenes out of the same primitives SketchUp itself works with:

Materials — solid colors, opacity, and image textures
Layers (tags) — for organizing geometry the way SketchUp's own Tags panel does
Groups and component definitions — the same grouping/instancing model SketchUp uses natively, including nested groups
Curves and faces — arbitrary polygon geometry with material and layer assignment per face
create() for a brand-new file, and open_existing() for loading a file, editing it, and writing it back out

open_existing() in particular was the harder of the two entry points to get right. It isn't a byte-patcher that finds the one chunk you touched and surgically rewrites it in place — that approach is fragile against any structural change (add a face, and every downstream offset in the container shifts). Instead it does a full parse of the existing file into the same in-memory model the writer already knows how to serialize, applies your edits to that model, and replays the entire thing back out through the same write path a brand-new file goes through. Slower than a patch, but correct by construction: if create() is trustworthy, open_existing() inherits that trust instead of needing its own separate proof.

Five ports, five different sets of bugs

The writer shipped in Python first, since Python was already the most mature of the five ports and the fastest place to validate the design against the real SDK. Porting it to the other four languages wasn't a mechanical translation exercise — each port's own CI caught real, language-specific problems that the Python reference implementation simply couldn't have surfaced:

C++ — a check_writable helper failed to compile under the CI's stricter build flags, a class of error Python's dynamic typing has no equivalent to catching until runtime, if at all. The C++ port also turned up a clang-format issue where the CI's diff report was silently truncating on longer violations, which needed fixing in the tooling itself before it could be trusted to gate anything.
Dart — trigonometric rounding in transform-matrix math didn't match the other languages' output bit-for-bit, traced to a difference in how Dart's math library rounds versus Python's, and fixed by aligning the rounding step explicitly rather than relying on each language's default behavior.
Two of the ports hit test-ordering bugs — tests that passed individually but failed when run as part of the full suite, because they shared mutable fixture state that Python's test runner happened to isolate in a way the other runner didn't by default.

None of these were writer-logic bugs in the sense of "the geometry is wrong." They were the ordinary friction of porting real, non-trivial code across five different type systems, build toolchains, and test runners — exactly the kind of thing that's invisible if you only ever ship one language, and exactly why keeping five active ports is more expensive than it sounds, but catches more than a single-language project ever would.

Shipping five packages at once

1.1.0 went out to all five registries in the same release cycle — PyPI, npm, NuGet, pub.dev, and a tagged GitHub Release with prebuilt C++ artifacts (C++ has no package registry equivalent, so it ships as a downloadable tarball/zip pair instead). Coordinating that many release pipelines in one pass surfaced two more process-level snags worth naming honestly: a batched multi-language tag push needed the tags separated out per-language rather than pushed as one lump, and pub.dev's own publish flow has a gotcha around tag naming that isn't obvious until it rejects a push.

Neither was a code bug. Both are the kind of thing you only learn by actually running a five-language release end to end, which is exactly what 1.1.0 forced.

What's next

Read and write both exist now, but write support is currently VFF-only — no legacy-MFC writing, and no re-encoding a legacy file into the modern container. Conversion the other direction (glTF, IFC, OBJ into .skp) is on the roadmap but not started. If either of those is something you'd use, the issue tracker is open.

Install:

pip install openskp          # Python
npm install openskp          # TypeScript / JavaScript
dotnet add package OpenSKP   # .NET
dart pub add openskp         # Dart

OpenSKP is open source under the MIT license: github.com/iamahsanmehmood/openskp

Why We Built OpenSKP

Ahsan Mehmood — Thu, 20 Aug 2026 13:32:34 GMT

If you want to read a .dxf file, there's an open specification. If you want to read a .gltf file, there's a Khronos Group standard with a public GitHub repo and a validator you can run against your output. If you want to read a .skp file — SketchUp's own native format — there is nothing. No spec, no schema, no reference decoder. Just a proprietary SDK, licensed by Trimble, that only runs where Trimble lets it run.

That gap is the entire reason OpenSKP exists.

The problem with "just use the SDK"

SketchUp's official SDK is a real, functional way to read and write .skp files — if your project can tolerate everything that comes with it: a native dependency tied to specific platforms, a license that constrains how and where you can ship, and no path at all if you're building for Linux servers, WebAssembly, or anywhere the SDK simply isn't available.

That constraint is exactly what two of the projects OpenSKP now powers ran into. FrameSmart, a 3D collaboration platform, needed to parse SketchUp files as part of a Linux-hosted pipeline. IngeTrazo, a Linux-first 3D modeler for civil engineering, was running the real SketchUp SDK through Wine — a working setup, but a fragile one, dragging a Windows-only dependency into a project that had no other reason to need it.

Neither of those is an unusual situation. Anyone building a pipeline tool, a headless converter, a web-based viewer, or a CI step that touches SketchUp files runs into the same wall: the only "real" way in is a native SDK that assumes you're building a desktop plugin on Windows or macOS.

Reverse-engineering, not guessing

Without a spec, the only way to understand the format is to look at real bytes and figure out what they mean — and then prove the theory rather than just believing it looks plausible. That distinction matters more than it sounds. A parser that produces geometry that looks right in a debug print is not the same as a parser that's actually correct; SketchUp files are dense binary structures where a single misread flag byte can silently corrupt geometry without ever throwing an error.

The methodology that held up: build real files with the actual SketchUp application (or, once OpenSKP's own writer existed, the real SDK as a validation oracle), then diff OpenSKP's understanding of those files against what SketchUp itself reports through its own API — material colors, transparency values, transform matrices, vertex positions, all checked field by field rather than assumed. Several real bugs were only caught this way: a legacy-format alpha byte that four of the five language ports were silently discarding, a face's texture-positioning data that was being parsed but never linked back to the face it belonged to, a slot-numbering edge case that corrupted any file crossing a specific size threshold. None of those would have shown up in a "does it produce a mesh" smoke test. All of them showed up the moment real SketchUp was used as the source of truth.

Two container formats, not one

Part of what makes this format genuinely hard is that it isn't one format — it's two. SketchUp changed its internal container completely in the 2021 release. Files from SketchUp 2021 onward use VFF, a ZIP-based container wrapping a TLV (Tag-Length-Value) binary tree. Files from SketchUp 2013–2020 use something structurally unrelated: a classic MFC CArchive object-graph stream, with its own class-reference and back-reference numbering scheme, no ZIP involved at all.

A tool that only reads one of these covers a shrinking slice of the real files people actually have sitting on disk — architecture firms, civil engineering practices, and product designers routinely have SketchUp libraries stretching back a decade. OpenSKP reads both, transparently, behind the same parse() call in every language, which is a meaningfully larger reverse-engineering effort than picking the newer, better-documented-by-inference format and calling it done.

Why five languages, and why not bindings

OpenSKP isn't a core parser in one language with thin wrapper bindings for the rest. Python, TypeScript, .NET, Dart, and C++ are five independent implementations of the same reverse-engineered format, each idiomatic to its own ecosystem — because a Python native extension is a poor fit for a browser-based TypeScript viewer, and a JavaScript parser is a poor fit for a native C++ desktop tool.

The tradeoff is real: five implementations mean five places a bug can hide, and cross-language parity has to be actively maintained rather than assumed. In practice that means every non-trivial fix gets checked against all five ports' actual source before being called complete, and the same real .skp fixtures get run through every language to confirm they produce identical geometry, layers, and materials — not just "each one compiles and returns something."

Where it stands now

What started as a read-only reverse-engineering project has grown into a full toolkit: parsing both container formats, converting to seven other formats natively (glTF, OBJ, STL, PLY, DXF, IFC4, JSON), and — as of the 1.1.0 release — writing genuinely new .skp files from scratch, in all five languages, with no SketchUp SDK involved at any point.

None of it required Trimble's permission, a license fee, or a Windows machine. That was always the point.

OpenSKP is open source under the MIT license: github.com/iamahsanmehmood/openskp

Building OpenSKP: How We Open-Sourced a Multi-Language 3D SketchUp Parser

Ahsan Mehmood — Wed, 24 Jun 2026 08:52:04 GMT

Reading or viewing SketchUp (.skp) files in custom apps has traditionally been a closed shop. Developers either had to pay for proprietary cloud APIs or deploy Trimble's official C++ SDK natively on servers, which is notoriously difficult to scale in serverless environments or run in web browsers.

To solve this, we built OpenSKP — a pure, open-source binary parser and WebGL viewer for modern SketchUp (v2021+) files.

In this article, I want to take you behind the scenes of how we reverse-engineered the binary format, resolved 3D planar triangulation, and structured a multi-language library to run natively across Python, TypeScript, Dart, and C#.

The VFF Container and Binary TLV Parser

A modern SketchUp file uses a Versioned File Format (VFF). It is a ZIP container wrapped in a 16-byte custom header.

By finding the byte offset of the ZIP file marker (PK\x03\x04), we extract the contents directly into memory to read model.dat — the core binary database containing geometry and instance metadata.

model.dat is structured as a tree of Tag-Length-Value (TLV) nodes. To unpack the model, the parser recursively navigates this tree:

sequenceDiagram
    participant SKP as .skp File
    participant VFF as VFF Header Reader
    participant ZIP as In-Memory ZIP Extractor
    participant TLV as Recursive TLV Parser
    participant Geom as Geometry Builder (Vertices/Edges/Faces)
    participant Scene as 3D Scene Graph (GLB/glTF)

    SKP->>VFF: Open Binary Stream
    VFF->>VFF: Parse Magic (FF FE FF 0E) and Version
    VFF->>ZIP: Find ZIP Offset (PK\x03\x04)
    ZIP->>ZIP: Extract model.dat & materials XMLs
    ZIP->>TLV: Load model.dat payload
    loop Recursive Parse
        TLV->>TLV: Read Tag (2B) + Size (4B) + Value
    end
    TLV->>Geom: Map Tags (C409 Verts, B80B Edges, AC0D Faces)
    Geom->>Scene: Triangulate & Transform meshes (3x4 matrices)
    Scene->>Scene: Package GLB & Metadata JSON

Key Technical Challenges

1. 3D Planar Triangulation

SketchUp files store faces as n-sided planar polygons, which can have nested inner holes (like windows inside walls). Since GPUs only render triangles, we had to build a robust triangulation pipeline:

Extract the face normal vector from the AD0D tag.
Project the 3D vertices onto a local 2D plane perpendicular to the normal.
Apply a 2D triangulation algorithm (using Earcut for JavaScript and Shapely for Python) to resolve boundaries and holes.
Project the index results back into 3D space.

2. Multi-Language Consistency

Since developers work in different environments, we wanted OpenSKP to run natively in their preferred language. We structured the monorepo into 4 packages:

packages/python: A pure Python library, perfect for Django/Flask/FastAPI backends and serverless conversion tasks.
packages/typescript: Compiled to ES modules, allowing developers to run the entire parser client-side in the browser.
packages/dart: Native Dart library enabling mobile and desktop Flutter viewers.
packages/dotnet: Standard .NET library for enterprise C# engineering pipelines.

How to Use OpenSKP in Your Projects

Python 🐍

pip install openskp

from openskp import SkpFile
from openskp.export import glb

# Parse SKP
skp = SkpFile.open("model.skp")
model = skp.parse()

# Save as GLB
glb.export(skp, "output.glb")

TypeScript / JavaScript 🌐

npm install openskp

import { parseSkp } from 'openskp';

// Parse array buffer directly in browser
const model = parseSkp(arrayBuffer);
console.log("Layers:", model.layers);

Dart / Flutter 🎯

dependencies:
  openskp: ^0.2.0

.NET / C# 💻

dotnet add package OpenSkp

Battle-Tested in Production

OpenSKP isn't just a prototype; it is already running in production to parse and visualize framing panels, studs, and trusses in real-time at Frame-Smart!

Special thanks to Noor Ali Qureshi (@nooraliqureshi) for contributing critical parsing fixes that resolved component instance and material rendering bugs across multiple SketchUp file versions.

Star Us on GitHub! ⭐️

OpenSKP is released under the MIT License. We welcome contributions from the community to expand the parser's capabilities.

👉 Join us on GitHub: https://github.com/iamahsanmehmood/openskp

I Built the First Deterministic Urdu Compound Word Detector — Here's Why It Took a Full Library to Get There

Ahsan Mehmood — Mon, 27 Apr 2026 18:41:23 GMT

Urdu is spoken by over 230 million people. It is the national language of Pakistan, one of the 22 scheduled languages of India, and the lingua franca of a diaspora spanning three continents. And yet, if you try to build Urdu software today — real software, not a toy — you will hit the same wall every other developer hit before you: the tools do not exist.

I hit that wall building HamaariUrdu, an Urdu language learning platform. This post is about what I built to fix it.

The bugs that no library could fix

I was not looking to build a library. I was looking to ship features. But the bugs kept piling up, and none of the available Urdu NLP libraries (UrduHack, URDUNLP, or anything else) could fix them.

Bug 1: Search returning zero results for words that are obviously in the database.

The database stored ہے using the correct Urdu ہ (U+06C1, Heh Goal). The user's keyboard typed Arabic ه (U+0647, Heh). Both look completely identical on screen in Naskh fonts. But U+06C1 !== U+0647. Zero results. No error. No warning. Just silence.

Bug 2: String equality silently failing.

"قلم" === "قلم"  // false — why?!

One of those strings was copied from Microsoft Word and contains an invisible ZWNJ (Zero Width Non-Joiner, U+200C) that Word inserts automatically. You cannot see it. Your editor does not show it. But the comparison fails.

Bug 3: TinyMCE destroying Izafat.

In Urdu grammar, Izafat (اضافت) is a grammatical construction that links two words — like the English "of" but expressed as a marker on the first word. The marker is often an apostrophe-like character (U+2019, Right Single Quotation Mark).

TinyMCE — a very popular rich text editor — silently converts U+2019 to ’ before saving. So a word like کتابِ (with Kasra) or a phrase using Izafat apostrophe gets stored as an HTML entity. Every compound word lookup in the database then fails because the stored form doesn't match the queried form.

Bug 4: Numbers overflowing.

Urdu text frequently references South Asian scale: لاکھ (100,000), کروڑ (10,000,000), ارب (1,000,000,000). These are real everyday numbers in Pakistan — newspaper headlines, financial documents, government statistics.

Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991. A single کھرب (1 trillion) value loses precision with typeof number. JavaScript silently gives you the wrong answer.

Bug 5: Sorting broken for every Urdu word list.

No database and no JavaScript runtime has native Urdu collation. The Urdu alphabet has 39 letters in a specific order that does not match either Unicode codepoint order or any Latin-derived collation. Every sorted word list was wrong.

Bug 6 — the worst one: Compound words destroying every downstream NLP task.

This one deserves its own section.

The compound word problem

Urdu مرکب الفاظ (compound words) are multi-word expressions that function as a single semantic unit but are written with spaces between their parts.

کتاب خانہ  →  library  (کتاب = book, خانہ = place)
بے عزت     →  disrespectful  (بے = without, عزت = honor)
خوش قسمت  →  fortunate  (خوش = well, قسمت = fate)
علم و عمل  →  knowledge and practice  (fixed expression)
محنت مشقت →  hard work  (synonym compound)

A naive tokenizer sees spaces and splits them. The result:

Input:   "اس نے کتاب خانہ بنایا"
                ↑ ↑
         space between compound components

Wrong:   ['اس', 'نے', 'کتاب', 'خانہ', 'بنایا']
         (5 tokens — "library" is split into "book" + "place")

Right:   ['اس', 'نے', 'کتاب‌خانہ', 'بنایا']
         (4 tokens — "library" is one semantic unit)

The consequences ripple into every downstream NLP task:

Task	What breaks
Search	`کتاب خانہ` doesn't match `کتاب‌خانہ` — zero results
NER	`امورِ خانہ داری` (household affairs) split into 3 unrelated tokens
Sentiment	`بے عزت` (disrespectful) vs `بے` + `عزت` — polarity lost
Translation	`رنگ برنگے` (colorful) translated as "color" + unknown
Word count	Every compound inflates the count with phantom tokens

Why this is genuinely hard

Urdu compound words span four different morphological strategies simultaneously:

Strategy 1 — Affix-based: One word contains a known derivational morpheme (prefix or suffix):

کتاب + خانہ   →  library   (خانہ = "place of" suffix)
بے + عزت      →  disrespectful  (بے = "without" prefix)  
خوش + قسمت   →  fortunate  (خوش = "well" prefix)
کتاب + داری   →  librarianship  (داری = "keeping" suffix)

Strategy 2 — Izafat: A grammatical linking marker appears in the text, written or implied:

کتابِ حسنہ    (the good book)  — Zer mark (◌ِ) on first word
روحِ رواں     (driving spirit) — Hamza-above (◌ٔ) marker
علم و عمل     (knowledge and practice) — Vav-e-atf (و) connector

Strategy 3 — Lexical: Neither word is morphologically special. You simply have to know these pairs:

محنت مشقت     (hard work — synonym compound)
رنگ برنگے     (colorful — echo compound)
صبر شکر       (patient gratitude — near-synonym pair)
انسائیکلوپیڈیا آف اسلام  (3-word fixed title)

Strategy 4 — Chains: Three or more words where each link is independently valid:

امورِ خانہ داری  (household affairs — 3 words)
↑       ↑   ↑
izafat  affix  suffix

Decomposition:
امورِ + خانہ  →  izafat compound
خانہ + داری  →  affix compound
Merged:  امورِ خانہ داری  →  one 3-word compound

No statistical model trained on general text reliably covers all four strategies. They operate at different linguistic levels and require different detection mechanisms.

The approach: three deterministic layers

Every other Urdu compound detection library (where one even exists) treats this as a machine learning problem. They feed training data into statistical models and hope the probabilities align.

That means:

Results change unpredictably between corpus versions
You cannot explain why a pair was or wasn't detected
Edge cases (literary izafat, 3-word expressions, echo words) fail silently
No deterministic guarantee across identical inputs

urdu-tools takes the opposite approach. Every detection is grounded in one of three verifiable, explainable rules:

Raw text
   │
   ├─► Layer 1 — Affix (UAWL)
   │       100+ known Urdu prefix/suffix morphemes
   │       خانہ  گاہ  پرست  بے  نا  خوش  شب  غم  …
   │
   ├─► Layer 2 — Izafat
   │       zer mark (◌ِ) · hamza-above (◌ٔ) · vav-e-atf (و)
   │       کتابِ حسنہ · روحِ رواں · علم و عمل
   │
   └─► Layer 3 — Lexicon
           3,262 root entries · N-word tails · greedy longest-match
           محنت مشقت · رنگ برنگے · انسائیکلوپیڈیا آف اسلام
               │
               └─► Span chaining
                       امورِ خانہ  +  خانہ داری  →  امورِ خانہ داری

The same input always produces the same output, always with a reason.

This is the first open-source implementation of deterministic, multi-layer, N-gram Urdu compound detection in any language.

Introducing urdu-tools

github.com/iamahsanmehmood/urdu-tools

A production-quality, zero-dependency Urdu text processing library. Available for TypeScript/JavaScript and C#/.NET, with identical APIs in both.

npm install @iamahsanmehmood/urdu-tools

dotnet add package UrduTools.Core

392 tests passing. 85 C# tests. 90%+ coverage enforced in CI.

The compound detection API

import {
  detectCompounds,
  joinCompounds,
  splitCompounds,
  isCompound
} from '@iamahsanmehmood/urdu-tools/compound'

Detecting compounds

// Layer 1: Affix — خانہ is a known place-suffix
detectCompounds('کتاب خانہ بہت اچھا ہے')
// → [{
//     text: 'کتاب خانہ',
//     type: 'affix',
//     components: ['کتاب', 'خانہ'],
//     start: 0,
//     end: 1
//   }]

// Layer 1: Affix — بے is a known privative prefix
detectCompounds('بے عزت آدمی نہیں چاہیے')
// → [{ text: 'بے عزت', type: 'affix', components: ['بے', 'عزت'], ... }]

// Layer 2: Izafat — standalone و (vav-e-atf) between content words
detectCompounds('علم و عمل ضروری ہے')
// → [{ text: 'علم و عمل', type: 'izafat', components: ['علم', 'و', 'عمل'], ... }]

// Layer 3: Lexicon — echo compound, neither word is an affix
detectCompounds('رنگ برنگے پھول کھلے ہیں')
// → [{ text: 'رنگ برنگے', type: 'lexicon', components: ['رنگ', 'برنگے'], ... }]

// Lexicon: synonym compound
detectCompounds('محنت مشقت کے بغیر کامیابی نہیں')
// → [{ text: 'محنت مشقت', type: 'lexicon', ... }]

// 3-word chain: izafat (zer on امورِ) + affix (داری suffix on خانہ)
detectCompounds('امورِ خانہ داری چلانا مشکل ہے')
// → [{ text: 'امورِ خانہ داری', type: 'affix', components: ['امورِ', 'خانہ', 'داری'], ... }]

// 3-word lexicon entry: greedy longest-match wins over any 2-word overlap
detectCompounds('انسائیکلوپیڈیا آف اسلام کا حوالہ')
// → [{ text: 'انسائیکلوپیڈیا آف اسلام', type: 'lexicon', ... }]

The pipeline: join before tokenize

The critical downstream use case — bind compounds before tokenizing:

import { joinCompounds } from '@iamahsanmehmood/urdu-tools/compound'
import { tokenize } from '@iamahsanmehmood/urdu-tools'

const text = 'کتاب خانہ میں علم و عمل کی کتابیں ہیں'

// Without compound joining — naive tokenizer splits everything
tokenize(text)
// → ['کتاب', 'خانہ', 'میں', 'علم', 'و', 'عمل', 'کی', 'کتابیں', 'ہیں']
//    ↑ split!                 ↑ split!

// With compound joining — semantic integrity preserved
const joined = joinCompounds(text)
// → 'کتاب‌خانہ میں علم‌و‌عمل کی کتابیں ہیں'
//          ↑ ZWNJ (invisible, prevents tokenizer split)

tokenize(joined)
// → ['کتاب‌خانہ', 'میں', 'علم‌و‌عمل', 'کی', 'کتابیں', 'ہیں']
//    ↑ one token            ↑ one token  ✓

The ZWNJ (Zero Width Non-Joiner, U+200C) is invisible but meaningful — the tokenizer sees it and keeps the word intact.

Pair-level check

isCompound('کتاب', 'خانہ')    // → { matched: true,  type: 'affix'   }
isCompound('محنت', 'مشقت')    // → { matched: true,  type: 'lexicon' }
isCompound('اخلاقِ', 'حسنہ')  // → { matched: true,  type: 'izafat' }
isCompound('اچھا', 'آدمی')    // → { matched: false, type: null      }

Fine-grained control

// Use only specific layers
detectCompounds(text, { affix: true, izafat: false, lexicon: false })
detectCompounds(text, { affix: false, izafat: true, lexicon: true })

// Choose the binder character for joinCompounds
joinCompounds(text)                      // ZWNJ U+200C (default, invisible)
joinCompounds(text, { binder: 'nbsp' })  // Non-breaking space (visible)
joinCompounds(text, { binder: 'wj' })   // Word Joiner U+2060 (never line-breaks)

// Inverse — split back to spaces
splitCompounds('کتاب‌خانہ')  // → 'کتاب خانہ'

The normalization pipeline

A 12-layer normalization pipeline — the foundation that every other module builds on.

import { normalize, fingerprint } from '@iamahsanmehmood/urdu-tools'

Layer	What it does	Default
1 — NFC	Unicode canonical form	✅
2 — NBSP	Non-breaking space → regular space	✅
3 — Alif Madda	`آ` → `آ` (precomposed)	✅
4 — Numerals	`٠–٩` and `۰–۹` → ASCII `0–9`	✅
5 — Zero-width	Strip ZWNJ, ZWJ, soft hyphen	✅
6 — Diacritics	Strip zabar, zer, pesh, shadda, sukun, tanwin	✅
7 — Honorifics	Strip Islamic honorific signs (ؐ ؑ ؒ ؓ ؔ)	✅
8 — Hamza	`أ` → `ا`, `ؤ` → `و`	✅
9 — Kashida	Strip tatweel U+0640	❌
10 — Presentation forms	Map U+FB50–FEFF to base chars	❌
11 — Punctuation trim	Strip leading/trailing non-letter chars	❌
12 — Char normalize	Arabic look-alikes → correct Urdu codepoints	❌

normalize('عِلمٌ')                    // 'علم'  (layers 1–6: diacritics stripped)
normalize('آ')             // 'آ'    (layer 3: Alif + Madda → precomposed)
normalize('علم‌ہے')             // 'علمہے' (layer 5: ZWNJ stripped)
normalize('نبیؐ')                    // 'نبی'  (layer 7: honorific stripped)

// Full normalization for search indexing
normalize(userInput, {
  kashida: true,
  presentationForms: true,
  punctuationTrim: true,
  normalizeCharacters: true,   // ي → ی, ك → ک, ه → ہ
})

The fingerprint function

For client-side word comparison without database round-trips:

fingerprint('عِلمٌ') === fingerprint('عَلم')   // true (both normalize to 'علم')
fingerprint('نبیؐ') === fingerprint('نبی')     // true (honorific stripped)
fingerprint('علم‌') === fingerprint('علم') // true (ZWNJ stripped)

We use this in HamaariUrdu to compare user input against stored words in a 110,000+ word dictionary without needing a round-trip to the database for every keystroke.

The Arabic–Urdu confusion problem

This is the single most common source of silent failures in Urdu software, and no existing library addressed it.

Three character pairs are visually identical in Naskh fonts but are different Unicode code points:

Visual	Arabic codepoint	Urdu codepoint	Common source
ی	ي U+064A	ی U+06CC	Arabic-layout keyboards, Arabic websites
ک	ك U+0643	ک U+06A9	Arabic-layout keyboards
ہ	ه U+0647	ہ U+06C1	Arabic text pasted into Urdu context

A user searching for ہے typed with Arabic ه finds zero results in a database that stored it with Urdu ہ. Both look identical on screen. No error. No warning. Zero results.

import { normalizeCharacters } from '@iamahsanmehmood/urdu-tools'

normalizeCharacters('ي')  // → 'ی'  (U+064A → U+06CC)
normalizeCharacters('ك')  // → 'ک'  (U+0643 → U+06A9)
normalizeCharacters('ه')  // → 'ہ'  (U+0647 → U+06C1)

// Apply before storage or search indexing:
normalize(userInput, { normalizeCharacters: true })

Progressive search matching

The search module tries 9 progressively aggressive normalization layers until it finds a match — or returns false with full diagnostic info.

import { match, fuzzyMatch, getAllNormalizations } from '@iamahsanmehmood/urdu-tools'

match('عِلمٌ', 'علم')
// → { matched: true, layer: 'strip-diacritics', normalizedQuery: 'علم', normalizedTarget: 'علم' }

match('نبیؐ', 'نبی')
// → { matched: true, layer: 'strip-honorifics', ... }

match('أحمد', 'احمد')
// → { matched: true, layer: 'normalize-hamza', ... }

match('کتاب', 'علم')
// → { matched: false, layer: null, ... }

For database lookups, getAllNormalizations() returns every normalized form to try:

const forms = getAllNormalizations('عِلمٌ')
// → ['عِلمٌ', 'عِلم', 'علم', ...]  (from most specific to most aggressive)

for (const form of forms) {
  const result = await db.get(form)
  if (result) return result
}

Fuzzy matching uses Levenshtein + LCS hybrid (threshold 0.5):

fuzzyMatch('کتاب', ['کتابیں', 'کتب', 'علم'])
// → { candidate: 'کتابیں', score: ~0.7 }

Numbers — South Asian scale with bigint

The South Asian number system has named units that don't exist in Western mathematics:

Urdu	Value
ہزار	1,000
لاکھ	100,000
کروڑ	10,000,000
ارب	1,000,000,000
کھرب	1,000,000,000,000
نیل	1,000,000,000,000,000

The entire module uses bigint throughout — South Asian numbers exceed Number.MAX_SAFE_INTEGER.

import { numberToWords, formatCurrency, toUrduNumerals, wordsToNumber } from '@iamahsanmehmood/urdu-tools'

numberToWords(0n)                      // 'صفر'
numberToWords(100n)                    // 'ایک سو'
numberToWords(100_000n)                // 'ایک لاکھ'
numberToWords(10_000_000n)             // 'ایک کروڑ'
numberToWords(1_000_000_000_000_000n)  // 'ایک نیل'

// Ordinals with gender agreement
numberToWords(1n, { ordinal: true, gender: 'masculine' })  // 'پہلا'
numberToWords(1n, { ordinal: true, gender: 'feminine' })   // 'پہلی'
numberToWords(11n, { ordinal: true, gender: 'masculine' }) // 'گیارہواں'
numberToWords(11n, { ordinal: true, gender: 'feminine' })  // 'گیارہویں'

// Currency
formatCurrency(505.50, 'PKR')  // 'پانچ سو پانچ روپے پچاس پیسے'
formatCurrency(1000, 'INR')    // 'ایک ہزار روپے'

// Numeral conversion
toUrduNumerals(2024)    // '۲۰۲۴'

// Inverse — parse words back to number
wordsToNumber('ایک کروڑ')     // 10_000_000n
wordsToNumber('پانچ سو پانچ') // 505n

Canonical Urdu sorting

No database and no JavaScript runtime has native Urdu collation. The 39-letter Urdu alphabet order:

ء ا ب پ ت ٹ ث ج چ ح خ د ڈ ذ ر ڑ ز ژ س ش ص ض ط ظ ع غ ف ق ک گ ل م ن ں و ہ ھ ی ے

import { sort, compare, sortKey } from '@iamahsanmehmood/urdu-tools'

sort(['ے', 'ا', 'ک', 'ب'])           // → ['ا', 'ب', 'ک', 'ے']
sort(['زبان', 'اردو', 'بہترین'])      // → ['اردو', 'بہترین', 'زبان']

// Use compare() as a comparator for any sorting context
['ے', 'ا', 'ک'].sort(compare)        // → ['ا', 'ک', 'ے']

// sortKey() for indexing — diacritics stripped before key generation
sortKey('پاکستان')   // '030003091102280814'
// عِلم and عَلم sort to the same position

In C# it implements IComparer for native LINQ integration:

using UrduTools.Core.Sorting;

var words = new[] { "ے", "ا", "ک", "ب" };
var sorted = words.OrderBy(w => w, new UrduComparer()).ToList();
// ["ا", "ب", "ک", "ے"]

Unicode-aware tokenization

The tokenizer handles the edge cases that matter in real Urdu text:

import { tokenize, sentences, ngrams } from '@iamahsanmehmood/urdu-tools'

tokenize('پاکستان ایک خوبصورت ملک ہے')
// → [
//   { text: 'پاکستان', type: 'urdu-word' },
//   { text: 'ایک',     type: 'urdu-word' },
//   { text: 'خوبصورت', type: 'urdu-word' },
//   { text: 'ملک',     type: 'urdu-word' },
//   { text: 'ہے',      type: 'urdu-word' },
// ]

// Sentence splitting — on ۔ (U+06D4) ؟ ! but NOT on ، or ؛
sentences('پہلا جملہ۔ دوسرا جملہ؟ تیسرا جملہ!')
// → ['پہلا جملہ', 'دوسرا جملہ', 'تیسرا جملہ']

// The tokenizer preserves ZWNJ within words —
// so joinCompounds() output is one token per compound

Key edge cases handled:

Izafat Kasra (U+0650) at word boundaries is not treated as a split point
ZWNJ-bound compounds (output of joinCompounds()) are kept as single tokens
Mixed Urdu/Latin text is classified per-token

Transliteration — 18 aspirated digraphs

import { toRoman, fromRoman } from '@iamahsanmehmood/urdu-tools'

toRoman('پاکستان')   // 'pakistan'
toRoman('بھارت')     // 'bharat'
toRoman('چھوٹا')     // 'chhota'

Digraph rules (left-to-right FSM, digraph priority):

Urdu	Roman	Urdu	Roman
بھ	bh	پھ	ph
تھ	th	ٹھ	Th
جھ	jh	چھ	chh
دھ	dh	ڈھ	Dh
کھ	kh	گھ	gh

fromRoman('pakistan')  // → 'پاکستان' (trie-based longest-prefix match)
fromRoman('bharat')    // → 'بھارت'

InPage encoding — decoding 30 years of Urdu archives

InPage was the dominant Urdu desktop publishing tool for decades. Millions of documents — newspapers, books, government archives — exist only in InPage format. The library decodes all three versions:

import { decodeInpage, detectEncoding } from '@iamahsanmehmood/urdu-tools'

// Auto-detect InPage version and decode
const result = decodeInpage(buffer, 'auto')
// result.paragraphs → string[]  (Unicode Urdu text)
// result.version   → 'v1' | 'v2' | 'v3'

// Explicit version
decodeInpage(buffer, 'v1')  // 0x04-prefix byte-pair encoding (old InPage)
decodeInpage(buffer, 'v3')  // UTF-16LE with paragraph markers

// Detect encoding from buffer alone
detectEncoding(buffer)
// → 'utf-8' | 'utf-16le' | 'windows-1256' | 'inpage-v1v2' | 'inpage-v3' | 'unknown'

String utilities

import { reverse, truncate, wordCount, charCount,
         extractUrdu, decodeHtmlEntities } from '@iamahsanmehmood/urdu-tools'

// Reverse word order (not characters — preserves Arabic shaping)
reverse('پاکستان ہندوستان')      // → 'ہندوستان پاکستان'

// Truncate at word boundary
truncate('یہ ایک بہت لمبا جملہ ہے', 10)  // → 'یہ ایک...'

// Count grapheme clusters (correct for combining diacritics)
charCount('عِلم')   // → 3  (ع+ِ = 1 cluster, ل, م)

// Extract Urdu/Arabic segments from mixed text
extractUrdu('The word علم means knowledge')  // → ['علم']

// Decode HTML entities BEFORE normalize() — critical for TinyMCE/Quill content
decodeHtmlEntities('کتاب’خانہ')  // → 'کتاب’خانہ'
decodeHtmlEntities('علم ہے')      // → 'علم ہے'

That last one (decodeHtmlEntities) is the fix for the TinyMCE bug mentioned at the top. Always call it before normalizing text that came from a rich text editor.

Script and character analysis

import { isUrduChar, getScript, classifyChar, isRTL, getUrduDensity } from '@iamahsanmehmood/urdu-tools'

isUrduChar('پ')  // true  — U+067E is Urdu-specific
isUrduChar('ب')  // false — U+0628 is shared with Arabic
isUrduChar('۱')  // true  — U+06F1 Urdu numeral

getScript('پاکستان')          // 'urdu'
getScript('مرحبا')             // 'arabic'
getScript('Hello پاکستان')    // 'mixed'

classifyChar('پ')   // 'urdu-letter'
classifyChar('َ')   // 'diacritic'
classifyChar('۱')   // 'numeral'

isRTL('پاکستان')               // true
getUrduDensity('پاکستان زندہ') // 0.28

C#/.NET — identical API, zero dependencies

Every function is available in UrduTools.Core with the same behavior. The C# package mirrors the TypeScript structure exactly.

using UrduTools.Core.Normalization;
using UrduTools.Core.Compound;
using UrduTools.Core.Numbers;
using UrduTools.Core.Sorting;
using UrduTools.Core.Search;

// Normalize
UrduNormalizer.Normalize("عِلمٌ");                          // "علم"
UrduNormalizer.Normalize("علم‌");                      // "علم"

// Compound detection
var spans = CompoundDetector.DetectCompounds("کتاب خانہ میں");
// spans[0].Text == "کتاب خانہ"
// spans[0].Type == CompoundType.Affix

// Numbers
NumberToWords.Convert(10_000_000);  // "ایک کروڑ"
NumberToWords.Convert(1, new NumberOptions { Ordinal = true, Gender = Gender.Feminine });  // "پہلی"

// Sort
var sorted = new[] { "ے", "ا", "ک", "ب" }
    .OrderBy(w => w, new UrduComparer())
    .ToList();  // ["ا", "ب", "ک", "ے"]

// Progressive normalization for DB lookup
foreach (var form in UrduMatcher.GetAllNormalizations(userInput))
{
    var result = await db.LookupAsync(form);
    if (result is not null) return result;
}

// Match
UrduMatcher.Match("عِلمٌ", "علم").Matched;  // true, layer: StripDiacritics

Academic foundation

The compound word detection module was built on peer-reviewed Urdu linguistics research. These three works directly informed the architecture:

Jabbar, A. (2016). "Urdu Compound Words Manufacturing a State of Art." Provides the Urdu Affix Word List (UAWL) — the definitive catalog of Urdu derivational morphemes. The 100+ affix morphemes in Layer 1 (AFFIX_SET, PREFIX_SET, SUFFIX_SET) are drawn from this work.

Rahman, M. "A Linguistic Classification of Urdu Compound Words." Informed the typological distinctions between compound categories — specifically the Perso-Arabic vs. native Urdu origin split and vav-e-atf chain patterns. Shaped the CompoundType taxonomy and izafat heuristics.

"High Performance Stemming Algorithm to Handle Multi-Word Expressions." Motivated the joinCompounds() + tokenize() pipeline design — the paper demonstrates that semantic integrity is best preserved by preventing erroneous splits at the input boundary, not by post-processing token sequences. Also reinforced N-gram scanning over bigram-only approaches.

Used in production

This library is not a side project. It runs in three production systems:

System	Type
HamaariUrdu	Urdu language learning platform — normalization, search, compound detection, numbers
Pakistan Academy of Letters	Government literary institution — normalization, search, sorting
Digital Library of PAL	Government digital Urdu archive — normalization, search, encoding

HamaariUrdu was the origin — the library was extracted from production code where these problems were first encountered and solved. PAL and DLP integrated later for their Urdu text search and archiving systems.

Live Playground

Every function is interactive at iamahsanmehmood.github.io/urdu-tools.

The playground includes compound reporting built-in: if you find a compound the detector misses, or a pair it wrongly detects, you can report it directly from the UI — a pre-filled GitHub issue opens in one click.

Contributing

The compound lexicon (3,262 roots, expandable) is the highest-impact area for non-developer contributions. If you know Urdu, you can contribute without writing code:

// packages/urdu-js/src/compound/lexicon-data.ts
// Format: ['rootWord', new Set(['tail1', 'tail2'])]

['محنت', new Set(['مشقت'])],
['علم', new Set(['و ہنر', 'و عمل', 'کیمیا'])],
['انسائیکلوپیڈیا', new Set(['آف اسلام'])],

Full guide in CONTRIBUTING.md.

GitHub: github.com/iamahsanmehmood/urdu-tools

اردو سافٹ ویئر کو بہتر بنانے میں ہمارا ساتھ دیں۔ Help us make Urdu software better.

Tags: #urdu #nlp #typescript #dotnet #opensource

Why I Still Use WinForms in 2026 — And When You Should Too

Ahsan Mehmood — Mon, 09 Mar 2026 18:04:26 GMT


Yes, WinForms. In 2026. And I'm not embarrassed about it.

I've shipped 12+ desktop applications using WinForms over the past 5 years — including a multi-terminal POS system that handles real restaurants with real money every single day. Let me explain why WinForms still has a place, and when you should (and shouldn't) use it.

## The Hot Take

Every year, someone writes an article titled "WinForms is dead." Every year, thousands of businesses continue running on WinForms applications that just work.

Here's the reality: **WinForms isn't dead. It's boring. And boring technology that works is extremely valuable.**

## When I Choose WinForms

### 1. Internal Business Tools

When a restaurant owner needs a POS system, they don't care if it's built with Blazor, MAUI, or WinForms. They care if it:
- Launches in under 2 seconds
- Never crashes during dinner rush
- Prints receipts without drama
- Works on the old Windows 10 machine they already have

WinForms does all four of these better than any modern alternative I've tested.

### 2. Hardware Integration

Thermal printers, barcode scanners, cash drawers, kitchen display screens — WinForms talks to all of these through native Windows APIs without fighting abstraction layers.

```csharp
// Direct serial port access for receipt printer
using (var port = new SerialPort("COM3", 9600))
{
    port.Open();
    port.Write(escPosCommands, 0, escPosCommands.Length);
}
```

Try doing this in a web app. You'll need Electron, a bridge layer, custom browser extensions, or a local service. WinForms? Three lines.

### 3. Speed of Development

A WinForms CRUD app with DataGridView, forms, and dialogs takes me about **60% less time** to build than the equivalent React + API + database setup. For internal tools that 3 people will use, that speed difference is worth more than any architectural elegance.

## When I Don't Choose WinForms

### 1. Anything Cross-Platform
If it needs to run on Mac, Linux, or mobile — WinForms is wrong. I use Flutter for mobile and React for web.

### 2. Public-Facing Products
If customers will download and install it, I lean toward .NET MAUI or a web app. WinForms apps look dated by default, and while you can make them beautiful, it takes disproportionate effort.

### 3. Cloud-First Applications
If the app needs to run in the cloud, scale horizontally, or integrate with microservices — WinForms is the wrong tool. Use ASP.NET or a proper web framework.

## My WinForms Stack in 2026

```
- .NET Framework 4.8 (most projects) or .NET 8 (new projects)
- WinForms for UI
- Entity Framework for data access
- SQL Server for database
- DevExpress or custom controls for better visuals
- IMS Print Service (custom Windows Service) for printing
- MVVM-ish pattern (not strict, but organized)
```

## Real Examples

Here are WinForms apps I've shipped that are running in production right now:

| App | Users | What It Does |
|---|---|---|
| **RestoCare+ POS** | 3-5 terminals | Restaurant point-of-sale |
| **Payroll System** | 10+ users | Employee payroll processing |
| **Accounting Module** | 5+ users | Financial tracking |
| **Engineering Calculator** | 3 engineers | Structural analysis |
| **Inventory Manager** | 5+ terminals | Stock & warehouse |

## The Real Lesson

Technology choice should be driven by **constraints, not trends**. My constraints are:
- Windows-only environments
- Hardware integration requirements
- Small user counts (3-50 people)
- Tight deadlines (weeks, not months)
- Reliability over aesthetics

WinForms fits these constraints perfectly. If your constraints are different, choose accordingly.

Don't let Twitter tell you what technology to use. Let your users and their problems decide.

---

*I'm Ahsan Mehmood, Co-Founder of [XechTech](https://xechtech.com). I build production software with .NET, Flutter, and AI — whatever solves the problem.*

*Connect: [LinkedIn](https://linkedin.com/in/iamahsanmehmood) · [GitHub](https://github.com/iamahsanmehmood) · [Dev.to](https://dev.to/iamahsanmehmood) · [Medium](https://medium.com/@iamahsanmehmood)*

---