calt being too smart: Punctuation alignment

[jmk]

Describe the bug
In certain contexts, the alternate vertical alignment of colons and parentheses produces odd results.

These look especially awkward for unusual strings like C++ types. I know this isn't a common use case for a face like Inter, but these strings do appear in our app UI.

However, there are other (somewhat contrived) cases where these contextual alternates produce unexpected results as well.

To Reproduce
Steps to reproduce the behavior:
In the lab, I used a string like "Foo::Bar() foo::Bar() F" to produce a few examples of odd alignment. See the screenshot below for a few more.

In the first case, the two colons aren't aligned together. I'm a bit surprised that the second colon is shifted up because there are no numerals, but this appears to be caused by the capital B that follows.

In the second case, the same thing is happening to the parenthesis because of the capital letter F at the end. Given that it's a closing parenthesis, I'm surprised that a subsequent letter influences its alignment.

Given that these cases aren't very likely in ordinary prose, I'm not sure if there are additional contextual rules that will solve these cases without affecting other more common use cases.

Expected Results
I'd expect all colons and parentheses in these examples to have the default (lowercase-aligned) vertical positioning.

Screenshots
Example text in the lab (Safari on 10.14):

Environment

• OS: macOS 10.14, Linux
• App: Safari, Qt (freetype/harfbuzz)
• Version of font: Whatever's in the lab as of today!

[Derpitron]

This is probably part of the case alternates Opentype feature. Are you able to disable any opentype features in your app?

[be5invis]

The problem is that these case alternatives are impelemented in calt feature, which is on by default.
The standard way to solve this is to use case only.

[jmk]

@be5invis Indeed, the behavior above is with calt on and case off. Enabling case does force consistent uppercase alignment for these punctuation characters, but I would actually expect the (default) lowercase alignment in these particular examples. (I've edited the report to clarify.)

Of course, turning calt off will achieve this, but my point is that these particular contextual adjustments look buggy to me. None of results above seem like intentional or desirable behavior.

@Derpitron In my case (ahem), I'm not able to control specific OpenType features (thanks, Qt). However, I'm fine with modifying Inter for our use as needed, so I'm just reporting this issue to see if it warrants a fix in the original font.

[rsms]

This is an unfortunate outcome of calt — if you disable calt, you should see uniform punctuation. You can then opt-in to case-aligned punctuation on a case-to-case (ha) basis by setting case where you use upper case.

In any case, I think there’s room for improvement to the calt rules. There are already some code in the font that tries to “disable” these substitutions in certain situations, but implementation of contextual substitution actually varies between platforms. For instance, on the web, Safari correctly treats whitespace as whitespace, whereas Chrome doesn’t (meaning that rules based on word boundaries doesn’t work in Chrome.) Some non-web apps have similar issues as well.

Anyhow, disabling calt is your best bet for now!

[rsms]

Here’s a live repro: https://rsms.me/inter/lab/?sample=Foo%3A%3ABar()%20%20foo%3A%3Abar()%20Foo%0AThis%20is%20(a)%20Thing%0A%3A%3A%20dog%20%3A%3A%20Kitten&size=72

[rsms]

[rsms]

@jmk I hope this looks good to you. If you have any more sample text of tricky situations, please do post them here and I’ll make sure to add them to test matter.

[casta]

Hello,

I just was about to report something that is probably related.

There is an issue in parenthesis alignment as soon as you put numbers within.
Just modify your live example like this to see the issue: https://rsms.me/inter/lab/?sample=Foo%3A%3ABar()%20%20foo%3A%3Abar()%20Foo%0AThis%20is%20(1)%20Thing%0A%3A%3A%20dog%20%3A%3A%20Kitten&size=72

I get the issue in firefox or Pango (gtk3 rendering), either using TTF (without hint) or OTF variants.
But the issue does not raise in Chrome.

Thank’s !

[rsms]