Frequently Asked Questions
Relevant source files
The following files were used as context for generating this wiki page:
This page provides answers to common questions regarding the OpenHWP project, its architecture, development workflow, and technical requirements. OpenHWP is an open-source HWP/HWPX desktop application designed to run on macOS, Windows, and Linux without requiring Hancom Office.
The project is currently in its early development stages, focusing on a thin desktop shell architecture that leverages Deno and the rhwp engine for document processing.
Project Architecture & Tech Stack
What is the core technology behind OpenHWP?
OpenHWP is built using the Deno desktop runtime. It separates the document processing logic from the desktop interface by using rhwp (a Rust and WebAssembly-based engine) for parsing and rendering HWP/HWPX files. The desktop shell is a native window using a Chromium-based (CEF) webview to display the application.
Sources: README.en.md:5-13, README.md:5-13
How does the document engine work?
The project utilizes two primary NPM packages from the rhwp ecosystem:
@rhwp/core: A WASM-based parser and renderer used for viewing documents.@rhwp/editor: A full editor UI designed to be embedded via an iframe.
Sources: README.en.md:21-36, README.md:23-38
Why is the CEF backend used?
Setting the backend to cef (Chromium Embedded Framework) in deno.json ensures that rendering remains identical across different operating systems and allows the application to utilize modern web APIs like the File System Access API.
Sources: README.en.md:15-20, README.md:16-21
Application Component Diagram
The following diagram illustrates the relationship between the Deno desktop shell, the rendering backend, and the document engine.
The application maintains a thin shell and delegates document-specific tasks to specialized WASM engines.
Sources: README.en.md:11-20, README.md:12-21
Development & Contribution
What are the prerequisites for building OpenHWP?
You must have Deno version 2.9.0 or later installed, as deno desktop functionality was introduced in that version. No other toolchains like Node.js, Bun, or Mise are required.
Sources: CONTRIBUTING.md:13-16, README.en.md:50-51
How do I run the project locally?
Currently, the repository contains the project scaffold. Once implementation begins, the following commands are used:
| Command | Action |
|---|---|
deno task dev | Starts the application in development mode. |
deno lint | Runs the Deno linter. |
deno fmt --check | Checks code formatting. |
deno test | Executes the test suite. |
deno desktop main.ts --backend cef | Builds a standalone binary. |
Sources: CONTRIBUTING.md:18-30, README.en.md:53-62
What is the contribution workflow?
OpenHWP uses a specific process for external contributions:
- Initiation: Start with an Issue or Discussion rather than a direct Pull Request.
- Approval: If a maintainer approves the proposal, they create an approval PR.
- Submission: Only after the approval PR is merged should you submit your code changes.
- Standards: Use Conventional Commits and ensure all documentation and comments are in English.
Sources: CONTRIBUTING.md:7-10, CONTRIBUTING.md:32-52
File Handling & Security
How are files opened and saved?
OpenHWP uses the web-standard File System Access API. This allows the app to open .hwp and .hwpx files directly from the browser context without needing a separate native file picker in the Deno backend.
The use of secure context (localhost) and Chromium enables direct disk access via standard APIs.
Sources: README.en.md:38-48, README.md:40-50
How should security vulnerabilities be reported?
Security vulnerabilities should never be reported via public issues. Instead:
- Use the Security tab on GitHub and click "Report a vulnerability".
- Alternatively, email security@pleaseai.dev.
- Expect an acknowledgment within 72 hours.
Sources: SECURITY.md:14-25, CONTRIBUTING.md:65-66
Summary
OpenHWP aims to provide a lightweight, cross-platform alternative for handling HWP/HWPX documents. By combining the Deno desktop runtime with Rust-based WASM engines, the project achieves a high degree of platform independence. As it is in early development, contributors are encouraged to follow the established workflow and keep an eye on the roadmap for upcoming viewer and editor features.
Sources: README.en.md:64-70, README.md:66-72