“Procedural” design software concept?

Belleve Invis
Belleve Invis Posts: 269
in Type Design Software
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

  • John Hudson
    John Hudson Posts: 3,230
    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.
  • Craig Eliason
    Craig Eliason Posts: 1,440
    You might want to look into how Glyphs 2 handles "smart components"
  • Bahman Eslami
    Bahman Eslami Posts: 73
    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.
  • Belleve Invis
    Belleve Invis Posts: 269
    @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.
  • Bahman Eslami
    Bahman Eslami Posts: 73
    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
    John Hudson Posts: 3,230
    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.
  • Nina Stössinger
    Nina Stössinger Posts: 155
    edited January 2016
    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’”

  • Dave Crossland
    Dave Crossland Posts: 1,431
    Nina Stössinger said
    “Set LSB = ‘H’”
    Glyphs 2 has this kind of spacing system, and its quite sophisticated. 

    Belleve, to better understand your visual example, how is this data represented structurally, in code?
  • Belleve Invis
    Belleve Invis Posts: 269
    edited January 2016
    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.
    You've misunderstood my idea. The key feature is that, you draw some letterform first, and then add metric or geometric constraints (like "colinear") to it. The constraint solver will "move" the points to the place they should be, or report a "overdetermint" error if the metrics is incorrect. This procedure is outline- and script-independent, pretty like the drawing feature in Solidworks:

    Dave Crossland said:
    Nina Stössinger said
    “Set LSB = ‘H’”
    Glyphs 2 has this kind of spacing system, and its quite sophisticated. 

    Belleve, to better understand your visual example, how is this data represented structurally, in code?
    Perhaps be saved in some structure like this:
    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: [...]}}
]
  • Simon Cozens
    Simon Cozens Posts: 752
    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... :-(
  • Ray Larabie
    Ray Larabie Posts: 1,436
    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.
  • Bahman Eslami
    Bahman Eslami Posts: 73
    edited January 2016
    @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.
  • Belleve Invis
    Belleve Invis Posts: 269
    @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.
  • attar
    attar Posts: 209
    Dave Crossland said:
    Glyphs 2 has this kind of spacing system, and its quite sophisticated. 
    Is it?
  • Belleve Invis
    Belleve Invis Posts: 269
    I am investigating this, a 2D CAD program which is simple enough to analyze. And fortunately it's open source.
  • James Puckett
    James Puckett Posts: 1,998
    Maybe you should talk to the TruFont devs about bringing your ideas to their project.
  • Deleted Account
    Deleted Account Posts: 739
    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!
  • Dave Crossland
    Dave Crossland Posts: 1,431
    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.
    Electron would be great - I hope the Metapolator and ufoJS libraries by @Lasse Fister 
    will be helpful for that :)
  • Lasse Fister
    Lasse Fister Posts: 8
    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.

  • Belleve Invis
    Belleve Invis Posts: 269
    @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.
  • Belleve Invis
    Belleve Invis Posts: 269
    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.)
  • John Hudson
    John Hudson Posts: 3,230
    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.
  • James Puckett
    James Puckett Posts: 1,998
    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. 
  • Belleve Invis
    Belleve Invis Posts: 269
    @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.
  • Dave Crossland
    Dave Crossland Posts: 1,431
    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.
    "Best" seems unlikely to be true, in that the position of the handles determined by the Hobby solver will not be the same position that a human type designer would determine.
  • Simon Cozens
    Simon Cozens Posts: 752
    edited January 2016
    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.

  • Belleve Invis
    Belleve Invis Posts: 269
    edited January 2016
    Setting up Electron and here's my first window :)

    (powered by Stylus and Vue)
  • Simon Cozens
    Simon Cozens Posts: 752
    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.
  • Belleve Invis
    Belleve Invis Posts: 269
    @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.
  • Miles Newlyn
    Miles Newlyn Posts: 252
    @Simon Cozens I like that, any progress on it?

Categories