open-pdf-studio: a PDF editor built for drawings and take-offs

An editor aimed at drawings rather than at forms

Open PDF Studio presents itself as a lightweight native desktop application for Windows, macOS, Linux and Android, built with Tauri 2 and web technologies, with a Microsoft Office style ribbon interface. The interesting part is the audience it names: people who work with drawings. The README describes importing DWG and DXF as a vector PDF with layers and a measuring scale, measuring and taking off quantities, exporting a page back to CAD, verifying digital signatures, making scans searchable with OCR, and letting an AI assistant operate the app through a local connection. That is a specific professional workflow, not the generic highlight-and-annotate feature list. The comparison table in the README makes the pitch in commercial terms, claiming that annotation, markup, measurement, DWG and DXF import and export, OCR, stamps, watermarks, redaction, page management and multi-tab editing are all included without subscription, telemetry or watermarks. Whatever the marketing framing, the feature inventory itself is what you would compare against a paid tool.

Six Rust crates under a Tauri shell

The Cargo.toml at the root defines a workspace of six members, and the names describe the architecture better than the README does:

[workspace]
resolver = "2"
members = [
  "open-pdf-studio/src-tauri",
  "open-pdf-render",
  "pdfium-worker",
  "open-pdf-cad",
  "open-pdf-cmyk",
  "open-pdf-thumbnails",
]

There is an application crate, a render engine, a worker that wraps the PDFium renderer, a CAD crate, a CMYK crate and a thumbnail crate. That split is what the README means by its own Rust engine: the PDF rasterisation and the drawing geometry live in Rust, separate from the SolidJS front end listed in the repository topics. The top level listing adds the surrounding infrastructure: mcp-server, mcp-stdio and mcpb directories for the model context protocol side, open-pdf-studio as the app itself, plus docs, tests, scripts, pocs, snap, flatpak, android-apk and packaging directories, and a flake.nix. The build profile section is unusual and worth knowing about, since it sets opt-level 3 for the render crate and for the hot dependencies such as tiny-skia, tiny-skia-path, lopdf, image and pdfium-render in development builds, because the engine is far slower in an unoptimised debug build. The workspace also patches tesseract-rs to a specific upstream commit to work around a cache directory that was not namespaced by target triple.

Measurement that depends on scale calibration

The measurement tools are the part that would decide an adoption for an AEC user, and they are described in concrete terms rather than as a feature name. Distance, area and perimeter measurement are supported, along with a scale calibration dialog offering mm, cm, m, inches, feet and points. The scale can be overridden per line with a fallback to the document scale, and there is a quick scale gesture where you right-click a dimension line and type a value such as "12.3m" to recalibrate. Dimension text and endpoints are draggable and recalculate live. Snapping covers endpoints, midpoints, centers and edges, and angles snap in configurable increments. That combination is what makes take-off plausible: a take-off depends on every dimension being right, and a document whose scale was never calibrated produces confident nonsense. The README shows a screenshot of a floor plan drawn with parametric walls whose corners trim themselves and where doors, windows and rooms snap into place, drawn to scale on a blank sheet.

DWG and DXF in, CAD out

The CAD side is import first and export second. A DWG or DXF file goes in through File > Import, through Open, or by drag and drop. On the way in you choose which layers to take, and whether to use model space or a layout, and for a layout you set the viewport, area, scale, paper, orientation, margins and placement. Appearance options follow, covering colours as in the file, all black, greyscale, black and white, or a single colour. The output side is described as exporting a page back to CAD. The README lists DWG and DXF import and export as included, in contrast to commercial editors where such support is rare or sold as a separate product, which is a reasonable claim about the competitive field for AEC tooling. The repository also carries a CAD crate of its own, open-pdf-cad, alongside the render engine, which is consistent with a native geometry implementation rather than a wrapper around a third-party converter. The README does not state which DWG and DXF versions are supported, and for a format with a long history of revisions that gap matters.

A local MCP connection instead of a cloud service

The README describes letting an AI assistant operate the app through a local connection, and the comparison table contrasts that with a cloud service, if any. The repository backs that up structurally with three separate directories, mcp-server, mcp-stdio and mcpb, which suggest a server component, a standard input and output transport for local process integration, and a bundle format. This is the part of the project with the sharpest operational consequences, because an assistant that operates an editor can do things a human assistant would not: it can open files, change markup, and save. The README does not document what permissions that assistant has, whether every action is confirmed, or what an audit trail looks like, and it says nothing about which models or agents it has been exercised with. Other editor features are more conventional. Signatures can be drawn with multiple strokes and up to five can be saved for reuse, redaction marks areas and applies to permanently remove content, ten built-in stamps cover states such as Approved, Rejected, Draft, Confidential and Final, and images can be inserted from file, pasted from the clipboard or dragged in, with non-destructive cropping.

The licence badge and the licence field disagree

The README carries a badge that reads LGPL-3.0, and the comparison table lists the price as free and open source under LGPL-3.0. The licence field on the repository, however, says it is a custom licence that GitHub cannot classify and points to the LICENSE file. Those two statements are not the same claim, and the discrepancy is the first thing to resolve before an organisation builds a process on top of the tool, because LGPL obligations attach to linking and redistribution while a custom licence can say anything at all. The repository root holds LICENSE.md, CONTRIBUTING.md and CLAUDE.md, and the README says nothing about which of the two is authoritative. On packaging, the tree contains snap, flatpak, packaging and android-apk directories alongside a Snap Store badge, so desktop and mobile builds are handled by the project rather than by community packagers. The release cadence is fast: v2026.43.0 was published on 2026-10-20 with v2026.42.13 and v2026.42.12 the day before, and older release notes for v1.47.5 and v1.47.13 remain in the repository root, so the version scheme itself has changed recently.

Editorial conclusion

Open PDF Studio fits a construction, architecture or AEC team that annotates and measures drawing PDFs on the desktop and wants an offline editor with no subscription, and it fits an engineer who wants to drive a PDF tool through a local MCP server rather than a cloud API. It does not fit a team that needs a headless PDF service, and it does not fit anyone who cannot accept a licence that GitHub cannot classify. Verify first what LICENSE.md actually grants, since the licence field on the repository says it is a custom licence while the README badge advertises LGPL-3.0, then check that the DWG and DXF import path handles your own files. The last push was on 2026-10-20, the same day as release v2026.43.0.

Frequently asked questions

Official sources

1. Issues
2. OpenAEC-Foundation/open-pdf-studio on GitHub
3. README
4. Releases