@steve, @rajaa, @lowell, we were talking about adding single-stroke fonts to Rhino for marking and engraving. We have two fonts available to us: one Lowell made, and one made by MecSoft.
I am concerned that installing single-stroke fonts in Windows will make for crummy user experience in other applications, as single stroke fonts don’t work well generally.
Is it possible to load fonts from TTF files outside the Windows Font system?
Looks like this is possible with the Win32 function AddFontResourceEx.
If my first suggestion doesn’t work, we may be able to do this with
http://www.freetype.org/freetype2/index.html
There are several articles on code project etc about doing this.
@DavidRutten, we may want to look into your recent work with single stroke type fonts. Do you think what you’ve written could be packaged with Rhino and used in place of, or in addition to our single stroke TTFs?
Could you provide us a little more details about your work so we can get a better understanding of what we have to work with? Thanks
Here’s what I’m currently working on, it’s basically a project made up of 3 parts:
The goal of the above is to be able to generate high quality geometry that looks like text. The font we’re working on is composed entirely of lines, arcs and circles (but it’s possible that I’ll add support for bezier/nurbs segments later).
I’ve put a bunch of details on my blog, including a YouTube video of the Font Editor plugin.
So far this is a pure C# RhinoCommon plugin, so there’s no reason why it wouldn’t work in Rhino proper at some point.
…wow…
–Mitch
Yes, wow! 
I can imagine that that’s really difficult…
Philip
What is the downside of reading and saving the fonts as TTF or OpenType files? It seems that, were this done, all the code that handles them today in Rhino could make direct use of the fonts created. If Rhino had a place to load single-stroke fonts into the font list, we could make them available everywhere text can be created in Rhino.
Thanks, @brian and I just had a long chat about this and I’m sure you’ll be getting more questions from us 
A few minor points:
For SDK support, at first glance it seems like we would need some form of MeasureString and DrawString similar to the System.Drawing.Graphics routines.
First, I think this is an absolutely great idea. Solving the problem of single-stroke fonts for engraving will be a great thing to do.
Second, I’d love to see this eventually integrate into Rhino so people can use these fonts in Text, Dimensions, and other annotations. But doing that seems challenging on a number of fronts:
Integration with standard UI controls seems the hardest to solve. Brainstorming a few options:
that is luckily not my problem. My goal is to write a few GH components that generate this geometry. Saving will just work the way it works for all GH stuff.
If I had to solve the problem though, I’d say that the TextObject in Rhino should be aware of which font it uses and act accordingly. Perhaps the font picker needs to provide both OS installed fonts and special single-line fonts.
It doesn’t. Italics are of course possible, but there’s no way to make a single line font bold. The thickness of the burn or milling groove depends on hardware, to be selected by the user. Also colours are immaterial if you want to use a laser-cutter to burn the text onto a piece of wood. Any colour you want, as long as it’s black…
Other RTF properties such as variable font-size, underlines can be mimicked with a sufficiently advanced font ‘renderer’, but this falls well outside my initial goal posts.
It doesn’t. It’s not a font in the way that Windows thinks about fonts. It won’t be installed on the OS level.
See earlier reply. Shearing may work, though it will deform arcs and circles into ellipses.
Yeah, probably. Once a kerning engine is up and running it’s fairly trivial to draw text with single-line fonts onto graphics surfaces (OGL, Direct2D, GDI, doesn’t matter). But if you want it to work within textboxes, you’ll need a proper font. One interesting idea would be to create a proper font (TrueType or OpenType) from the rhino curves, it can be done by widening the strokes. If I get access to a font writing dll, I can automate this process as well.
Oops, you got there before me.
Depends. If we use Eto to write the UI it’s the same code on both platforms.
I have a feeling we’re getting a bit ahead of ourselves here though. This is a long-standing problem and I’m just now trying a different approach. It may not work at all. It may work poorly. Or maybe, if we’re lucky, it’ll work better than our current approach, in which case we can start worrying about how to apply it further.
I’ve been wondering about what file format to use, but settled (at least for now) on simple text files. They are extremely easy to write and parse, which is not true of SVG. In addition, SVG supports a lot of stuff we don’t need, this complicates matters. SVG even supports scripting, and this may cause all sorts of security issues where computers block or quarantine the files.
I figured putting a bunch of text files with *.char extensions into a zip archive with a *.font extension would be easiest to deal with. But as Brian already brought up, there’s no reason why the font creator plugin couldn’t write out other font formats as well, including *.otf and *.ttf. What I’m trying to say is that the file type decision is not something we commit ourselves to forever. If we decide to go a different route later, we’ll just have to update the plugin and re-export the fonts we have.
Yeah, that’s the hard bit. The kerning engine needs to be able to do all this stuff, including perhaps alignments, dealing with variable font sizes, auto-italics, auto-underline, hyphenation, justification, … the list goes on. It’s also mostly beyond what I was imagining version 1.0 of this project would need to do. At the moment I’m really just trying to make it easy for fabricators to put identifiers on parts which can be milled/burned with a minimum of effort.
I mention what I feel the downsides are on my blog post:
Hi David.
I’m looking forward to adding this to my toolbox!
As for this:
( sorry no formatting on my phone)
“At the moment I’m really just trying to make it easy for fabricators to put identifiers on parts which can be milled/burned with a minimum of effort.”
Did you consider starting with a stencil like font; iow a font without closed regions to prevent material detaching when milling/cutting through material?
Cheers
-Willem
We didn’t yet, definitely something to keep in mind. It shouldn’t be too big a deal to punch holes into an existing single-line font to create a stencilled alternative.
I like to cast the net wide while I’m dreaming - that way I can imagine things that might otherwise never come to be.
Sure, you could solve this problem for GH only, and GH-only customers will be happy. If we can also use your work to solve a broader set of problems for Rhino users, too, that’d be even better.
I’m mostly hoping to plant the seed for where this work could ultimately end up being used.
I imagine you were inspired by LaTex, but Autodesk had what you’re proposing (except for the GUI editor) in SHX files before there were TrueType fonts. It made it possible to create symbol fonts (think Wingdings) for common drawing symbols, and enter them with ordinary characters.
Yes, but that’s only a problem if you install them in the system. It’s perfectly reasonable to load fonts from elsewhere (without confusing all the other apps on the system). Sure, it’s a misuse of the system, but it also lets the OS solve the kerning, layout, and display problems for you.
I think we will have the same problem if we use a single stroke true type font file. Those fonts will probably look bad in standard edit controls.
I wasn’t recommending we try to support every part of SVG, just support what we need (lines and arcs for now). An SVG path with lines and arcs is reasonably easy to parse, well defined, and can be previewed in other applications. Since you are writing the reader, the parsing code can just only support only these elements for now and ignore everything else. We can then expand on this in the future if we wanted to. Just trying not to completely reinvent the wheel.