Howdy, Stranger!
Categories
- All Categories
- 39 Introductions
- 3.6K Typeface Design
- 764 Font Technology
- 1K Technique and Theory
- 588 Type Business
- 435 Type Design Critiques
- 526 Type Design Software
- 30 Punchcutting
- 132 Lettering and Calligraphy
- 79 Technique and Theory
- 53 Lettering Critiques
- 461 Typography
- 289 History of Typography
- 111 Education
- 61 Resources
- 479 Announcements
- 74 Events
- 104 Job Postings
- 147 Type Releases
- 153 Miscellaneous News
- 259 About TypeDrawers
- 52 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
Options
A new approach to spacing?
Simon Cozens
Posts: 724
I've often found it strange that there's a big impedance mismatch between the thing that we want to do when spacing - to set the distance between a pair of glyphs - and the three knobs that we have to twiddle to set that distance - RSB of the left glyph, LSB of the right glyph, and a kerning pair. It's as if you want to set the temperature of a shower, and you have a cold tap, a hot tap, and a mixer tap. (Oh, and the hot and cold taps affect other showers too.)
Yes, I know about spacing key letters, but I still find myself scratching my head about which taps to open and close when /r/s is too loose but /t/s is too tight and /t/n and /r/o look kinda OK and...; and besides, sidebearings and kern pairs are implementation details. Actually I shouldn't have to care about these things - I just want to set the distances!
So, I realised that we can just tell the computer the distances we want, if we express those distances like so:
This is a set of simultaneous equations, and computers are good at solving equations. We can even get the computer to find the best solution, by finding the case where the total of the squares of the kern pairs is at a minimum, meaning that kerns are only there if they need to be.
I did a few tests in Mathematica, and it gave me pretty similar numbers to the ones I had come up with using the normal approach. So I wrote a UI which lets you drag or nudge glyphs around, and it solves the equations for you:
Is this a crazy idea? A useful idea? A useful crazy idea? Or something else?
Yes, I know about spacing key letters, but I still find myself scratching my head about which taps to open and close when /r/s is too loose but /t/s is too tight and /t/n and /r/o look kinda OK and...; and besides, sidebearings and kern pairs are implementation details. Actually I shouldn't have to care about these things - I just want to set the distances!
So, I realised that we can just tell the computer the distances we want, if we express those distances like so:
dist[o,o] := 76 -> 76 = RSB[o] + LSB[o] + kern[o,o]
dist[o,n] := 108 -> 108 = RSB[o] + LSB[n] + kern[o,n]
dist[n,o] := 97 -> 97 = RSB[n] + LSB[o] + kern[n,o]
center o -> LSB[o] = RSB[o]
...
This is a set of simultaneous equations, and computers are good at solving equations. We can even get the computer to find the best solution, by finding the case where the total of the squares of the kern pairs is at a minimum, meaning that kerns are only there if they need to be.
I did a few tests in Mathematica, and it gave me pretty similar numbers to the ones I had come up with using the normal approach. So I wrote a UI which lets you drag or nudge glyphs around, and it solves the equations for you:
Is this a crazy idea? A useful idea? A useful crazy idea? Or something else?
7
Comments
It is a good thing though that you are thinking and exploring. That's how progress happens.
George seems to think this is taking away the human element from spacing, and that's a bad thing; but that's not what I'm doing. (Meanwhile, Ramiro thinks this isn't taking away the human element from spacing enough! I have played with autospacers and I agree they're pretty cool. But you still need to tweak the output.)
I'm not talking about either a semi-automated or a fully automated approach to spacing a font. This is still entirely a manual approach to determining the space between glyphs; distances are set by a user determining the appropriate spacing by eye and then dragging or nudging the glyphs around, not by an algorithm. In fact, that's precisely the point - you're actually setting the spacing, rather than setting a combination of interwoven parameters which together combine to set the spacing.
And this knows nothing clever about the fonts other than the fact that LSB + RSB + kern = distance, which is just as true for round rounds as it is for flat rounds. So I'm not sure the choice of example is relevant. If you need to open your rounds up, just drag them further apart.
This is quite awesome, but not fully implemented as a plugin for a font editor (maybe simon can do that): Fitting Room
https://github.com/skosch/fittingroom
http://www.aldusleaf.org/fittingroom/
Also, a new autospacer will be released next month at ATypI.
It works really really well, although it is only for spacing, not kerning. Maybe both approached can be combined to complement each other.
At the same time, Spaceman is too dumb, because pairs are not independent. /h/a spacing does affect /n/s spacing.
And I guess this is where the interface of both tools falls down: it's hard to know from a simple drag if you're trying to make a general adjustment (tighten up all glyphs with this shape) or a specific one (tighten up this particular glyph pair).
So probably the best way is with a two-pass approach: set the general spacing first, then fine-tune the details. Which, I suppose, is the spacing method we've been using all along.
I think I may have just convinced myself I'm wasting my time.
More estimates make better association of shapes, but also increase memory usage.
FittingRoom's web user interface is not very good, but the concept is really powerful.
Having a better user interface for it may allow better test of its true power.
Are you talking about Andrés Torresi's spacing tool? Will it just be announced at ATypI, or will it be available publicly? From the YouTube video he posted on Twitter it seems promising.
Very true—but I’m afraid this will fall on deaf ears for all those who believe that setting the spacing and kerning of a font, is first and foremost a creative activity to be done by an artist, and not a parameterized optimization process to be done by a computer and to be managed by a smart designer.
If the aim is to minimize the total number of kern pairs in a font, then spacing and kerning are interdependent. Because of this, a tool that only changes kerning is of limited value, because it doesn’t change spacing—while a change in spacing might be needed to reduce the total number of kern pairs. Also, a tool that only changes spacing is of limited value, when it is not informed about how a change in spacing will reduce or increase the total number of kern pairs. So, setting the spacing of a font, and setting the kerning of a font, cannot be done independently—if the aim is to minimize the total number of kern pairs.
Type design should be scientific.
As long as we have a text layout technology that handles spacing in two steps, I see no inherent problems with font development workflows that also handle spacing in two steps.
Should the left side of c, d, e, o and q all be grouped into the same kern class? Should they be drawn and spaced to facilitate this? Yes and no, but my inclination is to draw them individually, rather than make a cookie cutter that homogenizes them.
You might want to consider that, before electronic typesetting, spacing was entirely a matter of establishing correct and well-balanced sidebearings. There was nothing else available. Yes, there were inevitable spaces after T, V, etc., and small holes before periods and commas after creation letters, but otherwise everything worked. Not all fonts were as well cast as Jenson's "Eusebius" type, but the best fonts rose to that standard. Look, too, at the original Bauer Futura specimens.
They started with the lowercase and fit the right sidebearings of the caps to the most limiting combinations. The cap-to-cap spacing was not given much consideration in the casting. The spacing of all-cap lines was done by the compositor.
I am not suggesting that we do exactly the same as in the days of metal, as our requirements have changed, but carefully considered sidebearings will eliminate the need for most kerning adjustments, especially in the lowercase. You can greatly help the cap-to-cap fit by adjusting the left sidebearings, though this will not take care of the combinations that leave the largest holes. If your font needs a lot of added kerning pairs to make the lowercase work, you're doing something very wrong. Text fonts with a lot of lowercase kerning adjustments make for difficult reading, as they never have a predictable rhythm.
I doubt this process can be automated, at least not fully. Too many letters require individual treatment depending on their design: g, s, t, j, z, q, and sometimes r. If you are interested in making good type, why would you want to? Would you automate the drawing? Is the white space any less important?
This interdependence doesn’t presume anything like that. It exists irrespective of which human being, or what tool, sets the spacing/kerning of a font. Of course, an experienced designer can do a much better job than an inexperienced designer—but that is not the point. If an experienced designer’s aim is to minimize the total number of kern pairs, he will, when he creates the spacing of a font, because of his knowledge of the relationship between spacing and kerning, knowingly or unknowingly, consider kerning when he creates spacing—which is in line with this interdependence. However, I doubt whether an experienced designer is able to create the optimal spacing/kerning for a big font (i.e., to minimize the total number of kern pairs); a human being is no match for the processing power of a computer.
Indeed. This could be called the current tradition. But in a future with “a new approach to spacing”, I see no inherent problems with font development workflows that handle spacing and kerning in just one step. Like in a traditional two-step approach—in a one-step approach, it is possible to create a preliminary spacing for a font (and if the designer wants, he can just ignore the kerning which has been generated along with this preliminary spacing). Especially when the creation of spacing and kerning has been automated, it is easy to create many preliminary spacings during the whole process of designing a font—each approaching the final spacing of the font more and more.
When the creation of spacing/kerning has been automated, the creative (non-automated) aspect of setting the spacing/kerning, moves from creating spacing/kerning “by hand”, to setting the parameters of the tool involved. Both doing this “by hand”, and doing this with a tool—is a trial-and-error process, which lasts until the designer is satisfied with the results. (Of course, during such a trial-and-error process, the designer can decide to change the shape of some glyphs to get more satisfactory results. In this way, the spacing and drawing of glyphs can become interrelated.)
A good spacing automation tool will give any glyph an individual treatment when needed, because it would consider the design of each of the individual glyphs of a font. In addition, it would have parameters a designer can set to (fine) tune the spacing in the way he wants. A good spacing automation tool wouldn’t have any “preconceived” spacing for any glyph—and if it would, it would be set in a parameter which can be changed by the designer.
A good spacing automation tool should automatically create kern classes. It should group glyphs into kern classes based on their exact design, and based on the way the parameters of that tool are set by the designer.
I believe that the creation of spacing/kerning can be automated, and that its results can be good. Why automate spacing? To save time for other activities; to make the whole process of creating a font more efficient. This discussion is about spacing, not about automating the drawing of glyphs.
Sometimes people suggest they are designing white space. If they mean they are designing the faces in the image below, then they are, in fact, doing the same as designing the vases in the image below—they only do it from a different perspective. If they mean they decide what the spacing and kerning of a font should be—then they can, when using a spacing automation tool, still do this in a way, by deciding about the settings of the parameters of the tool involved.
John, that’s an interesting comparison—but I see a big difference between your approach and my approach. With “parameters”, I think about all the options which are incorporated into a spacing automation tool by the creator of that tool, like the options or preferences which are incorporated into most computer programs. With “parameters”, I do not think about giving the user of the tool the freedom to set any distance between any (some?) pair of glyphs “by hand”, which is then used as a constraint in some way for the distance between some other pairs of glyphs in the font concerned. This last approach is much more near to “doing the spacing by hand”—and I would call this something like “assisted manual spacing”, instead of “auto-spacing”. Perhaps the difference between the two approaches is not a difference in kind, but a difference in degree—so there may be a continuum with different degrees of doing the spacing manually/automatically.
Beau, the spacing automation tool that I envisage, minimizes the total number of kern pairs in a font. You seemed to have missed that.
_____
Ben, I think we're talking now about interfaces for parameterisation. For me, it seems most intuitive for an interface to have a visual component, since spacing is something that is ultimately to be consumed visually. Yes, it might be possible to adjust an autospacing algorithm by entering numeric values for parameters, but if I can define what I want visually that seems to me a good interface.
This approach makes sense in a tool that only changes/creates kerning, and not spacing. It is a smart way to replicate, in a way, the traditional two-step approach for spacing/kerning. However, when considering a tool that creates/changes both the spacing and kerning simultaneously—such an approach comes at a price (if the aim is to minimize the total number of kern pairs in a font).
By setting the distance between certain key glyphs manually, the algorithm meant to reach the optimum of a minimal number of kern pairs in the font, may not be able to do so—because it does not have the freedom to change the distance (both spacing and kerning) between all the glyphs of the font. In other words, setting the distance between certain key glyphs manually, is a recipe for sub-optimization.
Of course, the ‘damage’ may be limited, when an experienced designer sets such key glyphs manually. Nevertheless, why limit the algorithm to create an optimum, why forego minimizing the total number of kern pairs in the font, why believe that a human being is a match for the processing power of a computer—by setting some distances manually? With such an auto-optimization tool, I would say, it is not up to the designer to decide that specific key pairs should not be kerned.
The designer can still, in an indirect way, set the distances between certain key glyphs—by viewing an example text containing such key glyphs, and then, in a trial-and-error fashion, setting one or more parameters of the auto-optimization tool.
If it is not up to the designer to directly decide about the distance between any two specific glyphs in a font—then an interface like the one of Spaceman, in which it is possible to set the distance between specific glyphs manually, does not make sense. Given the optimization logic of the envisaged auto-spacing tool, it is not a good idea to use a parameter tot set the distance of a specific glyph pair. So, it would make sense, that its parameters would either influence the distances between (potentially) all glyphs in a font, or influence such distances only for specific categories of glyphs in a font.
I envisage an interface in which most parameters are sliders. A slider for the general tightness of the spacing in a font, could be an example of such a slider. If, in the interface of an auto-spacing tool, a sample text and the parameter-sliders are both visible at the same time, and if any change in a slider, immediately leads to a change in the spacing of the sample text—than that would be a convenient interface.
Well, here’s a challenge for both you, John, and the creator of an auto-spacing algorithm. (A) You should describe how you would have done it differently. It should be possible to operationalize such a description into some change in the spacing of a font. Descriptions like “I want it to be more warm”, or “I want it to be more masculine”, may be too vague. (B) The creator of the algorithm should use such a description to create one or more new parameters for the algorithm, which would add the option to change the spacing towards the way you prefer it. (The same could be done with other experienced designers, which may result in more additional parameters.)
That is not what I said. I just wanted to set one pair of side-bearings as fixed so your software is free to do the rest. If it cannot do that, then I have no need for it.
You did not address the issue of spacing for optimum size. It seems all you are interested in is reducing the total number of kerning pairs. This is a small piece of the pie and should not be the controlling point of the whole job. I can understand reducing the total number of kerning pairs but still creating the best spacing and kerning for the intended use of the font. This might be analogous to growing tomatoes. If all you care about is how well tomatoes travel from grower to market then you emphasize the thick skin in your breeding model and pick them early to keep them tough longer. This may negatively affect flavor and texture and even nutritional value but get you fewer damaged tomatoes, and make more money. If you care more about what the consumer wants, you need a different approach. [Notice the growth of non-GMO organic locally grown vegetables today.]
Back to type. A software program can efficiently process lots of data but only give a result that incorporates the variables submitted and weighted. If the human who designs the software leaves out variables in the process or weights their value errantly, the result will be biased in a certain direction. The software engineer can always point out that the numbers must be correct because they were calculated by a computer but if humans do not rigorously question the methodology, it cannot be assured that the outcome is the best possible for the desired affect. We should always keep the door open to inquiry.
By setting the distance between certain key glyphs manually, the algorithm meant to reach the optimum of a minimal number of kern pairs in the font, may not be able to do so—because it does not have the freedom to change the distance (both spacing and kerning) between all the glyphs of the font. In other words, setting the distance between certain key glyphs manually, is a recipe for sub-optimization.
Not necessarily. You are presuming that the action of manually setting a desired distance for key pairs means fixing how that distance is achieved in the eventual spacing/kerning. Again, I'm talking about an interface, a way for the designer to intuitively communicate to the autospacer what kind of spacing he or she wants. In fact, I don't care how the tool goes about achieving that spacing, or how it represents it in the font data, only that the output isn't something different from the spacing that I want. If the tool can achieve that spacing most efficiently by adjusting overall default spacing and hence minimise kerning, that's fine.
I am reminded of a comment that Eliazer Kohen, the inventer of OpenType made to me: as soon as you have a heuristic, you need another heuristic to correct the output of the first heuristic. At some stage, I always want to turn off the heuristics and correct the output myself, so I favour automation that produces editable results (e.g. the new autohinter in VTT), because I know that any auto tool may sometimes produce a result that I don't like and which I am not willing to accept. Yes, I can try to spend time with the maker of the tool to refine the process to achieve what I want, but a) I might not have time, because I use tools in production, often with deadlines, and b) what I want might not be what all my colleagues want, so we come back again to needing to inject personal preferences into the tool settings, and not just at the level of 'looser' or 'tighter', but how particular shape relationships are handled.
I responded to John’s description, Chris, and left your description in the quote as context information.
What I want is a font to have optimal spacing/kerning. I think this can be achieved by creating spacing for a font that needs the smallest total number of kern pairs in the font, given the values of the parameters as they have been set in the auto-spacing tool. So the parameters can be used as the “controlling points” to create the spacing as the designer wants it. For every general variation in spacing of a font that most designers consider to be relevant, a parameter should be available to set that. The fact that I do not mention all those parameters, doesn’t mean they are irrelevant.
If you don’t agree with minimizing the total number of kern pairs as the optimization goal—you might choose another optimization goal, like minimizing the average absolute kern values. And if you prefer to choose an optimization goal in which the kerning will be ignored, that’s fine too—although then the number of kern pairs might explode. I just happen to believe that minimizing the total number of kern pairs, is the best optimization strategy.
Not at all. I presume that the action of manually setting a desired distance for key pairs (and at the same time not wanting any kerning for those key pairs), fixes this distance for these key pairs, i.e., it makes this distance permanent. So, for instance, if you manually set the distance between “o” and “n” to be 100, the optimization algorithm will not touch that distance; it will keep that distance at 100. In this context, it is irrelevant how this distance is achieved in the eventual spacing/kerning. (In the second paragraph of the quote above “Not necessarily”—I do not speak about a user interface, but about the fact, that manually setting some distance values, limits the optimization process.)
The challenge was primarily meant to show a general way to improve the versatility of an auto-spacing tool—not to give you a time-consuming task. It was meant to show a way to get additional fine-tuning options for such a tool, which may be useful for any designer—not to ‘bake’ someone’s personal preferences in the tool. If it would be possible to describe your preferred handling of particular shape relationships in a general way, then it may be possible to improve an auto-spacing tool by creating an additional option which covers such handling.
If you consider the possibility to manually set a desired distance for key pairs, more important than the optimization goal of minimizing the number of kern pairs—then the auto-spacing tool should allow that. Also, when it would be possible to manually set distances between glyphs, it would make sense to allow this directly in the sample text in the interface. This caveat would apply: The more manually set distances in a font, the less optimal the results of the auto-spacing tool may be from the perspective of minimizing the number of kern pairs.