Repository navigation
Support for proportional fonts #24
Description
Activity
Hi @matj1, thanks for reporting this!
I don’t know how it hasn’t come up before, but indeed, I have confirmed that you are correct – this script forces everything into 600-unit glyph widths, so it currently doesn’t work well at all to use anything besides
MONO: 0in the config.
I’ll poke around for a few minutes, but I’m not sure if I’ll be able to really dig in and fix this today. I’ll try to update here if I can.
Okay, I was able to solve a good chunk of this in the proportional branch ... have a look and test it, if you want.
The main remaining problem is that you cannot currently "bake-in" code ligatures without deleting the kerning, and having the code ligatures offset to the left in their glyph space. This project bakes-in code ligatures under the
caltfeature, which allows them to be activate by default in many code editors, and easy to control with e.g. VS Code’s built-in toggle for code ligatures. However, that process currently overwrites other existing font features, including kerning. So, the result isn’t great.If you want both proportional glyphs and code ligatures, there is a workaround: Leave
Code Ligatures: Falsein the config, and then activate thedligOpenType feature in your code editor, if your code editor allows you to use OpenType features.Reacted by matj1That was quick. Does it work well apart from calt? Why does calt behave differently than dlig? I expect that, if they offer the same ligatures, they would behave the same.
Does it work well apart from calt?
Yes, it seems to work well overall. Whether code ligatures work depends on whether your editor (IntelliJ, looks like?) allows you to activate arbitrary OpenType features, like
dlig.I’ve now mostly fixed the width issue when
caltis applied /Code Ligatures: Trueis set in the config.yaml. However, kerning still gets turned off when that is set.If you want, please go ahead and try it from that branch, and let me know if you find any other issues!
Why does calt behave differently than dlig?
Hmm, it’s a little hard to know how to answer this without a lot of background info. I’ll try to summarize, partly to help me sort out my thoughts.
There are many different feature tags specified in the OpenType spec. A font maker can put any given font behavior into (I think) any feature tag. However, font tags have intended meanings, and therefore, software treats them differently.
For example,
caltis short for "contextual alternates," and it is supposed to be applied to text by default, by every app, but also be possible for a user to turn off.caltcontrols useful things like applying the best shape of a letter, according to what is adjacent to it. For example, you might usecaltto use a more-compact "f," without an overhanging hook, when it is followed by an ascender.dligis short for "discretionary ligatures" ... basically, ligatures that are fancy, and used for style. An example of this is a ligated "st," which isn’t always useful, but might be aesthetically pleasing in some contexts.In my view,
dligis the more spec-compliant feature tag to use for code ligatures. They are basically fancy ligatures, and people use them out of an aesthetic (or ergonomic) preference, but they shouldn’t be active by default, for the average user.Meanwhile, in fonts like Fira Code, the makers did want code ligatures to be active by default, so they put code ligatures into the
caltfeature, I suppose because it was usually on by default, and seemed to make sense. And later, code editors like VS Code added a "code ligatures" toggle which controlscalt. But, at least VS Code also allows you to control other OpenType features, just in a slightly less obvious way.And now, my immediate problem is that this Recursive Code Config tool works by "freezing" in OT stylistic set features, and then just replacing the fonts’ OpenType code with a premade
caltfeature, in place ofdligbut also in place of all other features, includingkern. But actually, I’m now realizing that it also replaces other useful features, like stuff that allows localized forms for various languages like Dutch, Catalan, Romanian, Turkish, and others.So... I should really try to find a way to be more surgical in my edits to the font features, and only swap
dligtocalt, if possible. But, I haven’t yet figured out how to do that. I’ll test something, and if it works well, I’ll hopefully finish it and push it.Okay, I think I’ve fixed this and improved things, overall, for proportional fonts.
I’ve made a new issue for the separate problem of fully monospaced fonts losing some feature code: #26
OP: please give the branch a try if you can, and if you confirm that it’s working as you expect, I think I’ll merge that PR and close this issue.
The branch works well. I did not notice any wrong kerning with code ligatures enabled with
Code Ligatures: True. Which kerning would be affected? Only that around ligatures or in the whole font? I tried some cases where that would be obvious IMO (specifically:AV C- C->) and didn't see anything wrong. The only unusual thing is that->is slightly longer than its ligature.It works and I have nothing else to add to this, so I will close this issue.
I would like to have a custom proportional variant of Recursive for programming. I used this configurator, set MONO to 0.25, and the result looks wrong.
Please, make it work with proportional fonts too.
The text editor works well with Recursive Sans Linear Static, so the problem is probably that this configurator forces every glyph into the same width. I want that every character would keep its original width.
My variant looks like this:
This is my configuration: