Yes!
Definitely a bug with with getStringWidth*, should be a nice small UI win for the JUCE team.
I’m grateful for @migizo for pointing it out. I do a lot of horizontal centering (buttons, etc) of fonts with letter-spacing and things often feel not quite right…
Not to muddy the waters, but I believe another issue here is JUCE conflates kerning with letter spacing.
Kerning is spacing between letters. It’s something that type designers meticulously take care of. The amount of space differs for every character combo.
Tracking or letter spacing (see: css and every design tool) adds/removes a constant amount of spacing between glyphs— while keeping the carefully designed kerning intact. This is so designers/implementers (like us!) can tighten up a font or make it feel more spacious without ruining the font’s internal knowledge of how characters relate to each other. The kerning is not touched or altered.
I’m not 100% on this, but it looks like JUCE’s withExtraKerningFactor does something different, it’s a multiplier that overrides the kerning of the font’s glyphs at a low level, for example via kCTKernAttributeName on macOS. As far as I can tell this replaces the kerning between glyphs with a constant amount of space — getting rid of the meticulous work done by the type designer. I haven’t “proven” this with a demo, but this would explain the discrepancy @migizo is seeing in their test as well as some issues I’ve noticed when going adjusting (what I assumed was) letter-spacing.
Edit: I should have tested this before jumping to conclusions, sorry about that, see below.