Bug 92756 - Synthetic emboldening of monospace fonts makes characters wider
Summary: Synthetic emboldening of monospace fonts makes characters wider
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: freetype font backend (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: David Turner
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-31 17:10 UTC by Adam Williamson
Modified: 2018-08-25 13:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Williamson 2015-10-31 17:10:28 UTC
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.
Comment 1 GitLab Migration User 2018-08-25 13:48:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/205.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.