Hello everybody. When True Type font doesn't have a Bold style and Bold is emulated, it is done in suboptimal way, that is: when Bold style is emulated on a bitmapped font, the characters are rendered beautifully, but when emulation is done on a True Type font, characters are rendered noticeably worse - they have jagged edges, are emboldened in a non-uniform way etc. Here is a discussion which I had on a freetype mailing list, where solution were proposed: ---------------------------------------------- Question: Generally, X renders .ttf fonts exactly as Windows does, but there is the following problem: usually .ttf file for a particular font contains a number of styles: Regular, Bold, Italic and Bold Italic, so that when application uses bold font, it uses Bold style instead of Regular. But when .ttf doesn't contain Bold style, for example, and bold font is required, boldness is emulated. Now, Windows emulates boldness perfectly, but X does it really badly. For example, see the difference between Windows and X in bold font rendering in the following screnshots: Windows: http://xt.nm.ru/monaco-win-10pt_1.tif Linux: http://xt.nm.ru/monaco-lin-10pt.tif The font used in a screenshot is Monaco (.ttf version), but there is the same problem with other fonts which don't have Bold style "built-in", for example Ariel Mono and others. I use libfreetype 2.2.1 (Ubuntu Edgy). Is it possible somehow to improve the situation? ---------------------------------------------- ---------------------------------------------- Response (by David Turner): The problem is in the client libraries using FreeType to render the text. 2.2.1 provides both outline and bitmap emboldening functions, and the latter is capable of generating output exactly equal to your "good" screenshot. more precisely, the problem is that these libraries only use the vector emboldening algorithm, which only gives satisfying results with anti-aliase text. I would provide a patch if I had time, I recommend you to file bugs against libXft, Cairo, and probably OpenOffice.org if this is a big concern to you. ---------------------------------------------- As adviced, I submit that bug both to Cairo and to LibXft.
The tif files linked are nonexistant. Please attach them to the bug.
Created attachment 7360 [details] Boldness emulation under Linux Here is a screenshot which shows boldness emulation for Monaco True Type font (Linux).
Created attachment 7361 [details] Boldness emulation under Windows. This is a screenshot of boldness emulation for Monaco True Type font under Windows. It is possible to generate .bdf font from Monaco and it would be rendered under Linux exactly like in the attached screenshot under Windows - I didn't attach suitable screenshot from Linux because I had a problem generating .bdf font, but David Turner mentioned above did it (I don't want to attach his screenshot without permission).
It seems the problem is we get very bad results if hinting is enabled and even worse if antialiasing is disabled too while emboldening glyphs. I have almost the same problem with simsun too. I have a dirty hack in my own cairo tree that does render the glyph to bitmap then embolden it if FC_HINTING is not FC_NO_HINTING and antialias is disabled and glyph size is small(I also have a patch for libXft). But we don't know the glyph is really hinted by freetype or not and it seems there's no way to detect that :(.
Do I see correctly that this bug still exists in Cairo 1.6.x? It calls FT_GlyphSlot_Embolden() while I understand from the FreeType docs and past posts to the FT list that FT_Outline_Embolden() or FT_Bitmap_Embolden() should be superior, but dependent on the font format. I just don't understand how to express the emboldening strength in 26.6 format otherwise I would have tested if that works...
-- 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/133.
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.