Need help with Luxor.jl?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

JuliaGraphics
281 Stars 40 Forks Other 824 Commits 3 Opened issues

Description

Simple drawings using vector graphics; Cairo "for tourists!"

Services available

!
?

Need anything else?

Contributors list

splash image

| Documentation | Build Status | Code Coverage | |:---------------------------------------:|:-----------------------------------------:|:-------------------------------:| | | Build Status | | | | Build Status | |

Luxor

Luxor is a Julia package for drawing simple static vector graphics. It provides basic drawing functions and utilities for working with simple 2D graphics. Think of it as a high-level easier to use interface to Cairo.jl, with shorter names, fewer underscores, default contexts, and simplified functions. In Luxor, the emphasis is on simplicity and ease of use.

"luxor gallery"

Luxor is thoroughly procedural and static: your code issues a sequence of simple graphics 'commands' until you've completed a drawing, then the results are saved into a PDF, PNG, SVG, or EPS file.

A short tutorial can be found in the documentation. There are some Luxor-related videos on YouTube, and some Luxor-related blog posts at cormullion.github.io/.

Luxor is designed primarily for drawing static 2D images. If you want to build animations, use Javis.jl.

Luxor isn't interactive: for building interactivity, look at Gtk.jl, GLVisualize, Makie, and Pluto.jl.

How can you contribute?

If you know any geometry you probably know more than me, so there are plenty of improvements to algorithms waiting to be made. There are some TODO comments sprinkled through the code, but plenty more opportunities for improvement.

Update the code, most of which was written for Julia versions 0.2, v0.3 and 0.4 (remember when broadcasting wasn't a thing?) so there are probably many areas where the code could take more advantage of version 1.

There can always be more tests, as the present tests are mainly visual, showing that something works, but there should be much more testing of things that shouldn't work - inappropriate input, overlapping polygons, coincident or collinear points, anticlockwise polygons, etc.

More systematic error-handling particularly of geometry errors would be a good idea, rather than sprinkling

throw(error())
s around when things look wrong.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.