Lace makers use both thread diagrams and pair diagrams for instructions to reproduce a piece of lace. Pair diagrams are much easier to draw. Automated functions could take over the tedious tasks involved in drawing thread diagrams.

This article concentrates on technical aspects (math, algorithms) to generate a thread drawing for a basic stitch by some vector drawing tool. In this article a stitch is limited to a (short) plait or braid of two pairs, but allows more variations than these common examples. The transition from pairs to threads has its use both in batch processing (as for example to generate a palette of stitches for tiled templates) as interactive drawing with a vector editor.

Table of Contents Draw thread diagrams of stitches Exploring Inkscape tools Stroke to path Create Gaps / Complex strokes Geometric shapes Release frequency Bezier math Positions in a straight stitch Positions in a bent stitch Splitting a curve

It looked quite complex to deduce an elegant algorithm form this initial sketch. Analyzing the image below seems to make things relatively straight forward. A complete diagram won't give an impression of the texture as it ignores tension, but it allows to follow how a thread runs through the lace as for example shown by the screenshot at the bottom of [EditDiagrams].

The views show different presentations, which are more or less on scale, of about the most complex stitch of pairs. Ignoring the additional twists, the depicted stitch is used for example in Milanese lace when a passive becomes a second weaver. The stitch is frequently called a turning stitch but also a lock stitch, because you can control the position of the stitch by gently pulling the proper thread.

This stitch is chosen as an example because most common stitches can be obtained from this stitch by omitting crosses and/or twists at the top and/or bottom. Another turning stitch, for other purposes, is created by dropping the second cross. Plaits are just repeating more twist-cross sequences.

The thread view is composed of more or less S-shaped Bezier curves. You can play with the blue dot's in the figures of this article to get a feeling of these type of curves. Each thread in the stitch is drawn with another color. The alternating shades reveals the individual curves and their Z-order.

The outline view is not familiar to lace makers, the imaginary view is introduced to illustrate mathematical (Bezier) properties. The two black shapes are convex hulls of the two columns of twists.

The main strokes of the pair view are chosen as wide as a twist in the thread view. Annotations like the cross marks to indicate additional twists are ignored in further discussions. The wide lines for pairs illustrate the similarity and difference with the outline view. When we consider the outline view as outlines of another two wide curves, both views have more or less the same end nodes and control points, they are just combined otherwise to get different curves. More or less: The combined view shows that the end nodes of the pair view are shifted in relation to the outline/thread-view. Otherwise the sections with crosses would get stretched too much. The same principle is explained for tiles.

Various sub-tasks of the drawing process might already be available in vector drawing tools and Bezier libraries, allowing to reuse the required code when implementing the edsired function(s). This section examines Inkscape to get an impression.

The Stroke To Path function creates an outline of wide lines. Exchanging the endpoints of the pair views creates more or less the wide lines that serve as s skeleton for the outline view, but there are a few complications.

• As shown by the combined view in the first image, a thread and pair view of a complete diagram might match, but the individual stitches have different boundaries.
• As shown in the figure one the right, the outlines overlap. A stroke cap could fix that if only we could set the size of the cap.
• The tool creates more than just corner nodes. The simplify tool, may even increase the number of nodes. In our case we should simply remove the smooth nodes. The change in shape is probably acceptable.

The last step in the drawing process: create gaps in lines that go behind others. The tiled templates use small circles in the background color between two thread segments. The Knot effect looks a good alternative at first sight. It would require to have bugs fixed and an option to switch all crossings at once or rather follow hints by the z-order of the segments. Would have to check behavior with the latest nightly build before reporting.

This manual describes complex strokes at the bottom of the page. Below an example customized to our needs.

Keep a few things in mind to manually edit diagrams generated with complex strokes:

• As long as groups are not in the way, the shapes can be normally adjusted with the node tool by selecting all objects: F2, CTRL-A. The bounding boxes however may cause some clutter.
• Without grouping you can't select a thread segment by clicking on it. You would at lest miss the invisible one of the the objects that compose the segment. You should select the area containing the segment.
• Make sure to duplicate a segment (the original plus two clones of a complex stroke) with the option relink duplicated clones switched on, available since release 0.47, by default it is switched off. Without relinking the segments are not independent. Reshaping the first segment would reshape the duplicated segment too.
• When copy-pasting complex strokes, group before copy and ungroup after paste, thus you get rid of transformations and keep the clones in the segments on top of the corresponding originals.
• The [EditDiagrams#Apply_color_to_the_threads] plugin would need enhancement to deal with the clones.

Knots and complex strokes require the same base algorithm to assemble stitches. Complex strokes just require to split paths at nodes and add duplicates to the segments for the stroke properties. Enhancing the thread style might be less error prone than fixing the knot tool. Both might serve a larger community than just lace makers and they might have different performance consequences for larger diagrams. Using the complex strokes makes editing of generated diagrams more complex.

Another alternative, draw-the-sections-you-see requires another algorithm. The approach forgets lace makers [concepts] that should somehow be reflected in software designed for lace makers. As a consequence manual adjustments are more complicated: A user would have to concentrate on three segments for a proper gap. With complex strokes or knots a user can concentrate on a nice bend of a single thread, the software takes care of the complex maintenance of the looks of each cross and twist.

Though a stitch is not quickly associated with a geometric shape, it could be implemented as a similar tool. When examining the XML of the implemented shapes, most are a single path with some additional attributes in the Inkscape name space. Using a single path for a stitch does not allow different colors for different threads. A single path would require the knot effect and a not yet available possibility to switch all crossings at once. The 3D boxes however are groups of paths, that allows stitches with complex strokes.

The group would require at least one special attribute: A text field for the lace makers abbreviation of the performed actions, for example "tct". Let's assume ctc=clrc, l meaning twist left pair and r meaning twist right pair and c meaning twist both pairs. That gives us four letters for the string: t,c,l,r. As we restricted a stitch to a two pair-braid, the string is in fact a braid word written in lace makers shorthand. Other attributes might be stroke properties.

Two special buttons could switch selected stitches to thread or pair view. A toggle is not applicable as individual stitches could be in different states. Keeping track of the states would be too complex, both to implement as to explain. Switching to pair view means making the clones 100% transparent and the paths without clones 0% transparent. The other way around might be trickier as one might want a little transparency for the wider clone. These buttons would allow to create a pair view for some publication and crop out (or check) difficult sections with a thread view, without having to redraw anything and prevent inconsistencies between the two.

Even if we don't define a proper braid word for a rare stitch like this three-pair stitch nor implement a corresponding algorithm, we could create and adjust it manually, but still have the buttons to switch between pair and thread view.

The timeline shows about three releases a year up to 2012 and none since might suggest a decline in development. These statistics a code chill which started on the brink of 2013, and the reason for the delay seem reassuring.

The image on the right zooms in on a tctc variant of the first image. The grid lines illustrate the ratios of the overall stitch and each twist and cross.

The nodes and control points of the curves are all placed on intersections of the outline view and horizontal grid lines. A twist between twists has its nodes on the corners of a rectangle. Only a node of a twist that touches another twist has a control point. These control points are placed on the outline view two grid lines above respective below the corresponding nodes. A node of a twist that touches a cross is moved up respective down by one grid line. Bumps in the blue and orange thread show we might need control points for these moved nodes after all. The position of these control points should mirror the center of the corresponding cross.

When a stitch is morphed into another shape (an example shown with the combined view in the first image) the nodes stay on the outline view. Keeping the control points also at a bent outline view would create bumps, but to simplify things it might do for a prototype. The tool "make selected nodes smooth" or some variant for split paths can fix it. To calculate the positions of nodes and control points, we can divide the long edges of the outline view in n sections of more or less equal length and count sections. The horizontal grid lines in the image on the right learns we need five sections per twist plus one overall to get n.

The Casteljau's algorithm can be used to split a curve into sections. From the Bobbinwork twist marks becomes clear that it is not trivial to get sections with equal lengths. The simple educated guess solution won't do in this case. This code example with look up tables seems to have an answer, though the code contains comment about an expensive operation, so it might not perform well for a large diagram. The number of intervals in the look-up table would be some multitude of n. Inkscape delivers a bezmisc.py. At first sight it does not contain a look-up-table.