Jason (jcreed) wrote,

Geoff's post rembinds me that I'm still really curious what might be possible with different font languages or different font editing programs or whatnot. Having worked with both METAFONT and "visual" editors like Fontographer and FontForge, I find it really hard to imagine going back to the sluggish-feeling edit-view-debug loop that METAFONT entails, even considering the expressive power it provides. I can't even conceive of doing something like Grassoline or Drivin Me Nuts in METAFONT -- they're not designed at all, really, just drawn. Hastily ketched, even. But even with Slavkäppen and Kenosha, "serious" attempts at typefaces, where I'm consciously reusing serifs and loops and carefully tweaking things and trying to insure consistency, my measure of consistency is as often "ok, this looks about right here" as "ok, this stem as 100u wide, and this counter is 90u wide, as it should be". Although it is the latter sometimes! "Reused" features are often tweaked beyond recognition as soon as I drop them into a character to accomodate to their context.

I'm not sure where I'm going with this...

But I would like to play with a tool that was some intermediate thing between a visual bezier editor and a programming language. If I could assign "roles" to points and run programs that depended on those, that would be cool.

It should be remembered, I think, that even the way that basically every cubic-spline editor works --- i.e. there are a bunch of on-curve points that "own" the preceding and succeeding off-curve points, and on-curve posts may be "curve" points if their control points are colinear with each other, or "tangent points" if their control points are colinear with adjacent on-curve points, and "corner" points otherwise --- is still a somewhat arbitrary solution of how to describe cubic-splines, much less all two-dimensional shapes.

In fact, it seems entirely reasonable to think of the "curve-tangent-corner" structure as expressing (very) "little language" that is "compiled down to" raw bezier spline segments. It doesn't provide the "programmer" with any more or any fewer "programs" than the lower-level language does, since you could always use corner points for everything. But it does let you impose constraints on yourself that change the topology of design-space a little. There's real perceptual meaning to a point being smooth rather than angular. If I want to nudge one control point south while maintaining that invariant, then making it a "curve point" does exactly that.

Great, so what? We could say that bezier curves themselves are programs that get compiled into raster images. Doesn't seem to get us much mileage. But: I think I can actually start to imagine reasonable alternate languages that would sit at about the same place in the hierarchy as "curve-tangent-corner", i.e. things that produce raw bezier curves, that can still be edited in a direct, wysiwyggy sort of way. Like, it would be nice to just declare constraints (like, minimum-distance requirements) somehow, not for the purposes of hinting, but for actually contorting design space beneficially.

The main problem I worry about is designing a system of constraint expression so that you can actually unambiguously figure out what all the constraints mean and produce an output spline. In METAFONT, there are straight-up error messages when your linear constraints outnumber your variables and you get inconsistency. There's something conversely pleasing about curve-tangent-corner, in that these problems can't even arise: you can't arbitrarily add constraints, there's a limit to them, so you can never have too many. Although, as a footnote, I should add that FontForge, if you make a point a curve point, it doesn't immediately enforce the constraint. It sometimes takes jiggling one of the control points to snap the other one into collinearity.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded