JKQTPlotter: a self-contained Qt plotting framework with a LaTeX renderer inside

The dependency list stops at Qt

JKQTPlotter is described as an extensive C++ library for data visualisation, plotting and charting for Qt, version 5.0 or newer, tested with Qt up to 6.10. It is feature-rich but self-contained and only depends on the Qt framework.

That constraint is the design brief, and it is unusual for a plotting library. Most charting libraries for C++ either wrap a rendering engine, wrap a scripting language, or shell out to a tool. The only optional dependencies named in the readme are CImg and OpenCV, and they are optional rather than required, which means the core functionality, including the equation renderer, the datastore and the graph types, does not need them.

For a team already shipping a Qt desktop application, that is the whole value proposition. Adding charts to a Qt application does not mean adding a second rendering stack, a second event loop or a set of third party binaries, and the same code compiles against Qt 5 and Qt 6, which matters for applications that still have to support an older Qt on some platforms.

The project is licensed under the GNU Lesser General Public License 2.1 or above. For a charting library, that is a licence worth understanding rather than skipping: LGPL is designed so that a library can be used by proprietary applications, provided the library itself stays modifiable and the application does not statically embed it in a way that prevents relinking. That is a fact about the licence, and a legal review should confirm what it means for your distribution model.

JKQTMathText renders equations without a TeX installation

The feature that separates JKQTPlotter from a generic chart widget is the integrated LaTeX parser, JKQTMathText, described as a pure C++ implementation with no dependencies that renders mathematical equations in axis labels, ticks and elsewhere.

The problem it solves is real for a scientific plotting library. Axis labels in scientific plots are not plain text, they are equations with subscripts, superscripts, fractions and symbols, and the usual options are to typeset them with a TeX installation and ship the resulting images, or to approximate with a limited set of markup. A pure C++ renderer gives you real typeset mathematics in a live, interactive plot, with the text scaling and remaining crisp at any export resolution, and it costs no external process.

There is a second, related piece of mathematics in the library: an integrated mathematical function parser for parsed function plots, with an intelligent rendering algorithm, and line and scatter graphs that can be based on C or C++ functions instead of data series, with C++11 support. So the library covers both directions of the same idea, mathematics that comes in as a function, and mathematics that comes out as a label.

For a user, the practical effect is that the equations are part of the plot object model rather than an image you paste in, which means they survive zooming, export and restyling without being redrawn by hand.

The datastore is the data model, and it does statistics

Centralised data management is handled by an internal datastore called JKQTPDatastore, and the readme describes it in enough detail to tell you how it thinks about data.

Data is organised by columns, and the datastore can also represent image data in row-major form. A column can be reused in several graphs, which is the reason for having a datastore at all: in a plot with three graphs over the same x axis, you describe the x column once. Access goes through Qt's model view framework, so the data can be bound to a table view, and the datastore is complete with a GUI table view. Datasets can be external or internal, there is a C++ standard iterator interface over the columns, and there are export capabilities, for example to CSV and to SYLK.

The statistics library is part of the same package rather than an add-on, and it covers basic statistics, boxplots, histograms, kernel density estimates, regression analysis and polynomial fitting. That is an unusually generous set for a plotting library, and it explains why the graph list includes boxplots and violinplots as first class graph types rather than as examples built on top of a data series.

The examples directory backs this up. There is a `datastore/` example, and beside it `datastore_groupedstat/`, `datastore_iterators/`, `datastore_regression/`, `datastore_statistics/` and `datastore_statistics_2d/`, which is a good indication of how much of the library's surface is about data handling rather than drawing.

A long list of graph types, from scatter to candlesticks

The graph catalogue is long enough that it is better read as a list of use cases than of classes.

There are scatter plots and parametrized scatter plots such as bubble charts, line graphs, step graphs, impulses, and filled curves. Barcharts are supported, including stacked ones, and there is extensive support for different styles of error indicators, which matters for anyone plotting measurements rather than functions.

Then the domain specific ones. Statistical plots including boxplots and violinplots. A large variety of image plots, with different colour scale modes, RGBA plots, and overlays or masks, plus contour plots. Vector field graphs and quiver plots. Financial graphs, that is candlestick and OHLC. And geometric forms, lines, rectangles, polygons, circles and bezier curves, together with annotations such as labels, text and ranges.

Two design choices are worth pulling out of that list. The image and contour support means this is not only a statistical plotting library but a general scientific visualiser that can render a raster as an image plot with a colour map, and the geometric and annotation support means the library is usable for schematic and explanatory diagrams rather than only for measurement data.

Everything is added to a plot through the widget's graph model, and the readme links each family to its own documentation page, so the depth behind each entry is not visible from the summary but is documented.

Interaction, export, and graphs that stay in step

A plotting widget is only useful if the person using it can interrogate the data, and the feature list puts a lot of weight on interaction.

The readme lists extensive user interactions pre-programmed, including several zooming modes, selecting regions, custom context menus, and switching graph visibility. There is a highly customizable look and feel, and the widget supports the Qt layout system for graphs, which means it can be used inside a layout with splitters and docks rather than being a monolithic window. It also allows several graphs to be synchronised with each other, which is the feature that turns a set of plots into an analysis view: pan one and the others follow.

Export is handled the same way, with full print and export support for PDF and PNG among others, including a preview and parametrization out of the box. For a library embedded in a desktop application, being able to produce a print-ready PDF from a plot without a separate tool is worth a lot, and the parametrization is what makes it usable in a batch export rather than a manual save.

The combination of the model view datastore, the styling system and the export path is what makes this a framework rather than a plotting class. The cost is that the API surface is large, and the readme itself calls the library feature-rich, which is a polite way of saying you will be reading the documentation for a while.

CMake and qmake, with a documentation build in CI

The build story is the part of the repository that tells you how a project is run day to day.

There is a `CMakeLists.txt` at the root with a `cmake/` directory, a `qmake/` directory, and qmake project files at the root, including `JKQtPlotterAppveyorBuild.pro`, `JKQtPlotterBuildAllExamples.pro` and `JKQtPlotterBuildLibsOnly.pro`. The last two names are useful, because they show that building the library alone, building all the examples, or running the AppVeyor build are separate targets, which is what a library with a large example set needs.

The examples carry their own CMake integration, with an `examples/CMakeLists.txt`, and there are two integration examples whose names are the answer to the most common adoption question: `cmake_fetchcontent_example/` and `cmake_link_example/`, which is FetchContent versus linking against an installed library.

The documentation is built with Doxygen, driven by the `Doxyfile` at the root, and the CI badges show a Doxygen build and deploy workflow, a build and test workflow on master, a CodeQL analysis workflow, and an MSVC code analysis workflow. Running the static analysis on both GCC-style and MSVC toolchains is a sensible choice for a library that has to work on Qt 5 and Qt 6 across compilers.

The rest of the tree is `lib/`, `examples/`, `tests/`, `tools/`, `doc/` and `screenshots/`, which is a conventional C++ library layout with the documentation and the screenshots as first class directories rather than as an afterthought.

Where JKQTPlotter is the wrong tool

The boundaries are mostly about scope, and one of them is about versions.

The first is the platform. This is a Qt library. If your application is a web app, a Python notebook, a command line tool that produces SVG, or an application on a toolkit other than Qt, then nothing here applies, and the same need is served by a different category of library entirely. A C++ team that does not already use Qt is being asked to adopt a whole application framework to draw charts, and that is rarely the right trade.

The second is the version line, and it is the one to check first. The release history shows v5.0.0-beta1 published on 2025-11-30 and v5.0.0-beta2 on 2026-06-22, while the newest stable tag is v4.0.3, a bugfix release for the 4.0.0 branch, published on 2024-03-12. The last push to the repository was on 2026-09-23. So the current stable line is more than two years old and the 5.x line is still a beta. A production application that wants a stable tag is choosing the 4.0.3 branch, and a project that wants the current feature set is choosing a beta. Neither is wrong, but it is a decision, and the release notes are where you make it.

The third is the optional dependencies. CImg and OpenCV are listed as optional, and if your plotting needs image processing or computer vision features, those are additional dependencies to manage.

The fourth is the size of the API. The library is described as feature-rich, and the graph catalogue is long. A team that needs three line charts does not need boxplots, violinplots, contour plots, quiver plots, candlesticks and a LaTeX renderer, and the practical cost of adopting a large framework is reading it. The faster route is to start from one of the examples in the `examples/` directory rather than from the class reference.

Editorial conclusion

JKQTPlotter fits a C++ desktop team that already uses Qt and needs charts, image plots or scientific visualisation without pulling in a plotting dependency and its own dependency tree, and it fits anyone who needs LaTeX-style equations in axis labels without linking a TeX installation. It does not fit a web project, a Python notebook workflow, or a team that needs a maintained stable release, since the newest stable tag is v4.0.3 from 2024 and the 5.0.0 line is still in beta. Before you commit, read the v5.0.0 beta release notes, decide whether the beta or the 4.0.3 branch fits your Qt version, and check the LGPL-2.1 obligations against how you intend to link the library.

Frequently asked questions

Official sources

1. jkriege2/JKQtPlotter on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases