How to fix horizontally cut off glyphs caused by negative side bearing

Some of my glyphs have negative side bearings, this is mostly done to reduce the amount of kerning. But these glyphs (i.e. lowercase ‘j’) are cut off on the left side in Google Chrome (and TextEdit) when used as the first letter of a sentence. Not a really big issue, but I was still wondering if there’s a solution for this?

A better solution than changing the side bearing to a positive value, because that leads to some major re-kerning. Maybe with a Custom Parameter, or setting a specific kerning value for the first glyph in a sentence?

Thanks for your time!


I just checked this. You can’t really do anything about this. Have a look at the j in Zapfino :wink:

1 Like

While this may not be of good use for your situation, I’m including a link below to Google Fonts webfont recommendation for avoiding clipping in case you or someone else may find it helpful.

1 Like

I have just experienced a similar issue. In my file two glyphs overshot the RSB but only one of them was clipped in the .woff. What would cause one to clip and the other not to? I copied the direction of the path from the one that wasn’t clipped to the one that was and the clipping went away … (clockwise …).


(Edit: This is a different issue but someone may stumble on this via Google)

Which glyph in which version of which browser on which version of which OS? Under what circumstances?

In my own design the clipped glyph was /K, the unclipped glyph was /Q
This issue was produced on Safari on iOS 11.4.1 rendering a .woff file produced in Glyphs 2.6.1

Some artefacts are to be expected. I would double check:

  • path directions (should be counterclockwise in the .glyphs file and PS-based export, but clockwise in a TT-based export),
  • accidental duplicate paths (the Show Angled Handles plug-in can help find those),
  • if it is the same for PS and TT exports,
  • if the clipping still occurs in iOS 12.3.1,
  • if the clipping still occurs with the latest cutting-edge version (I remember Georg fixed a bug a while ago where bbox had been miscalculated)

In your case, you said changing the path direction helped. Can you double check the path direction of the exported outline with OT Master?