There are many ways that a pressure input can be used by a 2D drawing program.

Art programs often do quite complicated things with pressure, using it to vary opacity and scale and to pick a pen profile from a pressure-and-distance-varying sample. That’s too much for a simple board-work application: it’s too computationally complex, results in too-large files, and can be distracting for those close enough to see it and difficult for those farther back in the room to make out.

Most programs suited to board work use pressure to indicate the width of a stroke with clear edges. This allows much more fluid writing and drawing than a fixed-width stroke system while also being visually crisp, computationally simple, and highly compressible for later file export.

There are three models for pressure-based stroke width that I’ve seen: fixed-axis linear offset, stroke-aligned linear offset, and circular offset.

Fixed-axis linear offset simulates how western calligraphy works when using a flexible nib. It can look fancy and appealing with a skilled scribe, but lacks the desired legibility for board work.

Stroke-aligned linear offsets fill a line perpendicular to stroke direction at each point along the stroke, the width of which is dependent on stroke pressure. This technique is computationally simple and in theory can create an appealing filled stroke shape, but it’s very sensitive to the noise and jitter that come with most hand motions and digital stylus discretization because even small offsets of the pen can create arbitrary changes in the stroke direction, with a large visual impact on the resulting stroke. To counteract this jitter, applications often add a smoothing effect, sometimes marketed as the mass or inertia of the virtual pen; such smoothing can make slow, careful strokes render nicely but removes high-frequency details and makes rapid writing look garbled.

Circular offsets fill a circle at each point along the stroke, the radius of which is dependent on stroke pressure. This technique is robust against jitter, rendering attractive strokes even at high frequencies, but may be computationally more expensive than linear offsets.

My board work tools all use circular offsets; circular offsets are the subject of the rest of this post.

Pen data is delivered by the tablet through the operating system device drivers as a sequence of $(x, y, p)$

My first application created a pill shape between each pair of points: a circle at each point, both the same radius, connected by a rectangle the same width as the circles. This is legible and simple to implement, but has bumpy strokes when pressure varies and doesn’t zoom in very well.

My second application created a trapezoidal pill shape between each pair of points: a circle at each point with different radii connected by a trapezoid tangent to them both. This looks much smoother than the pill approach, at the expense of slightly more computation.

Both of those approaches connect sample points with straight strokes. But when I am writing quickly I might only have half a dozen total $(x,y,r)$

Enter the world of splines. Instead of connecting tablet-provided points with straight lines (with variable-width stroking) I connect them with smooth curves; in particular, cubic Bézier curves. There are many ways to pick the curves based on the sample points, but I am satisfied with the visual quality of picking the slope of the curve at point $i$ based on the angle between points $i-1$

Bézier curves are the workhorse of curve drawing on computers. They nicely mix computational efficiency, artist intuition, and numerical stability.

Bézier curves are a specific instance of Bernstein basis polynomials; I’ll not further distinguish the two here, referring to them as Bézier even in contexts where Bernstein might be more appropriate.

Each Bézier curve is specified with a sequence of control points. The curve touches the first and last control points and travels towards those in between in order while being smooth and not exiting the convex hull of the control points. The more control points there are, the less influence each one exerts over the curve, with influence being more limited for those in the middle then those near the ends. In the vast majority of cases, we use four control points, yielding a cubic Bézier curve⁴⁴ So called because the curve can be expressed as a cubic polynomial..

An important algorithm for Bézier curves is de Casteljau’s algorithm which can split a single Bézier curve into two Bézier curves at any point along the original. Given a $0 < t < 1$

If a single value on the curve is wanted, de Casteljau’s algorithm can provide it, but uses $n(n+1)$

An important property of Bézier curves is that their derivative (the rate at which their coordinates change) is also a Bézier curve, called the curve’s hodograph. The hodograph has one fewer control points than the original curve; if the control points of the original are labeled $𝐂_i$

Bézier curves are separable, in the sense that working with a Bézier curve with $(x,y,r)$

A Bézier polynomial can be squared by multiplying its control points by appropriate binomial coefficients; convolving the list of control points by itself; and dividing by appropriate binomial coefficients. For example, a cubic polynomial with control points $(a,b,c,d)$

The roots of a Bézier polynomial can be found by positioning its control points evenly along the $x$ axis between 0 and 1 (that arrangement is called an explicit Bézier curve). There are then several tools that can be used to find roots:

Interval narrowing

Because Bézier curves remain within the convex hull of their control points, finding where it crosses $y=0$

This will converge to the first and last root as quickly as Newton’s method⁵⁵ Newton’s method generally has quadratic convergence, unless the root it is finding has multiplicity greater than 1. Newton’s method can diverge if the starting guess is too far from the root; that kind of divergence cannot happen with Bézier interval narrowing.. It can also be used with just the minimum or just the maximum $x$ to find only one root.

Splitting

Bézier curves have a variation-diminishing property which means (among other things) that a Bézier polynomial can have no more roots than it’s control points have sign changes: if the control points switch signs only twice, (e.g. $(+, +, -, -, -, -, +)$

If the curve has more than 2 roots, de Casteljau’s algorithm can be used to split it into curves with ≤ 2 roots.

Deflating

If the first control point of a Bézier polynomial is 0, then a deflated polynomial removing that root but keeping any other roots can be defined with $n-1$

If the last control point of a Bézier polynomial is 0, then a deflated polynomial removing that root but keeping any other roots can be defined with $n-1$

Bézier curves are mathematical paths with extend but no width, which means that if we tried to draw them by coloring the pixels they touch then no pixels would be colored. To draw them visibly, we need to instead fill in the pixels that come within a certain distance of the curve. This is true of all Bézier curves, including those used in current graphics APIs, but arguably even more true when the radius of the stroke is a coordinate of the curve itself. The process of finding and drawing these pixels is called stroking the curve.

There are two basic approaches to stroking a curve.

One option is to find many points along both edges of the stroke, connecting them into a big polygon with vertices close enough together to appear smooth, then fill in the polygon. There are several efficient algorithms for rendering polygons, including polygons with thousands of vertices.

Another option is to check how far each pixel is from the curve and fill it if that distance is small enough to be part of the stroke. While objectively more work than the polygon approach, requiring significantly more arithmetic computations for all but the smallest curves, this approach is well suited to the highly-parallel SIMD implementations to run on GPUs.

I have occasionally seen a third approach proposed, a variant of the polygon option which uses Bézier curves instead of line segments to bound the stroke. Because these intermediate Bézier curves will themselves need to be rendered using one of the two approaches above, adding this intermediate step seem to be more of a convenience for implementers than an actual computational win.

Although the two approaches (polygonal bounds and pixel checking) are widely implemented for fixed-width strokes, I’ve not seen many implementations nor clear descriptions for variable-width strokes. The remainder of this post attempts to rectify that.

The basic approach for creating stroke outlines is to find a sequence of points on the curve and for each find the point on the left and right side of the curve that lies on the edge of the stroke. The left-side points thus found are chained together, then connected (possibly via some kind of end cap) to the right-side points in reverse order, and then connected (again with an end cap) back to the left-side points.

For a 2D Bézier curve with radius as a third coordinate, the left- and right-side points of a point on the curve are not simply 90° off from the direction of the curve’s motion. Instead, we find those points as follows:

There are two cases where this approach will not yield the desired smooth boundaries of the stroke.

When $\ell = 0$

When $\ell < {H_r}^2$

Putting all of these together, we can derive the following algorithm:

It is worth noting at the outset: this section will be noticeably less efficient than the outline technique from the previous section unless it is implemented with a high degree of parallelism in a SIMD processor like a GPU.

If we know the set of pixels that might be covered by the curve (such as a bounding box of the control points padded by their radii), we can check if each pixel individually is inside the stroke. The square of the distance between the pixel and the curve is a Bézier polynomial, as is the square of the radius of the curve at each point; subtracting those two gives a Bézier polynomial that is negative inside the stroke and positive outside of it.

For anti-aliasing, it can be helpful to know if a pixel is within 1 pixel diameter of the border and if so, haw far from the border and in what direction. An approximation of the distance from the edge of the stroke can be found as $\big(($distance from stroke centerline$)^2 - ($

Since the introduction of Adoboe’s original PostScript specification in 1982, both printable file formats and printer firmware have supported cubic Bézier curves and circular arcs, using them both as boundaries of regions to fill and as paths along which to make fixed-width circular-offset strokes. This includes formats supported directly by many printers (.ps, .eps, .pdf) and formats that have joint display and print roles (.svg, .ai). None of these formats has direct support for any type of variable-width strokes.

I dream of a day when variable-width stroking is added to these formats. It is, alas, only a dream because I have no idea how to make it a reality.

Lacking native representation of variable-width strokes, and noting that the boundaries of such a stroke are not perfectly represented using only cubic Bézier curves and circular arcs, the remaining option for exporting board work to such a file or printer is to approximate the outline of the strokes, as is done by the stroke outline algorithm.

To optimize file size and support smoother-looking boundaries of the strokes, it may be desireable to have fewer boundary points and to connect them with cubic Bézier curves instead of line segments. If the outlines of the curve were cubic polynomials, finding these curves exactly would be as simple as finding the parameter-space derivative of each stroke boundary point, as is done in one of the visualizations of variable-width stroke outlines. However, stroke outlines are strongly non polynomial in parameter space near where stroke direction reverses, requiring additional sampling and variation capping to avoid strong visual artifacts. Reparameterizing or otherwise fairing those regions may yield smoother outlines.

The stroke boundary algorithm could be extended to 3D by generating a ring (instead of a pair) of stroke boundary points at each sample point. I do not know of compelling uses for such a 3D element.

Circular offsets are related to the medial axis. Given a variable-width Bézier stroke that does not intersect itself nor have any points where the hodograph of the radius is greater than the hodograph of the position, the stroke’s medial axis is the Bézier curve.

Because of the relationship between the circumcenters of Delaunary triangulations and medial axes, a triangle strip of the stroke is close to being a Delaunay triangulation and the point of the curve that generated a pair of points is close to the circumcenter of the triangles connecting that point pair.

Implementations of these algorithms are provided with this page (inside <script> elements in its header) and are welcome to be used, with or with modifications, by anyone for any purpose without royalty or attribution, as per the unlicense. See the comment at the beginning of each <script> element for more information.