“Procedural” design software concept?
Belleve Invis
Posts: 269
Just a concept: Is it a good idea to create a “procedural” type design software: every distinct glyph has a "construction workflow" so the data quntity a type designer have to maintain can be minimized?
1
Comments
-
I quite like this idea, and can imagine how it could break down into sub-glyph procedures, such as building from modular elements or even running scripts to affect stem weights.0
-
You might want to look into how Glyphs 2 handles "smart components"0
-
This is vague, in what terms procedural, What parameters are constant and what is variables? If you imply contours could be repeated as components this is only tip of the iceberg. Take Chinese for example. Many strokes share similar construction but when they are put on different characters their contours change, which could be solved by smart components in Glyphs 2 but still not ideal when you consider huge amount of possibilities because you have to make couple of masters per shape.0
-
@Bahman Eslami
I think I can introduce some concepts from mechanical design, especially Solidworks' sketching and constraint solver. Length, angle and proportion can be constraints, and their value can be set to a parameter or a literal number.
0 -
This could be really interesting when it's not only for one script. Otherwise it's not called a type design software, maybe Latin type design software? Latin contains more procedural constructions when it comes to roman capitals and miniscule. But when we deal with handwritten typeface in Latin still there are certain patterns which are constant across a family but could not be defined by the method you're mentioning. Of course it might help to start a family on a certain construction and then work on details manually.0
-
Ideally, the structural description is extensible, and not in any way script- or style-specific. Common libraries of structures for well-established styles — e.g. Latin serif type — could be shared, but it should also be possible to create new structures, using a smallish set of statements.
0 -
Interesting -- I have to admit I can’t quite picture yet how finely this would break down for more complex outlines, but I wonder where / how far this could lead. I’d be also excited about being able to combine hard numbers with variables in this sort of description as you’ve described above. “Set LSB = ‘H’”
0 -
Belleve, to better understand your visual example, how is this data represented structurally, in code?0 -
Bahman Eslami said:This could be really interesting when it's not only for one script. Otherwise it's not called a type design software, maybe Latin type design software? Latin contains more procedural constructions when it comes to roman capitals and miniscule. But when we deal with handwritten typeface in Latin still there are certain patterns which are constant across a family but could not be defined by the method you're mentioning. Of course it might help to start a family on a certain construction and then work on details manually.John Hudson said:Ideally, the structural description is extensible, and not in any way script- or style-specific. Common libraries of structures for well-established styles — e.g. Latin serif type — could be shared, but it should also be possible to create new structures, using a smallish set of statements.Dave Crossland said:Nina Stössinger said
“Set LSB = ‘H’”
Belleve, to better understand your visual example, how is this data represented structurally, in code?construction: [ {type: "polygon", points: [[x1, y1, "zp1"], [x2, y2, "zp2"], ......]}, {type: "save", name: "E", unicode: 0x45} ], constraints: [ {type: "distance-y", z1: "zp1", z2: "zp2", value: { type: "equation", expression: "cap"}}, {type: "distance-x", z1: "...", z2: "...", value: { type: "kriging", masters: [...]}} ]
0 -
I've been thinking a lot about this and I think there's quite a lot of mileage in it. Things like METAFONT failed because they were entirely constraint-based and lacked the visual side, but on the other hand, visual editors could be usefully supplemented by adding a constraint system.
For instance, it would be great to be able to declare a stem width constraint, and then moving the points on one side of the stem would automatically move the points on the other. Transformations could then also respect the constraints, so e.g. making a glyph 20% wider wouldn't stretch the stem widths by 20%. (My biggest gripe about visual editing software.)
I actually have a lot of the pieces of this in place for Glyphs. I already have a plugin which implements a constraint solver (although for a completely different purpose); Georg has pointed out that there's a lot of overlap between the idea of declaring glyph constraints and providing TrueType instructions - at least for simple constraints; I'm not sure about e.g. proportions between points - so there's already some kind of a UI in place for this; the only remaining issue is knowing when to run the solver and move the points around. That may actually require quite a bit of support from the editor to call the constraint system back every time the points move significantly, but one way to do things without such support would be to implement a custom Select tool which runs the solver after a drag action.
All I need is time... :-(1 -
This sounds like something I could use. There are a lot of aspects of type where you need to use your eye but a whole lot of other tasks where you don't. My current workaround involves making lots of throwaway glyphs used as instances which are eventually decomposed and thrown out. In other words: a mess.0
-
@Belleve Invis
This is much more clear. The first time I didn't get what you meant by solid works and constraints. When you said procedural I remembered Houdini which is the most powerful procedural software I've ever seen in computer graphics, everything is node based and connecting different variables from one node to another results in different results. I think something like that would be really interesting. What you've described so far seems just part of a much bigger picture. If you could come up with more abstract ideas about shapes and their relations, the results could become more dynamic, maybe. But still I can't see the whole picture you're seeing. Maybe after making some prototypes it would become more clear.0 -
@Simon Cozens
@Bahman Eslami
I'll investigate the feasibility and techniques ASAP. If I decide to do this, it (called Caryll) will be completely open-source, and it will be built on Electron.3 -
Is it?Dave Crossland said:Glyphs 2 has this kind of spacing system, and its quite sophisticated.0
-
I am investigating this, a 2D CAD program which is simple enough to analyze. And fortunately it's open source.0
-
Maybe you should talk to the TruFont devs about bringing your ideas to their project.0
-
Cool. Typography has open technology already defined to do this. Constraints, parent-child relationships, freedom and projection vectors to define measures and moves and interpreters to make it happen.
There are also plenty of superficial pretenders that just work on side bearings because side bearings are always "children" of the glyph extrema with X projection and X freedom vectors. Good luck with yours though, and especially with open sourcing it!0 -
Belleve Invis said:@Simon Cozens
@Bahman Eslami
I'll investigate the feasibility and techniques ASAP. If I decide to do this, it (called Caryll) will be completely open-source, and it will be built on Electron.
will be helpful for that0 -
The technology build for Metapolator is going into a similar direction. There's still some work to do though and Constraint-Solving is not my top priority at the moment. Basically the language used for our CPS (CSS inspired tech) could support it at some point.
My next steps include separating some spinoff libraries from Metapolator and to write documentation for them, to make the technology more visible, interesting and accessible for (future) contributors.
0 -
@Dave Crossland
I think we can directly export SFNT fonts using node-sfnt, a fork of a libeary used by Baidu. However it does not support CFF OTF generation (though reading is okay) and feature tables yet, but we can make it support. The building script of Iosevka uses this library to "combine" outlines, features and metadata.
0 -
Basic concept about the properties of a on-curve control point. It's simply an adoption of the Hobby spline used in METAFONT. (spiros are a bit too complex and too "exotic" for most type drawers.)
0 -
You'll find that most type drawers find Hobby splines at least as exotic as spiros: most spend their time working almost exclusively with cubic Beziers, and occasionally with quadratics if they do any native TTF work.2
-
John Hudson said:You'll find that most type drawers find Hobby splines at least as exotic as spiros: most spend their time working almost exclusively with cubic Beziers, and occasionally with quadratics if they do any native TTF work.I’m definitely in the too exotic category. I’d rather just keep doing what I’m doing than pile on more software, more parameters, and another type of spline that isn’t the type used in the final fonts.0
-
@John Hudson
@James Puckett
However Hobby's spline is just cubic Bezier curve with some handles not explicitly assigned. You can simply use this in the convintional way. When a user switch a handle into "implicit" or "directional", the Hobby-solver will be activated and solve the best position of the handles.1 -
Belleve Invis said:When a user switch a handle into "implicit" or "directional", the Hobby-solver will be activated and solve the best position of the handles.0
-
Simpler is better than more complicated and evolutionary is better than revolutionary until you've proved that evolutionary isn't enough. You don't need to build a whole new font editing engine based around Hobby splines and setting tension and so on.
Start simple: take an existing font editor and add a simple constraint solver to the points. Don't even worry about the off-curve points yet, add that later. You can build something useful fairly easily.
Look, here's a proof of concept - I want to make stem 2 and stem 3 the same width as stem 1, while keeping stem 1 in place, the top right corner of stem 2 fixed, and the right-hand points of stem 2 and stem 3 aligned.3 -
-
And here's my version, now with some Glyphs UI for constraint setting.
Still at proof-of-concept stage, but looking a bit useful already.3 -
@Simon Cozens
Looks good, but I do not have a Mac so I cannot enjoy it
Currently I am creating a serializer/deserializer of SFNT called otfcc (github: https://github.com/caryll/otfcc) with Clerk Ma. It will be the most important underlying power of Caryll.0 -
@Simon Cozens I like that, any progress on it?
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 618 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports