Dedicate library for identifying strokes/stems?

Belleve Invis

Sometimes I am wondering that there would be a library for stroke/stem identification. Input an outline and output the identified strokes/stems with point index correspondence.
Should I extract them from autohinters?

Hrant Հրանդ Փափազեան Papazian

Do you mean to extract the skeletons inside black shapes? They're imaginary.

Georg Seifert

The ttfautohinter can output 'debug' info that contains the info you need.

Belleve Invis

Hrant H. Papazian said:

Do you mean to extract the skeletons inside black shapes? They're imaginary.

Well, not exactly same. I'd like a separate library to identify horizontal / vertical stems.

John Hudson

Identify just in terms of glyph topography, or identify in terms of being able to label the stems?

Belleve Invis

John Hudson said:

Identify just in terms of glyph topography, or identify in terms of being able to label the stems?

Identify stems from a specific input glyph (outlines, in particular), return a list containing information including:

1. Upper/Left edge points
2. Lower/Right edge points
3. Upper/Left edge position and slantness
4. Lower/Right edge position and slantness

Kent Lew

You’re talking about a library of analyzers that can identify various common glyph parts and report the associated points, right?

I think Petr van Blokland has done some significant work along these lines in the context of development of various hinting and other tools for Font Bureau/Type Network. But I don’t know if any of that will ever be made public.

Vassil Kateliev

I am currently playing around with similar concept, trying to develop a library that will allow the computer to see and identify glyph parts and nodes belonging to them, label/tag them for further processing (parametric or otherwise), but... only when I have the time for it....  So I guess I would say... Yes! it is quite possible to do such a library - my approach is purely analytical-computer-vision-kind-of-thing and it sort of worked (at least for me and my type projects), but I guess Neural network approach (self learning) will be far better, but it is beyond my capabilities/knowledge...

Hrant Հրանդ Փափազեան Papazian

Now it's sounding like skeletons again...

Vassil Kateliev

Hrant H. Papazian said:

Now it's sounding like skeletons again...

No skeletons here (at least not in my project) but it will be a nice addition..., on the other hand I was always interested in your Notan theory, so if you care to explain it to me when you have the time!

PS: Skeletons are tricky, messy and no panacea - they have their purpose dough, but that is a one that I am not interested right now.

Belleve Invis

Vassil Kateliev said:

Hrant H. Papazian said:

Now it's sounding like skeletons again...

No skeletons here (at least not in my project) but it will be a nice addition..., on the other hand I was always interested in your Notan theory, so if you care to explain it to me when you have the time!

PS: Skeletons are tricky, messy and no panacea - they have their purpose dough, but that is a one that I am not interested right now.

Write it in Node.js please

John Hudson

Now it's sounding like skeletons again...

No, it isn't. Belleve is talking about identifying the topology of outline glyphs, which has nothing to do with skeletons. The problem he wants to address is that a digital outline is just a path, and a glyph can be made up of multiple paths, and there's nothing in the outline itself that identifies the parts of the glyph shape in a way that is meaningful in terms of what the glyph is. So if you consider the glyph of an uppercase H, even though it is may be composed of a single path, it has a fairly complex topology involving two interior spaces divided by a crossbar; in the world of variable fonts, this is likely to be complicated further by the use of multiple paths. What I understand Belleve to be talking about is being able to identify the topology of the glyph, so as to be able to say 'This is the left upright; this is the right upright; this is the crossbar'.

Hrant Հրանդ Փափազեան Papazian

Although it could be used to "reconstruct" skeletons, I guess you're right. I just worry.

Deleted Account

We use analysis as Kent points out, to give us dimensions interactively while we draw.

But most font design systems that mark "stems" for the kinds of manipulation I think being contemplated, involve substem elements combined, breaking up the continuous contour into parts for detailed manipulation according to their location, proximity, size and shape.

This mastication gets around the shortcoming John's pointing out, about continuous contours. With variations freeing contours from restrictions that went back to metal, wood and film, then carried forward via "the great overlap bug" in postscript, it's now easier to develop modular fonts, as an upcoming variation will demonstrate. https://youtu.be/KOO5S4vxi0o

This should also open up Vars development to font design systems that have been working this way for a while, but had no way to interface their substem parts and variators to Desktop platforms. 

John Hudson

Although it could be used to "reconstruct" skeletons

Sure. That's the approach that the Metapolator guys are taking.

But that in itself is really interesting: because if you can obtain a skeleton in this way, and if you can then reconstruct the original glyph on that skeleton using parametrics, that means the glyph has a skeleton. And if you obtain a skeleton by analysing a glyph, but can't reconstruct the glyph on that skeleton, that means the glyph doesn't have a skeleton. My guess is that some glyphs in some typefaces have skeletons, and some do not. To insist that 'there is no skeleton' seems as unwise as insisting that one can generate all glyph shapes parametrically from skeletons.