Family Stem Weights Calculator

Jacques Le Bailly

@Linus Romer
Thank you very much ! That is awesome.

Dave Crossland

David Berlow's comment (http://typedrawers.com/discussion/comment/13824/#Comment_13824) makes more sense to me after our discussions subsequent to commissioning Amstelvar from him. What he said seems prescient given the variable fonts technology that was released since then, but in fact seems to be repeating the concepts of the predigital type industry.

In a font with optical size and weight axes, type designers can set their Regular's stem widths at various optical sizes, and then Bolds' stems appropriately and differently. The typical user's pt size scales (eg, 6pt, 7, 8, 9, 10, 11; 12, 14, 16; 20, 24, 28, 32; 38, 42, 48; 56, 64, 72; 96, 120, 144) have contigious sets within the scale, and within each set or group the stems can be interpolated on a straight line, and together these approximate a curve. This means that type designers don't need to set every one; but for the stems they do set, they can then specify a Bold stem sizes for each that corresponds, that are different in ratio/proportion, as appropriate. 

Then, a Width axis adds a whole 3rd dimension to the design problem. And that's for Sans! With serif designs, then not only stem widths but serif heights and bar widths come into play, because those when combined create stroke contrast and that needs to be different at different sizes. 

With Amstelvar, there are independent axes which control individually all those aspects. Really there are 4 aspects: black form horizontally and vertically, and their concurrent white (or negative or transparent) forms, horizontally and vertically. These together are what David calls "parametric axes", and has named script agnostically as "x opaque" and "x transparent" and "y opaque" and "y transparent". Opaque for black forms, transparent for negative shapes. X and Y for horizontal and vertical. (But it doesn't matter what you call them too much

Their scale is per mille of em, so the user can set them in a straightforward way, because they relate directly to the typographic dimensions they are dealing with (text box sizes, gutters, line heights, etc)

By drawing the central default design, then the Min and Max masters for those 4 core parametric axes, it's merely a matter of dialing in their right combination to get the appropriate stroke weights horizontally and vertically for every optical size of Regular and Bold and every other named weight at any width. That's what DB calls "blending," like it was oil painting. 

So, I guess type designers making Parametric Axes fonts will need a better tool for blending, for defining those approximated curves as "ready mades", which users can take if they want to get going, or use as a basis for deriving their own, perhaps with the same tool.

The tools shared in this thread will doubtlessly be relevant to this effort, and of course if I'm involved in such a tool, it will also be shared with everyone with source code  

Jacques Le Bailly

I basically agree with what David Burlow is saying. It is all about size, function and intended usage. 

In my workflow I often use graphs and schemes like Pablo’s or Lucas’ as a starting point to give me some directions to define the weights. Depending on the design, sometimes even a straight axis is sufficient to start with. 

Next step is an extensive proofing process. Proofing will always be focused on the preferred size range and intended use. For example, at the moment I am working on a serif typeface intended for longer texts of approx. 8-14 pt. in print. Proofing is done with and without hints. Most cases are CFF. How wide the weight range will be and how many subdivisions there will be needed is depending on the initial concept and/or the intended typographic application. When this is done, I will do a control test on screen. 

Nowadays a lot can be automated and there are a lot of different theories, but in my opinion the designer should always test, proof and (re-)define the best possible “default” defined weights. Each design has it’s own color, expression, quirks etc. I don’t believe there is a theoretical model that can solve all of this. The erratic nature of type, the technique used to display text (print, screen etc.) add to a lot of variables. Extensive proofing and redefining the “default” weight might feel like backwards engineering, but in the end it will give you better results. Use your eyes. Train your eyes.

 

By choosing new “default" weight/width evolution curves you will end up with a curve, line that will not fit in Pablo’s or Lucas’ curves anymore, but will more natural and custom for your design.

If there would be a tool that would visualize/generate the behavior of a design in different sizes, displays, hinting (ttf vs otf, mac, windows etc.), it would be awesome. 

Sometimes I run into a kind of thought problem with Google Fonts. There are so many users, that you actually do not know how the typeface will be used. Therefore I am very interested in Amstelvar to see how this is solved. And the use of parametric axes.

Actually I am also interested in the (future) capabilities of VAR fonts. Could those weight/width evolution curves be implemented as being something interactive? Thus actually turning the question 180˚. It would become very interesting. Example. You read an article on your phone. Default size. You zoom in. If the software of your phone could tell the font software what size the text is, surrounding light, reading angle etc. You would be able to generate on fly “perfectly” readable text for any circumstance. 

So basically, starting with generated numbers/curves is a good help. Test/proof and redefine the weight/width evolution curves by setting the best “default” weights. And never add a zillion default defined weights because you can. Everything you do should have a typographic reason and should be a solution for the initial typographic issue or problem you wanted it to tackle in the first place.

My 2¢

jeremy tribby

Building off the work of @Linus Romer I've turned this into a Glyphs script as an excuse to learn using Vanilla to build UIs -- so you can apply the steps directly to your instances within the app. You can find the script here. It does not include the third point of interpolation discussed by Linus here but this is an early draft of the script (more than a few places for cleanup in the code) and pull requests are always welcome  

AbrahamLee

Nice work, Jeremy! Way to take the next step in making it possible to compare each strategy against another. The only thing I'd probably recommend to really nail this down is to make the row values editable (and possibly highlight them red so you know they were edited), so that if the user liked the general progression, but wanted to tweak any values to taste, they could. Great job!

AbrahamLee

Oh, and as a coding suggestion, it's probably better if you don't call any variables "min", "max", etc. since those are reserved function names.

Rainer Erich Scheichelbauer

For reference, all the methods described above (linear, Pablo, Schneider, Abraham and Lucas) are now available in Interpolation > Insert Instances in the mekkablue scripts for Glyphs: