Someone has asked me to try making the node configuration automatic, as it's quite cumbersome at the moment, but I haven't really worked out what the logic to do that would look like. I may need to sit down with an Actual Type Designer who understands how points should move relative to each other.
I think I've realised that it's probably impossible to build a visual constraint system fully automatically. Aside from the difficulty of embedding knowledge about how points should move relative to each other in a generic way that is not specific to a glyph or style, the problem is that moving one point is not a clear signal of intent.
if I pull the bottom left point of the counter of a /b to the left, I could either be trying to thin the stem or enlarge the counter. If I am trying to thin the stem, then the points on the far left of the stem should not move, but if I am trying to open the counter, they should. The system could guess that stem widths should be maintained, but it would be infuriating if that wasn't what you intended. The only way to signal unambiguously that you want stems to be maintained would be to add an explicit constraint, which is where the plugin is up to add the moment.
In short, automatic smarts are brilliant until they're wrong, at which point they're useless.
@Simon Cozens In your situation, the /b may be rigged as this: So, to change stem width or contour size, you can just edit the numbers (of constraints) and see the result.
Ok, so this is not as "procedural" as shown/discussed here, but...close enough?... Last month I've had a client who wanted a small Didone style family for just under month and a half?! His offering was good and generous, but because I would normally do that in (under) six moths, I've panicked... so I wrote this little fellow to help me - a "simple" parametric engine that allows me to virtually tag/name any contour parts and control them. And if applied globally (and consistantly) it works very similar to what Prototypo.io would do, but in Fontlab V. It utilizes an abstract system that binds tagged nodes/parts to programmable stackable "containers" which behave differently (user specified in code) on demand. For example there is a container that just shifts things around or another that does that by interpolation; these same two that are metrics & kerning aware; serif shape or stem width controlling containers and etc... At the end the deal was regretfully off, but the script remained so here is a little demo tagging a typeface of mine that is work in progress.... https://www.youtube.com/watch?v=KAmh9NPvTvY https://www.youtube.com/watch?v=8BDrWBIvbjw
Comments
Someone has asked me to try making the node configuration automatic, as it's quite cumbersome at the moment, but I haven't really worked out what the logic to do that would look like. I may need to sit down with an Actual Type Designer who understands how points should move relative to each other.
...or just listen to one. Or just read the intructions of a b&w hinted font. Or just read the TT instruction manual.
if I pull the bottom left point of the counter of a /b to the left, I could either be trying to thin the stem or enlarge the counter. If I am trying to thin the stem, then the points on the far left of the stem should not move, but if I am trying to open the counter, they should. The system could guess that stem widths should be maintained, but it would be infuriating if that wasn't what you intended. The only way to signal unambiguously that you want stems to be maintained would be to add an explicit constraint, which is where the plugin is up to add the moment.
In short, automatic smarts are brilliant until they're wrong, at which point they're useless.
In your situation, the /b may be rigged as this:
So, to change stem width or contour size, you can just edit the numbers (of constraints) and see the result.
Simon, I also wonder if you have changed your view on this topic in the last 6 years
Wow it's been a minute haha