Earlier this year I noticed a problem with fonts in gedit. Even though I use a monospace font, sometimes the alignment seemed to be wrong - character 76 on one row was not at the same point horizontally as character 76 on another row. This is obviously bad when you're writing code.

Turns out this happens when you're using a font that doesn't have its own bold variant. For such fonts, bold characters are 'synthesized', ultimately by freetype. When freetype does this under the control of cairo, it doesn't keep the emboldened characters to the same width as the non-bold characters, so once a line has any bold characters in it (gedit uses them for source highlighting), its alignment will be wrong.

I first reported this upstream to fontconfig and freetype. Raimund Steger from fontconfig submitted a patch to freetype which would have it maintain the advance width when emboldening monospace fonts, but Werner Lemberg from freetype rejected it:

https://lists.gnu.org/archive/html/freetype/2015-02/msg00040.html

saying that in his opinion, it should be fixed at the toolkit level, e.g. in Cairo and in Qt. So, I'm reporting it here.

Raimund had an interesting follow-up here:

http://lists.freedesktop.org/archives/fontconfig/2015-February/005401.html

where he noted that "even plain old XftDrawStringUtf8 seems to do a better job than .. er, these toolkits. (I think it uses XftFont's max_advance_width to determine spacing for fixed-width fonts which is unaffected by the individual FT_GlyphSlot_Embolden results.)"

It's pretty easy to reproduce this problem: run gedit, set the font to Droid Sans Mono, and open a file in some syntax gedit can highlight, a Python file, an RPM spec, anything. Compare the rendering of lines with boldface and lines with none.