ClearType rendering issue with transformed components (was "Braces are asymmetric for some font sizes")

[ForNeVeR]

For some font sizes (e.g. 16px) braces ([](){}) look asymmetric, the right one may be drawn lower or higher than the left one.

For example, visit this link: https://rsms.me/inter/lab/?size=16&antialias=default and enter braces into the first text line:

Expected behavior
Braces should be symmetric and have the same height/position for all font sizes.

Screenshots

Environment

• OS: Windows 10 1909
• App that renders the font: Chrome
• Display size/scale: 3840 × 2160, 150%
• Version of font: sorry, I don't know; wasn't able to find this information on the font test site

[rsms]

Interesting. This seems to be a Windows-specific issue as I an unable to reproduce in Chrome, Safari or Firefox on mac. I will check on my Windows computer as well, but in the meantime, would you mind trying the following things?

• Check in a different browser like Edge (stable, non-chromium; the one that ships with Windows) and/or Firefox? Do you see the same issue there?
• Turn on variable font (use this link for a shortcut)

[g-cqd]

I get the same issue on :

• Link : https://rsms.me/inter/lab/?size=16&antialias=default
• OS : macOS Catalina 10.15.4
• Inter Version : Version 3.012;git-f93a4a705
• Browsers :

---

• Safari : Version 13.1 (15609.1.20.111.8)

---

• Safari Technology Preview : Release 103 (Safari 13.2, WebKit 15610.1.7.3.2)

---

• Firefox Developer Edition : 75.0b11 & 75.0b12

[be5invis]

@rsms Should be another issue related with transformed component references. This is how GID 1331 shown in VTT:

Note that, this component is also set rounded, so Macintosh may also have problems.

@schriftgestalt is it possible to tell Glyphs not to use transformed components? Font tools really really dislike that. Glyphs could unlink a component if it is trasnformed.

[Felix-MFU]

The experienced the same issue on Sketch (MacOS Catalina). It seems to have to do with the calt (Contextual Alternates feature. It works on capital letters only after letter, but not before it. So the left brace gets positioned wrongly (no reposition), and the right one correctly (reposition).

In Chrome on the other hand braces are positioned correctly.

––––

Turns out that the left bracket repositions like follows:
(M) brackets move upwards correctly
(a) brackets stay low as expected
(Ma) brackets stay low –> left bracket should move upwards instead
(Maaa) left bracket moves upwards correctly

–> When at least 4 characters are entered using mixed small and capital letters, the brackets behave as expected.

[schriftgestalt]

Sorry for taking so long. Flipped or rotated components are decomposed by default.

[be5invis]

@schriftgestalt It looks like Inter used its own script to generate TTF from Glyphs source 🤦. Time to fix that.

[rsms]

Indeed this looks like an issue with intended behavior with unexpected results — i.e. not a bug but also not ideal. Inter uses an OpenType feature called "contextual alternates" which is used to replace certain glyphs in certain contexts with specialized glyphs. For example, Inter provides a left parenthesis specialized for capital letters. When a left parenthesis is adjacent to a capital letter, it is replaced by the special one. However, the rules are more complex that this and includes exceptions, which is what causes the issue you see. Specifically, "x (M" vs "(M" — in the first case the adjacent lower-case letter "x" invokes an exception to not perform the substitution.

[rsms]

I made some improvements in ebdfaf2

Here is the result of /lab/?sample=Feature%3A%20calt&size=24&varWeightNum=446 (master, not the website)

[rsms]

Some improvements to this has been released as part of version 3.14

[ForNeVeR]

I'm sorry, but I can't see any improvements.

I can see that the braces are rendered differently if there's an adjacent capital letter (they go up a little), but the opening and closing brace still have different lifting, which, on my screen, differs from what I see on your screenshot. Here're the current results from https://rsms.me/inter/lab/?antialias=default&size=16 (which, I believe, has been updated to use 3.14 already? By the way, could we have a font version being printed on the website?)

And, for comparison, with space or a non-capital letter before and of the braces:

(they're drawn lower, but opening and closing brace are still noticeably different)

[rsms]

Interesting! So perhaps this is Windows-specific after all. I’ll test on a Windows machine...

[be5invis]

@rsms You can try with Visual TrueType, select the glyphs, select an anti-aliasing mode (TTFA should using "CT(anti-aliased)"), enable grid fitting (Ctrl+G) and zoom in to see the pixel-level difference.

[rsms]

Thanks! I'll try that.

[be5invis]

This issue may also influence certain Linux users (depending their fontconfig settings).

[rsms]

I've spend a good deal of time this evening trying to reproduce the issue but I'm falling flat. I've tried all major browser, macOS and Windows 10 as well as following @be5invis's advice with Visual TrueType. The results I'm seeing are the expected ones (i.e. "()" are aligned and not offset.) Is there any details we might be missing here?

How I'm testing:

1. Open https://rsms.me/inter/lab/ in a web browser
2. Select all and paste to replace the sample below
3. Inspect and screenshot

sample:

ABCDEFGHIJKLMNOPQRSTUVWXYZ[]{}()
abcdefghijklmnopqrstuvwxyz[]{}()
0123456789!?.

Note that https://rsms.me/inter/lab/ does not use font files with TTF hints.

Some screenshots of what I'm seeing:

Visual TrueType, setup as suggested in #251 (comment)

---

macOS:

---

Windows 10:

[be5invis]

@rsms You could try using ↑ or ↓ to increase or decrease PPEM in VTT. This issue only occurs at certain PPEM sizes.

[rsms]

Hm. I'm not seeing any changes to positioning of left and right parenthesis across sizes.

Perhaps the component transformation (right parenthesis is a component instance) gets messed up somehow on Windows.

Tomorrow I'll try to decompose everything in the font (which will explore the file size but allow me to test this theory.) If this is the case, with component transformation issues on Windows, then perhaps I could offer a decomposed and larger font for Windows specifically.

[be5invis]

@rsms It is a feature: you are using rounded component references in ), and this component is flipped, and you have hinting, so the rasterizer correctly interpreted the hinted (, rotated it, and translated but using an rounded offset, so they become asymmetric, since you added a lot of rounding (component offset and hinting).

[rsms]

Hm, but there are no hints in these fonts. The hinted TTF fonts are not served from the website (/inter/lab/).

My understanding of the issue, as I read it in the description of this issue, is that things are rendered incorrectly in the web browser when viewing https://rsms.me/inter/lab/, which does not serve font files with hints.

Let me ask a clarifying question: Is it possible that we are discussing two different issues here? I.e. rendering in web browsers AND hinting data of the hinted fonts.

What I'm testing and debugging is the rendering of https://rsms.me/inter/lab/ (as described in the OP.)

This is what I'm seeing walking through rasterization sizes in Visual TrueType, using the most recent release: (v3.14, no hints. two videos stitched together)

[be5invis]

@rsms Could you press CTRL + 2 and show me the glyph program of )?
I expect there's a line starts with SOFFSET[R], where the uppercase R means rounded. Changing it to r could immediate fix this issue.

[be5invis]

SOFFSET[r] + transformed components, perfectly symmetric:

SOFFSET[R] + transformed components, slightly asymmetric:

The best solution to this should be unlinking all the components that is transformed -- which shouldn't have a lot.

[schriftgestalt]

You can skip all tests on MacOS as it ignores TrueType instructions.

[rsms]

@be5invis This is what the CTRL+2 shows me for the glyph program

[rsms]

Now, if I open a font file with TTF hints (from ttfautohint) I do see a program for the glyph as expected, but as I mentioned earlier, the fonts on the website do not have TTF hints.

[rsms]

Repro on Windows with ClearType enabled: (or Linux with ClearType or similar technology enabled in e.g. FreeType)

1. Install or load Inter Regular with TrueType hints: Inter-Regular-hinted-v3.14.ttf.zip (release v3.14)
2. Use an app that uses the system font renderer, like Notepad
3. Type "ABC()[]{}"
4. Set font to Inter Regular, size 12

This should yield right parenthesis with an unwanted offset on the y axis, as shown in this screenshot:

---

Repro on Windows in a web browser (for some reason this is not reliable for me; sometimes it repros sometimes not. Very strange.)

1. Open https://rsms.me/inter/lab/?antialias=default&sample=ABC()%5B%5D%7B%7D&size=12 in Edge

[rsms]

Here's a new build of the fonts, incorporating the changes landed in 7d70535
Inter-3.14-text-ca7d79eb20-issue-251.zip

This is what it looks like on Windows 10 in Notepad:

This is what is looks like on the website in Windows 10: (left is static font, right is variable)

[rsms]

@ForNeVeR @aemi-dev Would you mind installing the fonts in the zip attached in the previous comment above and let me know if that solves the issue for you?

[g-cqd]

Issue is solved. I'm using macOS.
However :

Firefox

Google Chrome

Safari

We can notice that Google Chrome handles this differently.

[rsms]

Excellent news. Thank you @aemi-dev!

[rsms]

This has now been released as part of version 3.15 🎉
Try it out here: https://rsms.me/inter/lab/

[rsms]

Some ClearType rendering samples from Windows 10 using the v3.15 hinted font files:

[ForNeVeR]

Thanks a lot for your work on figuring our the issue and fixing it! I confirm that it has been resolved completely.

[citizenkade]

Sorry to dredge up this issue. Just experienced it with Inter in Figma on a mac. Not a big deal. Just thought it was an interesting problem and Googled it. Ended up here.