Public Sans - Bug: Kerning between endash and space (-500) breaks UK use

[fufurasu]

Describe the bug

British English style guides (eg Oxford) typically recommend the use of en-dashes with spaces either side for parenthetical comments (in the same way AP recommends the use of em-dashes without spaces).
Public Sans has a kerning rule that effectively removes the space after an en-dash. endash is in the @hyphen group and gets -500 kerning before a space.
Arguably, the -340 kerning between a space and a member of the @hyphen group is also problematic for this use.
This kerning rule breaks British English uses.

Steps to reproduce the bug

Type parenthetical – comment in Public Sans (space, en-dash, space). The spacing after the en-dash is way too narrow.

Expected Behavior

When typing parenthetical – comment there should be distinct spaces on either side of the en-dash.

Related code

In Glyphys kerning table:
@hyphen -500 space and also space -340 @hyphen

Screenshots

System setup

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct.
• I checked the current issues for duplicate bug reports.

[fufurasu]

Out of curiosity, could someone shed some light about the decision to kern the @hyphen group so aggressively with spaces? I note that em-dashes are not included in the group. I presume this solves some other problem?

[kenmcd]

The em dash has other problems.
it is handled (messed-up) using calt.
#204
#151

I figured-out what is happening with the em dash...
Note: the default em dash has huge side-bearings.

There is an alternative emdash glyph emdash.alt with narrower side-bearings. But the only way to access it is via calt when there are spaces before and after the emdash. So... If you enter no spaces - you get an emdash with excessive side-bearings. If you enter space+emdash+space - you get an emdash with narrower side-bearings but full spaces on each side. And no way to get just the emdash.alt alone. This is really dumb.

Change the default to what is now the inaccessible alternate - with the small side-bearings. I like the equivalent of a hairspace on each side.

Then provide full-width alternate emdash and/or /horizontalbar which is the full width.

[fufurasu]

The em dash has other problems. it is handled (messed-up) using calt. #204 #151

I read those before posting this bug. They don't offer any clues about the en-dash kerning situation, but I wonder if they are caused by the same underlying idea.

[kenmcd]

The endash kerning makes no sense.
Most of the kerning was carried-over from Libre Franklin.
Which makes sense.
But then someone added this kerning between space and the endash.
-500 on the right and -340 on the left - which makes no sense.
The L_hyphen/R_hyphen kerning classes include the endash and the hyphen.
So this weird kerning also affects the hyphen.
Don't try to make sense of it.
It makes no sense.

Side note: you can set side-bearings based on another glyph.
The endash side-bearings are both set to hyphen - so it copies the values from the hyphen.
The emdash side-bearings are both set to hyphen*3.
So they are set to three-times the values for the hyphen.
This makes no sense.
And then the crazy calt described above on top of that.
Have never seen an emdash configured like this.

I have tried to imagine why someone would do this.
In what scenario this would be desired.
Came up with nothing.