Core2D: a data driven 2D diagram editor with a scripting escape hatch

Data bound to shapes is the model, not a feature

Core2D is a multi-platform application for making data driven 2D diagrams, and the phrase carries the design.

The application has a built-in vector graphics editor where you can bind data to shapes, share data across multiple documents, and edit documents using layers. It supports exporting documents to many popular file formats like PDF, bitmaps and DXF, and you can automate drawing and processing by using C# scripting.

So this is not a drawing program with a spreadsheet import. The document model is a tree of shapes, and shapes can be bound to data, and one data source can be shared across several documents. That is a different thing from a diagram tool, and it is the thing that makes it useful for technical drawings, where a rectangle represents a value and the rectangle has to move and resize when the value changes.

The layers feature is the other structural element worth naming. Editing documents using layers means the document is composed of stacked layers rather than one flat pile of shapes, which is what makes a shared or generated drawing tractable, since a background, a diagram layer and an annotation layer can be managed separately.

And the export formats place it precisely. PDF, bitmaps and DXF are the three you actually need to hand a drawing to something else: PDF for a document, bitmaps for a raster, and DXF for a CAD or manufacturing workflow. A diagram editor whose output cannot go back into a CAD tool is a slide tool.

The C# scripting is what turns it from an application into a tool you can drive, and it is the same scripting surface that the headless mode uses, which is why the automation story is coherent rather than bolted on.

Avalonia, and what it buys you

The repository topics name avalonia and avaloniaui alongside c-sharp, xaml, graphics and multi-platform, and that combination is the key technical decision.

The topics list avalonia and xaml, and the supported platforms are Windows, Linux and macOS, so one C# and XAML codebase covers all three. The alternative for a diagram editor would be a platform specific stack, which for an application that has to render the same drawing identically on three operating systems is a maintenance problem that shows up as three bug trackers.

The topic list also includes wysiwyg-editor, shapes, diagram, gui, graphics and data, which is an honest description of what the application is.

The supported platforms are stated as Windows 7 SP1 or higher, Linux, and macOS. The Windows 7 baseline is old enough to be a deliberate choice, and it is the kind of constraint that matters in the enterprise space where diagram editors often end up.

The build layout is conventional.NET. There is a `Core2D.slnx` solution file, a `Directory.Build.props` and a `Directory.Packages.props` for central package version management, a `global.json` pinning the SDK, a `NuGet.Config`, and directories for `src/`, `tests/`, `samples/`, `tools/`, `docs/` and `external/`. The `external/` directory plus the presence of a `.gitmodules` file suggests some dependencies are vendored as submodules rather than taken as packages, which is common when a graphics or geometry library needs a specific revision.

The samples directory carries a project called BrowserTheme.Catalog, which is a hint about the shape of the samples: they are catalogues of theme resources rather than small demo apps, which fits a framework where the theming is a first class concept.

The project is developed using JetBrains Rider, and the licence is MIT.

The command line is where the headless story shows

The usage block in the documentation is a full option list, and it is worth reading as a description of what the application can be asked to do without a person at the keyboard.

The usage block itself is the reference:

Core2D:
  A multi-platform data driven 2D diagram editor.

Usage:
  Core2D [options]

The ordinary options come first. A theme can be set with `-t` to one of DefaultDark, DefaultLight, FluentDark or FluentLight. Scripts are loaded with `-s` and a project with `-p`, both as relative or absolute paths. There is a `--repl` option to run a scripting repl, which is a REPL for the C# scripting layer, so you can drive the editor interactively from a terminal without opening the window.

Then come the rendering backends, and the list is long because the application runs on three operating systems and in a headless container. `--useSkia` selects the Skia renderer, `--useGpu` enables GPU rendering and defaults to True, `--useDeferredRendering` and `--useWindowsUIComposition` also default to True, `--allowEglInitialization` defaults to True, and there are platform specific switches for `--useWgl` to use Windows GL, `--useDirectX11` to use the DirectX11 platform api, and `--useManagedSystemDialogs` for managed system dialogs.

And then the headless group, which is the part that changes what the application is for. There is `--useHeadless` to use headless, `--useHeadlessDrawing` for headless drawing, `--useHeadlessVnc` for headless vnc, and `--createHeadlessScreenshots` to create headless screenshots, with `--vncHost` and `--vncPort`, the port defaulting to 5901.

So there are three separate headless modes and they are not the same thing. Headless runs without a window. Headless drawing renders without presenting. Headless VNC runs the application on a machine with no display and exposes it over VNC so a person can still interact with it. The screenshot option then takes that further.

That combination is the answer to the question of how a desktop diagram editor gets into a CI pipeline or a server side rendering service. You can render documents to images on a build agent, and you can have a person drive the editor over VNC on a remote machine when they need to fix something by hand.

And the `--repl` and the scripting options mean the same document model is reachable from all three. A script and a CI job manipulate the same things.

What the export formats and the version history imply

Two things about the project are worth thinking about before you commit, and neither is visible in the feature list.

The first is the version history. The recent releases are 11.0.0-rc1.1 from 2023-06-10, 11.0.0-preview8 from 2023-05-14 and 11.0.0-preview1 from 2022-08-31, and the last push was on 2026-09-27. So the tagged releases stop in 2023 while the working tree is being touched in 2026.

That pattern usually means one of two things. Either the project is in a long stretch of prerelease work on a new major version, which fits the sequence of preview and release candidate tags, or the recent commits are maintenance and fixes without a new release being cut. The version scheme suggests the first, since a long run of preview tags ending in an rc is a major version being stabilised.

Either way, the practical advice is the same. If you pin a version, pin a release candidate deliberately and expect the API to move. If you build against the tip, expect to deal with the churn yourself.

The second is what the export formats say about the intended use. PDF, bitmaps and DXF are not the exports of a presentation tool, they are the exports of an engineering tool. DXF in particular is a CAD interchange format, and the fact that it is supported alongside PDF means the drawings are expected to end up in a mechanical or manufacturing context rather than in a slide deck.

That is consistent with the data binding model. A shape bound to a value, in a layer, exported to a format a CAD system reads, is a diagram that carries data from a system into a drawing that a person then works with. And the C# scripting layer is what makes the generation part of a pipeline rather than a manual step.

The project also has a wiki and a documentation directory, an `AGENTS.md` file in the root, and a `Core2D.slnx` solution file using the newer solution format. The presence of an agent instructions file in the repository is a small signal of a project that has adopted current tooling conventions.

Editorial conclusion

Core2D fits a team that produces technical drawings from structured data, because binding data to shapes and scripting the generation are the point rather than an add-on, and because the headless modes let the same drawing code run in a pipeline instead of a desktop session. Skip it if you need a general purpose vector illustration tool, since this is built around a document and data model rather than freehand drawing. Before you adopt it, read the command line options carefully, because the headless and VNC flags change the deployment shape substantially, and note the release state, with the last tagged release 11.0.0-rc1.1 from 2023 and the last push on 2026-09-27.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wieslawsoltes/Core2D on GitHub