Asymptote, the vector graphics language written for technical figures

A drawing language for people who already typeset

Asymptote describes itself as a descriptive vector graphics language for technical drawing, inspired by MetaPost but with an improved C++-like syntax. The word descriptive is the important one. Instead of pointing at a canvas and dragging handles, a figure is written as a program that describes geometry, and the program is what you edit, re-run and version.

The project states the goal plainly: figures get the same level of typesetting quality that LaTeX gives scientific text. That is a comparison to a specific workflow, not to graphics editors. LaTeX users already expect to compose a document, compile it, and get predictable output; Asymptote aims to slot into that habit, where a figure source file is compiled alongside the text that references it.

The description on the repository calls it a 2D and 3D TeX-aware vector graphics language, and the primary language of the implementation is C++. Both facts matter for adoption: the language is intentionally close in feel to MetaPost and to C++, and the tool itself is a compiled program rather than a scripting layer on top of a graphics library.

The source tree separates parsing from processing

The top-level directory listing gives a good picture of how the program is organised, because the file names are descriptive rather than generic.

There is a parser cluster: absyn.cc, absyn.h, asyparser.cc, asyparser.h and access.cc sit near the top of the tree, which is the shape you would expect for a front end that builds a syntax tree from an .asy file. The header asyparser.h and the implementation asyparser.cc sit alongside the abstract syntax layer, and asyprocess.cc and asyprocess.h hold the stage that turns a parsed program into output.

Two support pieces sit at the top level as well: asy-list.py is a Python helper, and the repository carries tool-specific configuration in .isort.cfg and .pylintrc, which suggests the Python side is linted as part of the project rather than treated as an afterthought.

The repository also holds its own working notes in files named BUGS and TODO. For an adopter, that is a mild signal about how the project surfaces known problems: they are visible in the repository rather than hidden in a tracker.

Geometry, rendering and file format code share the tree

Alongside the parsing files, the top level contains what look like the computational and rendering layers.

Delaunay.cc and Delaunay.h are present as standalone units, which is a concrete sign that the language handles mesh generation rather than only stroking paths. The curve and surface family is spelled out in the file names: beziercurve.cc and bezierpatch.cc, and the examples directory contains matching .asy files named BezierPatch.asy, BezierTriangle.asy and BezierSaddle.asy.

For raster and hardware paths there are GLTextures.cc and GLTextures.h, EXRFiles.cc and EXRFiles.h, and the tree includes an abs3doutfile.h header, plus a base/ directory that the listing shows as a shared foundation. A VulkanMemoryAllocator/ directory and a LspCpp/ directory sit in the tree as well, and the third-party list in the README names GLEW and TinyEXR among the bundled components, which lines up with those file names.

None of this tells you how the renderer is configured at run time, and the README does not document command line options beyond the licence printing switch. What the listing does tell you is the shape of the thing: a parser, a geometry library, a graphics layer with both legacy and newer back ends, and a package format for images.

Building from source means choosing a build system

The repository carries several build paths, which is normal for a program that has to build on Unix-like systems and on Windows.

At the root there is CMakeLists.txt and CMakePresets.json, which give the CMake route including configured presets. Alongside them sit Makefile.in and autogen.sh, the autoconf and automake route. A spec file named asymptote.spec exists for packaging on RPM-based systems.

Windows has its own documentation files, INSTALL-WIN.md and INSTALL-VCPKG.md, the second pointing at the vcpkg package manager. A .devcontainer/ directory is included, so a container-based development environment is available. Code style is pinned by .clang-format, and the tree also contains .gdbinit for the debugger.

The README itself does not spell out a build procedure, it points to asymptote.sourceforge.io for installation instructions. So for a source build you are expected to follow the INSTALL documents in the repository, and you need to decide between the CMake and autotools routes before you start. The presence of both suggests the two are supported, but the README does not say which one is preferred.

Licensing splits between the source and the Windows executable

The licensing story needs reading twice, because the source and the binary are not under the same terms.

All source files in the project, unless explicitly noted otherwise, are released under version 3 or later of the GNU Lesser General Public License. The tree contains both LICENSE and LICENSE.LESSER, and the README points to those files for the full text. This is the standard LGPL arrangement, where a library can be used by software under other licences while modifications to the library itself remain under the LGPL.

The Windows executable is the exception. The README states that the Windows build available on asymptote.sourceforge.io and on ctan.org can only be released under the GNU General Public License, because it ships with the GNU Scientific Library, the GNU Readline library and other GPL libraries. The README then lists where the sources for those components live, including fftw3, getopt, freeglut, gsl, libcurl, pthreadVC3, readline and zlib1, along with vulkan_lvp.dll.

Third-party components bundled into the project have their own terms. The README names span-lite, wyhash, Boehm GC, LspCpp, libatomic_ops, GLEW and TinyEXR, and points to LICENSES-THIRD-PARTY.md for the list. On an installed system the full texts can also be printed locally, by running the asy executable with the --licenses=full switch, which reads from the installed licenses/ directory. That answers the question on the machine you are on rather than sending you back to the repository.

Binaries, issue reporting and the forum are the front doors

The README keeps its pointers to three separate places, and they cover different needs.

Installation instructions, documentation, binaries and source code are all at asymptote.sourceforge.io. The ctan.org site is named as the second home for the Windows executable, which matters if you fetch it from a TeX distribution mirror rather than the project site.

Bugs, patches and feature requests go to the GitHub issue tracker for vectorgraphics/asymptote. That is the only place the README names for reporting problems, and it means an issue is the right channel for a reproducible drawing that fails to compile.

Questions and comments go instead to the Asymptote Forum on SourceForge. The split is deliberate in the README's wording: questions to the forum, defects to the tracker. A consequence for adopters is that usage questions do not produce searchable answers in the same place as the source code, so the forum archive becomes part of the practical documentation.

The examples directory is the shortest route to the language

For someone deciding whether Asymptote fits, the examples folder answers more than the README does. It ships ready made .asy files, and the names describe the feature each one exercises.

There are algebraic and geometric fixtures such as Pythagoras.asy, PythagoreanTree.asy, Klein.asy and Viviani.asy, alongside a plain algebra plot named 1overx.asy. Curve and surface coverage includes NURBScurve.asy, NURBSsphere.asy, NURBSsurface.asy, BezierPatch.asy, BezierSaddle.asy and BezierTriangle.asy. Fractals appear as Sierpinski.asy, SierpinskiGasket.asy and SierpinskiSponge.asy, and shading as Gouraud.asy and Gouraudcontour.asy. Surface work is covered by RiemannSphere.asy, RiemannSurface.asy and RiemannSurfaceRoot.asy, and there is a physics file named advection.asy.

Two files in the same folder are not Asymptote sources: 100d.pdb1 and 100d.views look like molecular structure data and a view configuration, so the examples cover reading external data rather than only closed-form geometry.

For an adopter, that list is a good fit test. If your figures involve surfaces, NURBS, fractals or imported molecular data, Asymptote has worked examples in the repository you can compile and read. If your figures are charts and layout diagrams, nothing in these names suggests that path.

Editorial conclusion

Asymptote suits people who publish technical figures and want the drawing to be code: students, textbook authors, and anyone who already lives in a TeX workflow. It does not suit someone who needs a point-and-click editor or a raster output, since the README describes no interactive authoring tool and the output path is vector oriented. Before adopting it, check that a prebuilt binary matches your platform on asymptote.sourceforge.io, and read the licensing split, because the Windows executable is GPL while the source is LGPL version 3 or later.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. vectorgraphics/asymptote on GitHub