Text as Geometry: Building Reliable Personalized Products

A personalized product often begins with something that looks harmless: a customer’s name. To a 3D printer, however, text is not language. It must become closed outlines, printable features, and valid solid geometry.

That conversion is where many customized products become fragile. A font can contain strokes that are too thin to print, a long name can collide with an attachment hole, and an unsupported character can silently disappear. Even two names with the same number of letters can occupy very different amounts of space.

This article is the first technical deep dive following Parametric Goods: From Customer Choice to Printable Product, which introduces the seller’s complete order-to-print workflow. Here, the focus narrows to text as a geometric input with measurable bounds and testable failure cases. The keychain project below demonstrates the maker-facing routine: enter the ordered text and font, inspect the regenerated result, and export the geometry for production.

The text stored in an order is a sequence of characters. A font maps those characters to glyphs: the visual forms that will eventually become geometry. Text layout then positions the glyphs using advances, side bearings, kerning, and—depending on the writing system—contextual shaping or substitutions.

Only after that layout step can the glyph outlines be treated as planar paths. Those paths may contain straight segments and curves, multiple disconnected components, and interior holes. The letter O, for example, needs both an outer contour and an inner contour. Filling both indiscriminately would produce a solid disk instead of a recognizable letter.

This distinction matters because “the order contains valid text” and “the project generated valid geometry” are separate tests. A character may exist in Unicode but still be missing from the chosen font. A replacement box or blank space is not an acceptable personalized product.

From customer text to printable solid

Diagram: Customer text is resolved into glyphs, shaped into planar regions, measured, combined with the product body, extruded, and validated for printability.

flowchart TD
  S1["Receive the customer text"] --> S2
  S2["Resolve glyphs in an approved font"] --> S3
  S3["Shape and position the glyphs"] --> S4
  S4["Build planar regions from the contours"] --> S5
  S5["Measure the generated bounds"] --> S6
  S6["Derive the body and attachment geometry"] --> S7
  S7["Extrude and combine the solids"] --> S8
  S8["Validate glyphs and printable features"]

Character count is useful for setting an order limit, but it is a poor geometric measurement. III is much narrower than WWW, while punctuation, capitals, and wide glyphs can change the overall bounds again.

After the text has been laid out, the model can measure its actual width $W_{text}$ and height $H_{text}$. A keychain body can then be derived from those bounds:

where the $m$ terms are the desired margins. The attachment feature should be included in the same dependency system. If a ring hole occupies space on the left, the left margin may need to include the hole diameter, the required surrounding web, and a gap before the lettering begins.

The useful measurement is the geometry that will be produced—not an assumed average width per letter.

A typical production pipeline converts font outlines into planar regions and then gives those regions thickness. The exact operations depend on the product:

Font contours are not automatically clean manufacturing profiles. Very small curves, overlapping paths, self-intersections, duplicate edges, or inconsistent contour direction can cause planar filling or Boolean operations to fail. Curve approximation also matters: too few segments visibly flatten the letters, while excessive segmentation increases geometric cost without improving the printed result.

The final check is the solid produced after every union and subtraction, not merely the appearance of the original outline.

A screen can display a stroke thinner than the printer can deposit. The physical product is constrained by nozzle or laser spot size, layer height, resin behavior, material flow, orientation, and the slicing strategy.

For raised text, inspect the narrowest strokes, the relief height, and the contact area joining the letters to the body. For recessed text, inspect groove width and depth as well as the spacing between adjacent cuts. Small counters—the enclosed spaces inside letters such as A, B, and R—may close even when the outer silhouette survives.

There is no single universal minimum because processes and materials differ. A product template should instead be validated against the actual printer, material, nozzle or process settings, and orientation used by the seller. If several production profiles are offered, each one needs its own tested limits.

A useful rule is to treat the thinnest important feature as a controlled parameter or validation result, rather than discovering it only after slicing.

Text on a solid plaque is structurally simpler than freestanding script. The plaque supports separate letters, punctuation, and interior details. A keychain body also provides a predictable place for the ring hole and a continuous load path around it.

Freestanding text needs additional rules. Neighboring glyphs may require overlap, a connecting baseline, or deliberately added bridges. The dot over a lowercase i and punctuation marks are disconnected components unless the design joins them to something else. Cut-through lettering has the opposite problem: enclosed counters can become loose islands unless they are bridged in a stencil-like design.

These are product decisions, not generic font settings. A decorative typeface chosen for appearance may be unsuitable for a one-piece object unless the project modifies or supports its disconnected geometry.

Every text-driven product eventually receives an input near—or beyond—its intended limits. The project should respond deliberately.

Automatic scaling should have a lower bound. Otherwise the project can technically “fit” any name by shrinking it until it is unreadable or unprintable. The listing limit, project validation, and production policy should all describe the same boundary.

A font affects dimensions, stroke widths, counters, spacing, and the identity of the finished product. It should be managed more like a material profile than a casual visual preference.

For each offered typeface, retain the exact font file or approved source, record the family and style, and verify that the license permits the intended commercial use. Do not assume that a similarly named font installed on another computer will produce identical glyphs or metrics.

The production project should also define its behavior when the requested character is missing. Silent fallback is risky because the replacement font can change both appearance and dimensions. Rejecting the input or routing it to manual review is usually easier to audit.

When a product design is updated, keep a versioned reference to the font and relevant text settings. This helps reproduce an earlier order without guessing which asset generated it.

The attractive default name is rarely the best test. A useful validation set deliberately exercises the edges of the product family:

• the shortest and longest permitted strings;
• very narrow and very wide glyph combinations;
• names with capitals, lowercase letters, spaces, and allowed punctuation;
• letters with small counters or delicate strokes;
• repeated characters that expose spacing problems;
• every offered font at its permitted extremes;
• the closest allowed approach to the key-ring feature; and
• at least one real print for each production profile.

For each case, check the generated contours, completed solid, overall dimensions, minimum features, exported mesh, slicer preview, and physical result. Save representative configurations as regression cases. If a later project edit breaks a previously valid name, the product template has changed even if its default still looks correct.

The keychain generator above keeps the seller’s routine short:

Open the product project → enter the ordered text → choose the approved font → inspect the geometry → export → slice and print

Behind those few steps, the project carries the reusable work: text generation, body construction, margins, feature placement, and the approved parameter choices. The maker still performs the final order comparison and production inspection, but no longer rebuilds the CAD model for every name.

That is the practical value of treating text as geometry. A customer supplies language; a controlled Rig Cad project converts it into a repeatable physical product.

Parametric Goods: From Customer Choice to Printable Product is the series overview. Continue with Beyond Sliders: Designing Safe Parameter Spaces for Printable Products, which expands the text-specific rules in this article into a general method for keeping every combination of product parameters valid, printable, and within the seller’s production promise.