A cross-platform, multi-process input method framework built around Clean Architecture.
Scriptorium is an experimental next-generation Input Method Editor (IME) framework that treats software architecture as a first-class concern.
Instead of implementing an IME as a single platform-specific DLL, Scriptorium decomposes the system into independent architectural units that communicate through well-defined protocols.
Its primary goals are:
- Crash Isolation — Prevent IME failures from crashing host applications.
- Cross-Platform Core — Keep business logic independent of operating systems.
- Modular Architecture — Separate responsibilities into independent projects.
- Stateless UI — Decouple rendering from business state.
- Replaceable Infrastructure — Allow UI frameworks, IPC implementations, and platform adapters to evolve independently.
Although the current implementation targets Windows TSF, the architecture is intentionally designed for future multi-platform support.
The architecture presented in this README is the result of multiple redesigns rather than a single upfront design.
From a monolithic in-process TSF DLL to today's multi-process architecture, every major refactoring was introduced to solve a real architectural problem—not simply to adopt a particular design pattern.
Each milestone is documented with its corresponding architecture diagram and the reasoning behind every design decision.
👉 Read the complete story: Architecture Evolution
The names of the four repositories are inspired by traditional writing tools.
Together, they reflect the role each architectural unit plays within the Scriptorium ecosystem.
| Repository | Role | Metaphor |
|---|---|---|
| scriptorium-brush | Windows TSF client | A brush is the only tool that directly touches the paper, just as Brush is the only component that directly interacts with the operating system. |
| scriptorium-inkstone | Stateful IME core | An inkstone prepares the ink before writing, just as Inkstone prepares every composition before it reaches the user. It symbolizes the heart of the writing process, where everything begins. |
| scriptorium-ink | Stateless UI renderer | Ink is the visible result of writing. It represents the presentation layer—the part users ultimately see. |
| scriptorium-felt | Shared foundation library | Felt quietly provides a stable foundation beneath the writing process. Likewise, Scriptorium-Felt serves as the shared foundation upon which the entire ecosystem is built. |
The current Scriptorium ecosystem consists of four independent architectural units.
Windows TSF Client
Runs inside the host application and serves as the bridge between Windows TSF and the IME core.
Responsibilities:
- Capture native TSF events
- Forward requests to the IME core
- Commit text back to applications
Brush intentionally contains no business logic, no dictionaries, and no UI.
Stateful IME Core
The heart of the system.
Inkstone owns all application state and is responsible for:
- Input processing
- Candidate generation
- Dictionaries
- Tokenization
- Business rules
- Application services
Stateless UI Renderer
Ink is responsible only for presentation.
It renders UI based on data received from Inkstone and reports user interactions back to the core.
Core ─────────► UI
RenderState
Core ◄───────── UI
UserAction
This architecture allows different rendering implementations (WinUI, Tauri, ImGui, Web, native UI, etc.) without affecting business logic.
Shared Foundation Library
Unlike the other projects, Felt is not a Clean Architecture module.
Instead, it provides reusable infrastructure shared across the ecosystem, including:
- IPC abstractions
- Protocol definitions
- Logging
- Shared utilities
- Common services
It acts as the common foundation upon which the other architectural units are built.
Scriptorium is built around four architectural principles.
Business rules remain independent of frameworks, operating systems, UI technologies, and IPC implementations.
Critical components are isolated into separate processes to improve stability, debugging, and maintainability.
Rendering is separated from business state, allowing UI implementations to evolve independently.
Dependencies always point inward.
Outer layers depend on inner layers.
Inner layers never depend on implementation details.
Scriptorium is more than an IME implementation.
Its long-term vision is to become a reusable framework for building modern input methods across different operating systems.
Beyond cross-platform support, Scriptorium aims to provide a stable, long-lived foundation for an extensible plugin ecosystem. By maintaining clear architectural boundaries and a stable C ABI, new dictionaries, input methods, language models, UI renderers, and platform integrations can evolve independently without requiring changes to the core framework.
Ultimately, Scriptorium aspires to become an input method platform rather than a single IME implementation—one that prioritizes long-term evolvability, modularity, and ecosystem growth while demonstrating that system software can benefit from the same architectural principles commonly applied to backend services.
Good architecture is not created in a single design session—it evolves through continuous refinement.
Copyright © 2026 ScriptoriumLab.
