Should you use HOP?
HOP is a candidate for viewing and light HWP editing when you can inspect the resulting documents before relying on them. Its README lists HWP/HWPX opening, HWP saving, PDF export and printing. HWPX saving remains disabled in the supplied development guide. That boundary matters more than whether dependency installation succeeds.
The same guide says autosave/recovery is absent. Work on copies, retain the originals and test the complete task you need: open a representative document, edit it, save it, reopen it in the receiving application, then inspect its PDF and printed output if those are part of the workflow. These are recommended acceptance checks, not tasks we completed.
What our sandbox established
Our run was recorded on October 9, 2026, at commit 80888af (full SHA 80888af2b8c8a18aea16f824d2d92309a290b1ad). Installation succeeded in the supplied lab-node:22 sandbox. Our sandbox test command exited 101 after 73 seconds.
The raw failure identifies the prerequisite: pkg-config could not locate gdk-3.0, required by the Rust crate gdk-sys. Cargo was present and reached native compilation. The log therefore does not support diagnosing this run as a missing-Cargo failure or a Rust test assertion failure.
The attached stored parser summary records 159 passed, zero failed and zero skipped tests. These parser totals do not establish exhaustive, unique test coverage or a successful overall command. The raw Vitest footer separately reports 22 passing test files and 159 passing tests; other named checks also appear in the tail. We have not added those checks to the stored total or reconciled complete logs.
Our harness records command success, exit codes, elapsed time and parsed test counts separately. That separation explains how passing test output can accompany an unsuccessful command. The MrKeyoor testing methodology explains this reporting approach and its limits. Its supplied October 31 snapshot provides provenance context, not evidence that the October 9 run used a later procedure.
The generic build step was skipped because the harness found no matching script, although named build commands exist. We did not launch the desktop application, exercise document editing, verify PDF search, print documents, test installers or establish compatibility across operating systems. No new execution was performed for this correction. The attached audit value is null, so audit results and scanned-package coverage are unknown.
Installation depends on the operating system
The README provides macOS, Windows and Linux downloads. It describes macOS DMGs as signed and notarized, while warning that Windows builds are unsigned and may trigger download or execution warnings. These are project statements, not installer checks from our sandbox.
For Linux, the README recommends distribution-native packages for Korean IME and WebKitGTK stability. It reserves AppImage for portable use and warns that some Wayland/IME combinations can have unstable input switching or window display. Check the package on the actual desktop environment you intend to support.
The supplied development guide still describes signing and notarization as future work, which conflicts with the README's macOS statement. Use the exact release artifact as the subject of deployment verification rather than treating both documents as consistent proof.
HOP, rhwp and LibreOffice solve different problems
rhwp provides the document engine and web editor beneath HOP. Its own README also documents embedding packages and a CLI. Consider rhwp directly when building document handling into another application; it is an upstream component and a possible complement to HOP, rather than an equivalent desktop replacement. Its current capabilities do not establish what HOP's pinned integration exposes.
LibreOffice is an open-source integrated office suite. Consider it when the decision concerns a broader office suite. The supplied LibreOffice extract does not establish HWP/HWPX import, saving or round-trip fidelity, so it cannot justify recommending LibreOffice as a verified replacement for HOP's Hangul workflow.
How to read the ratings
The assessed ratings use a 1-5 editorial rubric: 1 means substantial evidenced barriers, 2 means major limitations, 3 means usable with material caveats, 4 means strong supporting evidence with few caveats, and 5 requires comprehensive supporting evidence. They are judgments about the stated dimension, not benchmarks or compatibility guarantees. A dimension without enough evidence is unassessed.
Setup receives 3 because dependency installation succeeded but native testing required an unavailable system library. Documentation receives 3 because the supplied Korean guides give concrete setup and architecture information but disagree about signing status. Maturity receives 2 because HWPX saving and recovery remain unavailable in the supplied guide, and our run did not validate the desktop workflow. Community is unassessed because the supplied primary extracts do not establish current response times, contributor activity or support reliability.
The supplied v0.4.1 release page identifies desktop installers at release commit 608d54b. Our measured commit was 80888af; this review does not present that later source run as a test of the v0.4.1 installers.