Work for a Member company and need a Member Portal account? Register here with your company email address.
Have you ever needed a single-line font rather than an outline of a typeface? For instance in the use of digital fabrication processes such as laser cutting, embroidery, or CNC milling?
SkeleText is an open-source creative tool that translates the character of any given font into a skeletal form through a series of geometrical transformations.
There is quite a lot of math and code involved to convert a typeface to a single line (and there could potentially be even more -- we found some math-light shortcuts!). Here's an explanation of some of the key steps in the process:
Text to points: By using p5.js's native textToPoints() command, the outline of each character in the chosen font is translated into a set of points. This is done by sampling points along the bezier curves that define the characters.
Delaunay triangulation: For this, we use d3's Delaunay library. This algorithm creates triangles by connecting the given set of points, ensuring that no point is inside the circumcircle of any triangle. It’s one of the key concepts used in the process, as it's a way to divide up the space within a letter into smaller, more manageable parts.
Voronoi diagram: In the context of SkeleText, the Voronoi diagram is derived from the Delaunay triangulation mentioned above. For each triangle, you calculate the circumcenter (the center of the circumcircle that passes through all three vertices of a triangle). Connecting these circumcenters gives you the Voronoi polygons, which look like the "skeleton" of the original shape.
Circumcenter: The circumcenter of a triangle is found using the intersection of the perpendicular bisectors of the sides. In a 2D plane, the formula can be derived using the coordinates of the triangle's vertices and is involved in the calculation of the Voronoi diagram.
Point organization: Organizing points into a continuous line requires finding logical connections between nearby points. An extreme (like the leftmost point) is selected, and then the closest subsequent points are ordered before the letter is drawn.
Brightness filtering: This approach leaves us with a mess of lines. We found a math-light solution where we draw the character to a temporary graphics buffer and check these graphics for each of the points. The points that are not drawn on top of the letter shape in the graphics are removed, preserving only the parts of the Voronoi diagram that correspond to the actual character shape.
Maximum point distance: The organization approach above is not perfect, so another filter is to split the points up in multiple lines if the current point and previous point are too far apart. This avoids having lines run across a letter shape.
Path Simplification: A simplification technique was applied to eliminate unnecessary zig-zags or noise. We used a custom version of the Douglas-Peucker algorithm to remove any unnecessary points. For a given segment of the line (initially the entire line), we identify the point that's furthest from the segment. If the distance from the segment to this furthest point is less than a given threshold (tolerance), then we can eliminate all the points between the segment endpoints. Otherwise, the segments are divided at the furthest point. This principle is recursively applied to the two sub-segments.
While this tool implements a lot of math as can be seen above, we learned that sometimes the most simple approaches are also the most effective ones. While some elements could have been solved purely mathematically, we often chose a solution with less heavy computations involved. For instance, the skeleton lines from the Voronoi diagram are simply filtered by checking if the point is drawn on top of a character or not. The mathematical solution may yield cleaner results in the long haul but would effectively require a lot more computation, causing the tool to be especially slow. We want to address this as these other approaches may have different benefits than the one we chose.
Unexpectedly, the structure that appears when applying skeletonization on text characters looks very similar to the design needed to carve letters in stone. Typographer Jacob Wise, who experienced hand-carving type while studying at the TypeMedia program in The Hague (NL), mentioned that this underlying architecture (as well as the outline of the character) is needed to chisel the letter shape properly. In the images below, you can see the way the architecture/skeleton translates to carved letters.
Adjacently, one of the leading theories on the emergence of serifs in the Latin alphabet is that they helped with creating neater shapes when chiseling letters in stone — a popular method of displaying text during the Roman Antiquity.
SkeleText Beta is a browser-based tool that can be accessed through any web browser. This version is meant for desktop interfaces. Find it on https://veravandeseyp.com/skeletext/.
SkeleText is just a beta version so far. The interface could be developed further, and some bugs might appear when the tool is used by different users. Please reach out to veraseyp@media.mit.edu if anything needs attention.
The implementations of this project , here are some examples:
"DeepSkeleton: Learning Multi-Task Scale-Associated Deep Side Outputs for Object Skeleton Extraction in Natural Images", available at https://www.researchgate.net/publication/308066453_DeepSkeleton_Learning_Multi-Task_Scale-Associated_Deep_Side_Outputs_for_Object_Skeleton_Extraction_in_Natural_Images
Samara, Timothy. Typography Workbook: A Real-World Guide to Using Type in Graphic Design. Rockport Publishers, 4 Sep. 2004, p. 21.
"Skeletonization", available at https://homepages.inf.ed.ac.uk/rbf/HIPR2/skeleton.htm