Almost proper or not, the font itself looks italicized, meaning the top is leaning out of the "normal" glyph width area, in other words, the base of the characters are indeed inside that bounding box!
The error is constant exactly because the font itself defined some glyph sizes "incorrectly", or at the very least, not to what you expected; just because they reach further doesn't mean that the next glyph will start later, getting a bigger offset and messing things up (
that's technically what you want to achieve).
The additional space included in the calculation wouldn't work as good, since apparently not all glyphs have this issue, so there might be some texts that wouldn't have glyphs being cut off, potentially messing with alignment.
Another hackish but workable way would be to just define (in pixels, let's say) how many extra units you want the total width to be appended by; that only needs to take into account the very last character in a line, for the above stated reason(s).
That said, it's most probably not an issue with Font:getWidth itself, it's a font issue... the only Löve related issue could be that the edges of such glyphs get cut off when drawing them, but i think that was already fixed.
grump wrote: ↑Fri Nov 03, 2017 8:37 pm
The thing is, I'm writing a tool that processes user supplied fonts and it requires accurate glyph sizes from any font. This is one of the last bugs I need to fix before I can release an alpha version. It's a pretty useless tool if I can't fix this
Processes as in? Turns them into an atlas/imagedata with all characters laid out nicely? Yes, that could cause some issues; usually you'd want to handle this with extra parameters that the users can supply for the fonts, like how much a glyph extends beyond its defined width.
Spacing's not an exact science.