Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for proportional fonts #24

Closed
matj1 opened this issue Jun 22, 2023 · 7 comments · May be fixed by #25
Closed

Support for proportional fonts #24

matj1 opened this issue Jun 22, 2023 · 7 comments · May be fixed by #25

Comments

@matj1
Copy link

matj1 commented Jun 22, 2023

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:

text in Recursive Mono Proportional having wrongly placed glyphs

This is my configuration:

Family Name: Proportional

Fonts:

  Regular:
    MONO: 0.25
    CASL: 0
    wght: 425
    slnt: 0
    CRSV: 0

  Italic:
    MONO: 0.25
    CASL: 1
    wght: 425
    slnt: -5
    CRSV: 1

  Bold:
    MONO: 0.25
    CASL: 0
    wght: 750
    slnt: 0
    CRSV: 0

  Bold Italic:
    MONO: 0.25
    CASL: 1
    wght: 750
    slnt: -5
    CRSV: 1

Code Ligatures: True

Features:
- ss09
- ss10
- ss11
@arrowtype
Copy link
Owner

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: 0 in the config.

image

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.

arrowtype added a commit that referenced this issue Jun 22, 2023
@arrowtype
Copy link
Owner

Okay, I was able to solve a good chunk of this in the proportional branch ... have a look and test it, if you want.

image

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 calt feature, 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: False in the config, and then activate the dlig OpenType feature in your code editor, if your code editor allows you to use OpenType features.

@matj1
Copy link
Author

matj1 commented Jun 22, 2023

That 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.

@arrowtype
Copy link
Owner

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 calt is applied / Code Ligatures: True is 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, calt is 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. calt controls useful things like applying the best shape of a letter, according to what is adjacent to it. For example, you might use calt to use a more-compact "f," without an overhanging hook, when it is followed by an ascender.

dlig is 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, dlig is 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 calt feature, 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 controls calt. 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 calt feature, in place of dlig but also in place of all other features, including kern. 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 dlig to calt, 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.

@arrowtype
Copy link
Owner

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.

@matj1
Copy link
Author

matj1 commented Jun 23, 2023

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.

@matj1
Copy link
Author

matj1 commented Aug 14, 2023

It works and I have nothing else to add to this, so I will close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants