Hi,

I am developing a multi-platform CAD program (with integrated CAM features), using wxWidgets and OpenGL. I need a method to get the geometry of characters, so that we can make texts using a milling machine. The geometry info is also useful for visualizing the texts in OpenGL.

wgl in windows (and also glx in X, I think) has a function for making OpenGL display lists from text strings, but they are not useful to me, because I also need the explicit geometry information for the CAM process. Basically, I'd like to convert from a character (e.g. 'a') to a set of line segments (e.g. (x1,y1)->(x2,y2)->(x3,y3)). It would be nice if a user could select a font using a standard wxWidgets font-selection dialog, but it is not strictly necessary: if the application only supports a single font, that would be nice too for now. I just want to avoid having to draw every character manually.

What would be an easy way to get this font geometry data? I guess there's some kind of TTF-reading-library?

Fixed pitch fonts define each character cell space with a fixed width, which is proportional to the heigth of the character cell. Character cells are bigger than you might think, with things descenders - like the tail on the letter "j".

All of this information stored in the ttf file, plus there are other font formats.
You want the dimensions of one cell. You do realize that output devices can alter this, right? Simply changing resolution on a screen or printer may change cell size. These sizes are NOT cast in stone like a phsysical law.

Font file formats - and how to decode them -
http://www.wotsit.org/list.asp?fc=8

I know about all these things. The exact geometry of characters can be quite complicated (depend on size, resolution etc.), so that's why I would like to use a library for it. By linking to wotsit.org, you suggest me to read font files "manually" (without help from a library). This is also an option, but I'd like to avoid this because of the complicated structure of fonts.

Top quality is not a first priority: the first priority is to get it working, so that it can be demonstrated. So, right now I don't worry about pixel resolutions and advanced technology: I just want (at least) one font to work (it can be an ugly one). Even fixed-width is OK for now. Bitmap fonts, OTOH, are not desired.

Of course I could also try to find the easiest font format on wotsit.org, download a sample font of that format and use it. I just hoped I could save time and improve quality at the same time by using some kind of already-existing font reading library.

Do you think this could be useful to me?
http://sourceforge.net/projects/fonttools/

I forgot to mention that the CAD application already uses a lot of Python (the core is written in C++).

I took it that you wanted something that would take a text string of a given font and pointsize and provide string.textheight and string.textwidth in either page or screen coordinates. There are a lot of font tools out there that can do that if you want to embed their code in yours.

wotsit.org merely provides the font file specifications, from which you would have to derive what font construction tools already derive indirectly for you.

Since you seem to want not to reinvent the wheel, a smart choice, then you may want to see if you can use their libraries. I'm not python-competent enough to say what is a good choice. manuzio maybe?

No, I want more than just the sizes of the characters: I want a complete geometry description. I need to give a milling machine sequences of commands like "go to new position (x,y)", and the result should look like the text entered by the user in the CAD program. E.g. you could make an 'M' with:
(0,0)->(0,1)->(0.5,0)->(1,1)->(1,0)

And I want to have geometry sequences like this for all characters. I want to get this information from existing font files because:
* entering a shape manually for every ASCII character is a lot of work
* this makes it easier to replace the font / improve its quality

What us manuzio?

manuzio is a python library for font manipulation and editing. We used it (one routine) for a CAD tool development for our GIS. I wasn't part of that team.

http://sourceforge.net/projects/manuzio

After looking at some font libraries, I realized that, even when reading + parsing font files is made easy, processing the resulting data (lines, splines etc.) would become quite difficult. It would not be impossible, but it would be so difficult that I decided to try the alternative: make my own font.

In the end, that turned out to be less work than expected. I already made some curve generating functions, and I re-used them to make the curved parts of characters with just a few points. The result is not really beautiful, but it works, and that's just what we need right now. And, it will be possible to expand this (even with real font reading functionality), if we need better quality in the future.

If you want to do this in the C++ portion of your program, what’s wrong with freetype (it’s the canonical font library for linux)?

First of all, your URL: I can't open it. I can find a freetype website on:
http://freetype.sourceforge.net/index2.html

I don't know everything about freetype, but I guess it is based on bitmap-based font rendering (I'm not saying bitmap fonts: I mean that the final output is supposed to be a bitmap target). Bitmap data is not really useful to me. I guess you can also get glyph information directly, which is probably composed of spline-based outlines. THAT kind of vector-based data could be useful, but it would still require some post-processing.

I need to explain a bit about what I need to do with the geometry data: it will be used in a CAD application with integrated CAM functionality. So, for geometry, I have two output targets: the visualization (using OpenGL), and the production commands for a milling machine. The production target only supports line segments and circle segments, and the visualization only supports line segments (there are other primitives, but they are not useful for characters). So I somehow want to convert characters to line segments. Therefore, one of the post-processing steps would be to convert splines in the font outlines to sets of line segments.

Another issue is related to the size of the milling tool. If we assume that material inside the character (the "black" part) should be milled away, while the material outside the character (the "white" part) should not be damaged, then the center of the milling head should not follow the outline exactly: its position should compensate for the radius of the milling head. for "outside" outlines it should be on the inside of the outline, for "inside" outlines it should be on the outside of the outline, so that the entire milling head is always inside the "black" part of the character. Of course, for low-quality results we could just ignore this: as long as the character details are much larger than the milling head, it will still be readable even without this compensation.

Sometimes it is preferable to let the milling head follow the center of the character shape, and not its outlines. With a cylindrical milling head, the width of the character shape (distance between inside and outside outline) would become the milling diameter. With a cone-shaped milling head, the width of the character shape could be varied by varying the altitude of the milling head. For this kind of font production, a post-processing step would need to convert from inside + outside outline shapes to center shape, or to center shape + width.

My current solution is a manually-created font, consisting of sets of 3D points. A curve is created through the points, and converted to line segments. The line segments follow the center shapes of the characters. This sounds like less work to me than all the outline post-processing. I created the font shapes in about 1 hour (only for uppercase A-Z though).

Sorry about that. It’s fixed now.
You can use freetype for rendering outline-based fonts to a bitmap target (like an X server). You can also use it to get the outline data of a glyph in a font. You use an FT_Face object to represent a font face (probably loaded from an external .ttf file). In this struct, there is the concept of a “current” glyph (the one you’re working with at any moment). You can use FT_Load_Glyph() to load a glyph into this glyph slot. Each glyph (from an outline font) will have an associated FT_Outline describing its outline information (including an array of points, an array of tags describing how those points should be interpreted, and an array of contour end points). You can use FT_Outline_Decompose() to make sense of the outline (i.e., decompose it into line segments, conic Bézier curves, and cubic Bézier curves).
That is a limitation, and would take some work (i.e., approximate Bézier curves with line segments). It would be much easier if you use a font whose outlines were composed entirely of line segments (I don’t know of such a font, though it is theoretically possible).
Well, I’m glad you found a solution that suits you.

Back in the day, there were fonts created specifically for the type of problem that you are trying to solve. Basically, you want vector fonts. Hershey fonts are one instance of these. I think HPGL, mainly used by pen plotters, also defined a small set of vector fonts. Both of these are well documented on the net.
Today, I think it is possible to create your own vector fonts from bitmaps using modern tools to generate SVG formatted image files. The GIMP would be one such tool that could generated this kind of file. This would require some up-front work but would give you a lot of freedom to produce exactly what you want.
--- rod.