Veusz: a scientific plotting package that builds graphs out of widgets

A graph is a tree of widgets, and the document is the file

Veusz is a scientific plotting package, designed to produce publication-ready PDF or SVG output. Graphs are built up by combining plotting widgets, and the user interface aims to be simple, consistent, and powerful.

The widget model is the design decision that distinguishes it from a plotting library. A chart in Veusz is not a call to a function, it is a document containing a tree of widgets, where each widget is a plot, an axis, a label, a key, a shape, a dataset, and the arrangement is itself a widget that holds others. That structure is why the document format exists and why the file extension for a saved figure is its own, seen in the examples directory as `.vsz` files alongside the `.csv` data they use.

It also explains the feature list. Nested plots and arrays of plots are natural, because a plot widget can contain other plot widgets. Plot keys and plot labels are widgets, so they can be positioned by the same layout mechanism. Shapes and arrows on plots are widgets too, which means they are not a special case bolted onto the renderer. And multiple axes, broken axes with steps in the axis scale, and axis scales using functional forms all fall out of a design where the axis is an object with properties rather than a parameter to a chart call.

The output target is what makes the widget approach worthwhile. Publication-ready PDF or SVG means the figure has to be vector, with text set as text rather than traced, which is where a renderer that composes objects beats one that rasterises. The export formats listed are PDF, EPS, PNG, SVG, and EMF, and the 3D plots, points, surfaces, functions, and volumetric plots, are the same widget idea applied to a third dimension.

The project is at veusz.github.io, the primary language is Python, and the licence is GPL version 2 or greater, copyright Jeremy Sanders and contributors from 2003 to 2025. The newest release is Veusz 4.2.1 from April 2026, and the last push was on 2026-08-22.

Six ways in, and the data formats it reads

The interfaces are listed as GUI, Python module, command line, scripting, DBUS, and SAMP, and that list is worth reading in order because the middle entries are where the automation story lives.

The GUI is the main way most people use it, and the feature list includes an interactive tutorial, a data picker, and multithreaded rendering. The Python module is the way you embed it, and the plugin interface explicitly allows you to embed Veusz within other programs. The command line is for running a saved document, and the scripting interface is for driving the application itself from a script, which is a different thing from importing it as a module.

DBUS and SAMP are the two that are less common and more interesting. DBUS gives a desktop application a way to be scripted by other desktop applications, and SAMP is the astronomy interoperability protocol for applications to exchange data and commands. Veusz using SAMP is a direct signal about the audience, because SAMP is the messaging standard the astronomy community adopted for exactly this, letting a plotting tool be driven from a data analysis tool running elsewhere.

The input side is the other half. Data can be captured from external sources such as Internet sockets or other programs, so the tool can take a live feed rather than only a file. The import formats are text, HDF5, CSV, FITS, NPY and NPZ, QDP, binary, and user plugins. FITS and HDF5 are the astronomy and scientific formats, NPY and NPZ are the NumPy formats. The `astropy` dependency in the requirements file is what brings the FITS support, and `h5py` brings HDF5.

The output side is PDF, EPS, PNG, SVG, and EMF export, and the document itself can be manipulated and edited, including by plugin, which means a script can rewrite an existing figure rather than rebuild it from scratch.

The requirements file is short and telling: numpy 1.20 or newer, PyQt6 6.3.0 or newer, sip 6.5.0 or newer, astropy 2.0 or newer, and h5py 2.6.0 or newer. sip is the tool that compiles the C++ extension modules, which is the reason the build is not a pure Python install.

Plugin points for data, datasets, and the document itself

The extending section lists four ways in, and the fourth is the one that makes this a tool rather than an application.

You can use it as a Python module. You can define user functions and constants, and import external Python functions, so a plot can call your own code. There is a plugin interface to allow the user to write or load code to import data using new formats, to make new datasets optionally linked to existing datasets, and to arbitrarily manipulate the document. And there is the scripting interface, with the DBUS and SAMP control on top of that.

The dataset plugin point is the interesting one, because it changes what the document can express. A dataset in Veusz can be linked to an existing dataset, which means a derived quantity stays in sync with its source rather than being a snapshot. If a plugin makes a dataset that depends on another, editing the source updates the derived value, and the document remains the single description of the figure. For a figure that gets regenerated each week from new data, that is a large simplification over a script that reconstructs every element.

The document manipulation plugin point is the most powerful, and also the one with the least guard-rail, since it can change anything in the document tree. For a team that wants to generate figures from a pipeline, that is the useful part, and it is also the part where an error produces a broken figure rather than an error message.

The user functions point is what connects the plotting to an analysis. A function defined in Python can be used as an axis scale or as a plotted function of a dataset, and the function axis scales listed under the plotting features are the built-in case of that. With the function plotting features and the function axis scales, the general case is a user function, so a model that is not a simple polynomial can be plotted directly.

The examples directory makes the document format concrete, with files like `custom_definitions.vsz` and `dataset_operations.vsz` sitting next to the CSV and DAT data they load, and `2d_irregular.vsz` next to `2d_irregular.csv`. A `.vsz` file is a saved Veusz document, and shipping a pair of a document and its data is how the project distributes worked examples.

The packaging compiles SIP modules, which is why pip needs a build toolchain

The build configuration is where a first-time installer's friction comes from, and it is worth understanding before you start.

The pyproject.toml declares the build requirements as setuptools 61 or newer, wheel, numpy, sip, and PyQt6, with the setuptools backend. So a pip install of Veusz builds the package and needs all of those present at build time, and in particular needs sip and PyQt6, because the package ships compiled extension modules rather than pure Python.

The setup.py confirms the mechanism in more detail. It imports numpy at the top, and it uses a custom `install_data` command pulled in from `install_data.py` to tell Veusz where to install its data files, with a `veusz-resource-dir` option to override the resource directory location and a `disable-install-examples` option. The comment in the file explains why that custom command exists, since setuptools removed the data-files support that the old distutils had. The build also uses a custom `sip_build_ext` command from `pyqt_setuptools.py` to build the SIP and PyQt modules.

The SIP part is the key. SIP is the tool that generates Python bindings for C++ libraries, and Veusz uses it for its own performance-critical parts, the rendering engine and the data handling, where pure Python would be too slow for the volumes of points a scientific plot involves. That is a deliberate trade, and it is why the requirements list is short but the build is not trivial.

The repository layout reflects the split between the Python code and the compiled parts. There is `src/`, `veusz/`, and `ui/`, which suggests the widget implementations and the user interface code are separate from the module sources, and `pyqt_setuptools.py` and `install_data.py` at the root are the packaging machinery. There is a `run_veusz_inplace` script, which is the way to run the application from a source checkout without installing it, and an `examples/` directory that ships with the distribution.

The `requirements.txt` pins the runtime floors, and the 4.2 release notes mention preferring tomllib on Python 3.11 and up, which is a small sign that the project tracks current Python versions.

The release notes read like a working document

The change list for the two recent releases is a useful sample of how the project is maintained, because it shows the mix of work.

For 4.2.1 the changes are: change tutorial highlight color to magenta, fix missing icon in tutorial, move data settings to top in fit widget, fix silent uninstallation, fix wrong size output PDF on MacOS, and update to qt-6.10.2 in binary builds.

For 4.2 they are: fix for double scaled 3D point marker borders, allow negative offsets for some labels, allow iterative change of properties of multiple widgets, strip BOMs from Veusz and imported files, fix binary import plugin, fix capture dialog, prefer tomllib on Python 3.11 or newer, clean up text for translation and document use of weblate in the README, fix inactive 2D data import range, and update GPL address.

Several of those are the kind of change that tells you the software has a large user base with specific needs. The wrong size output PDF on MacOS is a bug that only appears on one platform, and it matters because PDF is the publication target. The silent uninstallation fix is the kind of thing that only matters for people installing from a package manager. The double scaled 3D point marker borders is the kind of detail that separates a plotting tool used for papers from one used for a slide.

And the ones about process are worth noting. Update GPL address, clean up text for translation and document use of weblate, and the translation directory in the tree with a README note that translations are welcome to be made using Weblate. A project that has been running the same translation platform for years has a large existing translation set, and the clean-up entry suggests the text was being worked on for the translators' benefit.

The 4.2.1 list also shows the binary builds shipping a specific Qt version, qt-6.10.2, which is how a PyQt application keeps its binary distribution consistent with the Qt it was tested against. The licence is GPL version 2 or greater, and the copyright runs from 2003 to 2025, so this is a project with a long history and a single principal author.

Editorial conclusion

Veusz fits a researcher or instrument scientist who wants publication-quality vector output, needs to rebuild or update a figure from a script rather than by hand, and wants a document format that stores the figure itself. It is the wrong choice if you need the wider plotting ecosystem, and the wrong choice for exploratory work where a notebook is more productive. Check three things before you adopt it: that your Python is 3.11 or newer if you want the tomllib path, since the project prefers it on 3.11 and up, that the GPL version 2 or greater licence suits your distribution, and that the build works on your platform, since the package compiles SIP and PyQt6 modules and the binary builds ship a specific Qt version.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. veusz/veusz on GitHub