Character Alignment Issue in Inter 4.1 (******999 and similar patterns)

[subhankar-das2]

Describe the bug
Certain character combinations in Inter v4.1 appear visually misaligned when rendered. This is especially noticeable when using six or more special characters (such as * or @) at the start of a string, followed by capital letters or numbers (e.g., ******999 or @@@@@A12). The issue creates a visually jarring experience and affects UI fields where such formatting is common, like masked account or card numbers.

To Reproduce
Steps to reproduce the behavior:
This issue is also easily visible and reproducible in the Google Fonts font preview interface.

1. Use Inter v4.1 from rsms.me (official site).
2. Render a string like ******9999 or @@@@@A12 in any text-rendering environment.
3. Ensure that Contextual Alternatives (calt) feature is enabled (default).
4. Observe alignment glitch between special characters and following alphanumeric characters.

Expected behavior
All characters, including special characters followed by capital letters or numbers, should align properly and render without irregular spacing or jumps.

Screenshots

Environment

• OS: macOS, Windows 10, iOS, Android
• App: Chrome, Firefox (also applicable in apps like Figma, React Native, etc.)
• Font version: Inter v4.1 (from rsms.me)

Additional context
The issue is not observed in earlier versions of the font (e.g., Inter v3.x). Upon investigation, it seems linked to the Contextual Alternatives (calt) feature, which is enabled by default in v4.1. Disabling this feature or enabling the Case-sensitive forms (case) feature mitigates the issue, but both require platform-specific implementation. A custom modified font with adjusted feature defaults has been created as a workaround. However, a more permanent fix in the official font would be helpful.

[kenmcd]

Duplicate issue. u+2022 moves upwards when followed by a digit #442 4.0-beta9g - 4+ consecutive characters in contextual alternatives #594 Misalignment of bulletpoints when using inline #679

The font developer has stated that this is "by design" and changes are "not planned."

As you have discovered disabling calt is the way to handle this when needed.

Note: you can also apply case and it will override calt and that will have ****** all the same size.

You could also "freeze" the case feature, but that could cause unacceptable alignment issues with some of the punctuation with the lowercase characters.

[subhankar-das2]

Thanks for the detailed explanation.

On a related note—do you happen to know if there’s a way to disable the calt or (enable case) feature programmatically on Android (Jetpack Compose) and iOS (SwiftUI)? Currently, we’re using modified font files with case enabled as a workaround, but we’d prefer a cleaner solution if there's a reliable way to override these features in code.

Would appreciate any guidance or links.

[kenmcd]

I do not know anything about those APIs.

SF Pro does have both calt and case so I assume they have a way to affect those. It also has both /asterisk and /asteriskoperator and case affects both of them.

I do not know what Android is using these days, but the old Roboto (old android) and Roboto Flex do not have either calt or case - so I have no idea if it is possible to affect.

Check the APIs.

[Daedren]

Thanks for the detailed explanation.

On a related note—do you happen to know if there’s a way to disable the calt or (enable case) feature programmatically on Android (Jetpack Compose) and iOS (SwiftUI)? Currently, we’re using modified font files with case enabled as a workaround, but we’d prefer a cleaner solution if there's a reliable way to override these features in code.

Would appreciate any guidance or links.

I've hit this issue some time ago, and there is a.. simple way to evade this calt problem if you want a short-term solution. phone.replacingOccurrences(of: "*", with: "\u{EE71}")