IntegerStemFinder

Another stem interpolation (and extrapolation) calculator with the ability to adjust instances after interpolation and easily find the closest integer (or closest to integer) stem or sidebearing.
Links
Online version:
michaelrafailyk.github.io/IntegerStemFinder
Video demonstration:
youtube.com/watch?v=ei9jeOwSu30
Project page on GitHub:
github.com/michaelrafailyk/IntegerStemFinder
Sources
The idea of editable instances is inspired by a comment of Abraham Lee. The idea of finding the closest integer stem or sidebearing is inspired by a comment of George Thomas. The progression formulas are taken from a comment of Linus Romer and from a comment of Abraham Lee. Interpolation of nonlinear progression with intermediate masters uses the second method from a comment of John Hudson.Features
- Interpolate linearly (multiple masters setup supported).
- Interpolate with equal steps for all weights.
- Interpolate with a progression (multiple masters setup supported).
- Extrapolate linearly (multiple masters setup supported).
- Switch any weight to master.
- Hide any weight from axis.
- Drag the weight by the handle/line to change its position.
- Adjust instance after interpolation.
- Find a closest integer stem or sidebearing.
- Switch between accurate and rounded stems and sidebearings.
- See a visualization of stems and sidebearings.
- See a graph of stem growth curve.
- Compare interpolation strategies using sets.
A complete list of features:
github.com/michaelrafailyk/IntegerStemFinder?tab=readme-ov-file#features
Colors
Black – master.
Green – instance.
Blue – adjusted instance.
Gray – hidden weight.
Defaults
Default weights and their parameters could be predefined in an array in a JavaScript file. Here you can set default axis configuration, such as: amount of weights; weight position (axis range is from 0 to 1000) and name; weight is master, instance, or hidden; stem and sidebearing values for masters.
defaults: [ {position: 0, name: 'Hairline', hidden: true}, {position: 100, name: 'Thin', master: true, stem: 20, sidebearing: 82}, {position: 200, name: 'Extra Light'}, {position: 300, name: 'Light'}, {position: 400, name: 'Regular'}, {position: 500, name: 'Medium'}, {position: 600, name: 'Semi Bold'}, {position: 700, name: 'Bold'}, {position: 800, name: 'Extra Bold'}, {position: 900, name: 'Black', master: true, stem: 220, sidebearing: 50} ]
Implementation
Implemented using HTML + CSS + JavaScript. I'm not very familiar with Java, but I know JavaScript a little better, and also I like an idea that it could be accessed from any device connected to internet. To run it offline, download all three files, place it in one directory, and open the index.html file in any browser. However, I recommend using the online version as it will receive updates if any errors are found.
License
MIT License. You are free to fork / copy / download / modify this tool without any permission. In the case of modifications, all the functions and actions are commented and explained inside the JavaScript file.
Comments
-
Very nice.
Is Abraham’s progression documented somewhere? I’ve never used it, and am struck by how different it is from all the others.0 -
I'm not sure what the initial source of Abraham formula is, but I saw it implemented in steminterpolation by Linus Romer, and in Insert Instances by Rainer Erich.0
-
Abraham's progression and its origin is explained here:
4 -
Thanks, George. I understand the difference now: Abraham is approaching weight progression in terms of significant distinction between neighboouring weights, versus the others looking at proportional progresssion across the weight range.0
-
John Hudson said:Very nice.
Is Abraham’s progression documented somewhere? I’ve never used it, and am struck by how different it is from all the others.
1. The instances are noticeably different on the "light" end of a linear/equal progression
2. The instances are noticeably different on the "heavy" end of an exponential progression
So, the progression I came up with starts linear and ends up exponential. One consequence of this is that the middle of the range tends to be slightly less different from its neighbor. If one reverses this blend, which is what the "Impallari" progression is, going from exponential to linear, then the the extremes are less different and the middle is more different. There's no clear winner here as each has its trade-offs.
One example I have found in the wild (and I haven't really looked much) which follows a similar progression as I proposed is the font family "Traction" published by Schriftlabor, which was released around the same time as I came up with the mathematical form of the progression, though I have no idea if there was any influence, or just coincidence.3 -
I have a typeface close to release, that follows closer to the Abraham Lee proportions than anything else.
But in this case, it is the result of wanting something else, but needing to anchor the regular to a “historical regular,” which is heavier than one might otherwise get, given the number of steps and the weights of the extremes. So the progression is what I would consider unusual, or less optimal, as a result.0 -
needing to anchor the regular to a “historical regular”I have been in this situation a couple of times, but approached it slightly differently: I did a Luc(as) progression across the whole weight range, and then scaled the progression on either side to relocate the calculated regular to the location of the historical regular.
0 -
Question: Why is it that when I view the online tool, the line connecting the instances remains level in all views, rather than showing a curve as in your video demo? I checked in three different browsers and twiddled various parameters, but the line remains flat. (The distribution changes as expected, just not the slope of the line.) What am I missing?2
-
One of the things I like most about this tool is the visualisation of the stem weights and their distances to each other, along the bottom. I have almost always used Luc(as)’s equation, but looking at this visualisation the virtues of the Schneider progression are much more obvious to me than they have been in more abstract calculation tools and graphs.0
-
Kent Lew said:Question: Why is it that when I view the online tool, the line connecting the instances remains level in all views, rather than showing a curve as in your video demo? I checked in three different browsers and twiddled various parameters, but the line remains flat.0
-
Ah, thanks for the clarification. I agree that what I would have expected to be seeing is a stem-thickness curve, so if that’s not what was being mapped in your demo, then it makes sense that you disabled it.I might suggest you update the preview pics & videos now, unless you think you can implement a stem curve in the near future. The current mismatch really does make it seem like the tool isn’t fully working. I’m sure I wasn’t the only one trying to figure it out.That said, thanks very much for sharing your work.1
-
Agree, I updated the preview and video. Thanks for the feedback!0
-
I finally figured out how to correctly display the stem growth curve for a progressions. So the graph functionality is back. I updated all the files, and also updated the preview and video link.
When the graph is standalone, this is easy to draw the curve. But in my case (where graph is integrated right into interface), the solution is to compare the equal-step stems to actual (interpolated) stems for each weight, and then correct each point of graph curve for that difference (between equal and actual).
0 -
I am wondering if there is a way to add an option to scale the positions of interpolated instances if an instance is manually shifted. I have projects in which there is an inherited intermediate master (most often Regular), whose position is somewhat off from the calculated location of that instance. I would like to be able to apply a progression equation in the tool, then manually set the location of the inherited master, and have the locations of the calculated instances on either side of it scale relative to the new distance between the intermediate master and the extremes. [In theory, any manually set intermediate location can be considered a master, and floating locations between any masters should be scaled relative to those masters.]
1 -
John, if I understood correctly, you want to turn intermediate instance (like Regular weight) to master (which become the 3rd master), and have all instances between masters interpolated?
Currently it is possible for linear interpolation only (with equal steps between masters). To switch the instance to master, click on the "Instance" button below the weight name. It will be marked as Master and the color will be black. When you set up 3 or more masters, "Segments" button will be highlighted on the left side.
But if you need it for non-linear progression, like Luk(as) one – not yet, but it will be possible soon. It is already in work, just requires more time for polishing and testing. I'll be back and message here when this functionality will be added.3 -
Thanks, Michael.
Thinking about this, there seem two possible ways this can be done:
1) treat each segment between masters as a distinct progresssion with its own interpolation with a limited number of steps; or
2) treat the overall weight range as a progression, but with portions of it scaled between adjusted master locations.
I think these methods produce different results. The second method is the one in which I am interested (in part because I already have tools that I can use to the calculate the first method).0 -
I made some calculations, and confirm that these two methods produce different results for intermediate instances. In the following test I used Luc(as) progression applied to 8 weights, where Thin and Black are extreme masters, and Extra Light is the second weight. So I observed the percentage of Extra Light relative to segment of Thin (0%) — Regular (100%).
1. Default
Interpolation: Thin-Black
Thin (master): 20 (stem)
Extra Light (instance): 28.25 = 22.92%
Regular (instance): 56
Black (master): 220
2. First method
Interpolation: Thin–Regular + Regular–Black
Thin (master): 20 (stem)
Extra Light (instance): 28.25 = 22.92%
Regular (master): 56
Black (master): 220
3. First method (Regular stem is changed)
Interpolation: Thin–Regular + Regular–Black
Thin (master): 20
Extra Light (instance): 33.13 = 18.75% (percentage is shifted closer to Thin)
Regular (master): 90
Black (master): 220
4. Second method (Regular stem is changed)
Interpolation: Thin-Black
Adjustment: between Thin and Regular, and between Regular and Black
Thin (master): 20 (stem)
Extra Light (instance): 36.04 = 22.92%
Regular (master): 90
Black (master): 220
So, the first method (test 2) produce the same result for intermediate instances until Regular stem is unchanged compared to default (test 1) interpolation. But a difference of the first method could be seen in test 3. The second method (test 4) preserves percentage relation for instances between masters regardless of what the stem is set for intermediate (Regular) master. Looks like it make sense.
@John Hudson, do you think that the second method is better and why do you prefer it? Or are they both considered correct methods? I mean, implementing it is not a problem. The problem is to let the people know what the results they get.0 -
In principle, I prefer the second method, to the extent that I care. Both are reasonable methods. I do not think one can find a likely case in which they will produce radically different results. Just so long as you have an accommodation for this, that is lovely.
(As I am not 100% commited to a single interpolation scheme in the first place, so a small detail in how we patch the schemes when we have to anchor a specific intermediate designed master at specific values is just… not a big deal to me.)
You could theoretically support both! But I can see how that might seem like overkill.0 -
Thomas Phinney said:You could theoretically support both! But I can see how that might seem like overkill.0
-
I have used the first method in the past, but realised that it effectively creates two separate progressions on either side of a pivot master, so you lose the sense of an overall progression between the extremes. What I like about the second method is that you retain the sense of an overall progression. Of course, the proof is in the outcomes when applied to a design.
1 -
Thanks for updating the graph, Michael!I tend to agree with John’s take on the manual adjustment within a progression. There are tools to create two progressions on either side of a fixed master; but one that adjusts the entire progression to incorporate a fixed point while adjusting the overall curve on both sides to redistribute the designated progression across the whole curve would be value added.0
-
John, Thomas, Kent, big thanks for sharing your thoughts and proposing ideas.
I implemented the second method, and now you can add intermediate masters for progressions – one, two, or as many as you need.
I added the additional check. Intermediate master stem should be inside the range between first and last masters stems. If you set the stem that is out of range, or set empty value, this intermediate master will be turned to instance.
Another change: "Segments" button is now renamed to "Linear". I suppose that make more sense now. That button is highlighted for linear interpolation between every pair of masters, and also for extrapolation.3 -
0
-
A small visual fix. Now, when you add intermediate master for a non-linear progression (and stem value and weight position are the same as interpolated), the handle (of stems curve graph) no longer jumps (like in Linear interpolation), but continues to display a consistent stem growth curve. So now the graph of stems curve looks more organic. This improvement doesn't affect any numbers and it is only about visual.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 815 Font Technology
- 1.1K Technique and Theory
- 629 Type Business
- 449 Type Design Critiques
- 548 Type Design Software
- 30 Punchcutting
- 137 Lettering and Calligraphy
- 84 Technique and Theory
- 53 Lettering Critiques
- 496 Typography
- 307 History of Typography
- 116 Education
- 73 Resources
- 509 Announcements
- 82 Events
- 107 Job Postings
- 153 Type Releases
- 166 Miscellaneous News
- 271 About TypeDrawers
- 53 TypeDrawers Announcements
- 117 Suggestions and Bug Reports