Help with Glyphs path definition for single-stroke typeface (for CNC/engraving use)

Hello, all. I have designed a typeface using only single strokes – ie. no closed paths – such that these paths can be used by a CNC or engraving tool, with the line width set by the cutting tool itself. Of course I’m very aware that creating a font in this way is not supported in OTF/TTF, which requires closed paths! However, a number of CAD and other software tools still use special TTF fonts designed in this way, ignoring the “correct” way of interpreting the font. There are a number of options on in TTF that are designed to be used this way.

I see that there has already been some discussion of this topic on a couple of threads here, but I think I’ve come a bit further and I’m hoping for a little help in figuring out the final problems I’m having creating my own fonts the way that does it.

As I understand (from those other forum threads), if I export my fonts from Glyphs as TTF with “remove overlap” and “autohint” turned off, Glyphs will export without closing the open paths that I have created. My hope was that this would be sufficient for the font to work in my CAD application, but there is still something I’m not doing correctly. I assume it has to do with the way my paths are defined, but I can’t figure it out.

Here are three comparisons between my font with OLF Simple Sans – a “stick” font in TTF on (and included with Solidworks incidentally). First, here is a comparison in Glyphs itself (where I’ve just opened up the TTF of OLF Simple Sans). You can see that OLF shows all closed paths, but I guess these may be strokes that Glyphs is implicitly adding when it sees the open strokes in the TTF. You can see that the “3” actually has two open paths that are being closed in this way. Then below you can see how I am defining the same characters in my font in Glyphs.

Then second, here is a comparison of the fonts in Illustrator (changing display from filled to stroked). You can again see how the open paths in OLF are closed (implicitly or explicitly, I’m not sure). Then with my font, there is some strange behavior. “1” and “7” are completely missing for some reason. “6” and “9” have lost their tails. “4” shows a stroke I didn’t create, but ignores others that I did.

Then most importantly, here is a comparison in Solidworks. OLF works perfectly, removing only the unwanted path-closing strikes (removing 2 strokes in “3”, 1 stroke in “1, 2, 4, 5, 6, 7, and 9”, and no strokes in “8” and “0”. Then you can see my font where “1” and “7” appear, but only one stroke of each, and various implicit strokes that I assumed would be ignored in “2, 3, 4, and 5” are still visible.

So in the end, my question is: how do I define my strokes so that they are interpreted correctly by a CAD package that is expecting such a font? I assume that I don’t want to explicitly close my paths – then how would it tell that two of the strokes in “3” are to be ignored, where as none of the strokes in “8” should be ignored? But if I leave my glyphs open, how do I create my strokes so that they are interpreted the same way that OLF is in Solidworks (and I assume the other CAD software listed on

Any thoughts or advice would be greatly appreciated. An automated script to handle this would be fantastic, but I’m even willing to do some hand-work on my glyphs in order to make this work correctly, if I know what direction to go.

1 Like

I need to look into this. Could you send me one of the fonts that I can have a look inside?

I’ve just sent you a message. Thanks very much!

Same problem here, would really love to know if you solved this ymatto or if anyone has any ideas.

Georg has kindly been looking into it with me outside the thread here. Right now he’s in communication with SolidWorks to see how they’re using stickfonts for this kind of application. If we figure it out, I’ll definitely post the resolution here for others.

Thanks for the update. I’d really love to start using fonts like these in Rhino/Solidworks. My current process is manually typesetting the single line glyphs in Illustrator then exporting. So time consuming.

Let me know if I can help in any way!


If you want to make your own stickfonts, why not use StickFont Editor rather than Glyphs? It is specifically designed to make CNC fonts.

@Arnaud Yup, that illustrator approach is exactly what I’m hoping to avoid…

@George_Thomas Huh, I had never heard of StickFont Editor – I will have to check that out. Is it the tool at this URL?:

Although in this case I already have a typeface that I’ve designed in Glyphs for general use and I’m just wanting to create a stickfont version of it for engraving/machining so it would be ideal to have both built within Glyphs.

Same here. It’s already all in Glyph. I’m also assuming that StickFont editor won’t just let me drag and drop. :frowning:

I will give it a try later today and report back.

@ymatto This url is a better one for the latest version editor:
It has a 15-day Free Trial Period.

I played around with Stickfont Editor last night and I don’t think it’ll work for me. I need to be able to create a TTF that I can import into Rhino… seems to have figured out a way to do just that with the TTF format. I’m going to keep researching this. I think this is an important need considering how many people are using CNC machines (lasercutting, engraving, milling, 3D printing) these days.

I hope Glyphs can find a solution for us so that type designers can start making really nice single line fonts to be used in those CNC applications. Let’s keep this discuss going please. :smile:

Ah, yeah, I also took a look at Stickfont Editor and came to the same conclusion as @Arnaud – not what I’m looking for. Gcode is fine if you want to drop some text directly into your machine, but I need a font that can be used at the design level for more complex integration of type into a CAD object.

1 Like

So for those watching this thread: Both Georg and I have been trying to work with Solidworks to figure out what they are doing to read in fonts like those on Unfortunately I think we are at a dead end. Solidworks will only tell me that they are using “custom code” to read in the OLF fonts and won’t give me any additional information. Georg has been trying to figure it out from the outside, but there seems to be something non-obvious required to let CAD interpreters know that a font is one-line (as opposed to just a broken, open TTF).

is there a solution for this problem? Would be interesting.

I’d still love to find a solution, but after my post above I’ve given up and I haven’t learned anything new…

i find something new. How did they do that? Anybody reengineer this?

Do you have the Problem only with Solid Works and if not! Do you tested your font with open source CAD Software?

Very interesting, @spaceinvader . I wonder if those Fontlab settings would give @GeorgSeifert any hints about what might allow Glyphs to do the same.

As for open source CAD, no I haven’t tried with any of those – I’m only able to use Solidworks for what I do, but I don’t gather that it’s doing anything special. But perhaps somebody else could investigate.

If I can ever get a demo of Solidworks to try, I’ll try out some experiments. When I last requested, they were completely silent, though. Some CAD programs, e.g., Rhino, end up having a special option to enable so it doesn’t do the final closepath on a font with open paths in the glyphs. As I recall, it sounded like Solidworks might be looking for something special in the font to determine if it’s a single-stroke font.

I have some plans to do some more investigation this summer with another project. I’ll post about the results, if something is learned from the exploration.

The problem with solidworks is that the fonts need some hard coded support from within solidworks.

I just had an idea. Maybe me can hijack those fonts and put in out own outline.
@ymatto are you familiar with ttx/fonttools? With it, you can copy glyphs from one font to another. So you could try if your outlines made in Glyphs work if copied in the working font.