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

CoreText: parse features equivalently to HarfBuzz (currently we only parse binary features) #3128

Closed
qwerasd205 opened this issue Dec 26, 2024 · 2 comments · Fixed by #4139
Closed
Labels
font Issue within the font stack (typically src/font)
Milestone

Comments

@qwerasd205
Copy link
Collaborator

The CoreText shaper parses the provided font features using overly simplified assumptions about how font features are specified:

/// Append the given feature to the list. The feature syntax is
/// the same as Harfbuzz: "feat" enables it and "-feat" disables it.
pub fn append(self: *FeatureList, name_raw: []const u8) !void {
// If the name is `-name` then we are disabling the feature,
// otherwise we are enabling it, so we need to parse this out.
const name = if (name_raw[0] == '-') name_raw[1..] else name_raw;
const dict = try featureDict(name, name_raw[0] != '-');
defer dict.release();
self.list.appendValue(macos.foundation.Dictionary, dict);
}

The HarfBuzz shaper uses Feature.fromString which is a loose wrapper around hb_feature_from_string:

if (harfbuzz.Feature.fromString(name)) |feat| {

Despite the CoreText FeatureList.append's doc comments claiming to use "the same" feature syntax as HarfBuzz, this is not the case; the syntax for features passed to hb_feature_from_string can be found in the HarfBuzz docs.

The practical impact of this is that many configs that will work under HarfBuzz will not under CoreText, and it's actually impossible to specify non-boolean features (such as a specific character alternative).

I am willing to implement a parser with proper parity to the HarfBuzz one, it shouldn't be too difficult, but I figure'd I'd open this issue first to keep track of it since I might not get around to it for a couple days.

@mitchellh mitchellh added the font Issue within the font stack (typically src/font) label Dec 26, 2024
@mitchellh mitchellh changed the title Properly parse font features under CoreText CoreText: parse features equivalently to HarfBuzz (currently we only parse binary features) Dec 26, 2024
@ThorstenRhau
Copy link

https://github.com/githubnext/monaspace?tab=readme-ov-file

If I read this feature request correctly it would solve the "cv01" or first character variation (for zero) of Monaspace, right?

I am asking to make sure to not open a duplicate issue.

What I am trying to do is:

font-family = Monaspace Argon Var
font-family-bold  = Monaspace Argon Var
font-family-italic = Monaspace Radon Var
font-family-bold-italic  = Monaspace Radon Var
window-title-font-family = Monaspace Argon Var

font-variation = wght = 450
font-variation-italic = wght = 450
font-variation-bold = wght = 700
font-variation-bold-italic = wght = 700

font-feature = calt
font-feature = liga
font-feature = ss01
font-feature = ss02
font-feature = ss03
font-feature = ss04
font-feature = ss05
font-feature = ss06
font-feature = ss07
font-feature = ss08
font-feature = ss09

font-feature = cv01=1

All the configuration works except for the last line, that contains "cv01".

@qwerasd205
Copy link
Collaborator Author

If I read this feature request correctly it would solve the "cv01" or first character variation (for zero) of Monaspace, right?

Correct, this would solve that problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
font Issue within the font stack (typically src/font)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants