Hello Raimund!
> I don't at all disagree with the current implementation in terms of > aesthetics, but I suppose one could say that keeping monospace text > in its proper grid (in the face of users who don't want to configure > a lot) constitutes something like a higher cause... Well, after some thinking I disagree. > Anyway. We found that older Infinality patches implemented a change > to this exact advance width calculation that just disabled it if > FT_FACE_FLAG_FIXED_WIDTH was set. Newer versions then started > disabling it unconditionally, but I think that would be taking it a > little too far. > > Attached is a patch that's about what I have in mind. I'm going to reject this patch. While it is trivial for an application to preserve and restore the original metrics after calling FT_GlyphSlot_Embolden, the opposite is not possible – you would have to guess the new metrics, becoming thus dependent on the exact implementation of FreeType's emboldening algorithm (which may change). Another argument against your change is that FreeType has *always* increased the advance width for emboldened glyphs; I can imagine that returning unchanged metrics for mono-width fonts might yield to unpleasant surprises somewhere else. Finally, the correct way to embolden glyphs without increasing the advance width is to *move* the glyphs themselves a little to the left after emboldening! Otherwise it can happen that the very right of emboldened glyph gets overwritten (or cut off) by the next glyph. > Still I thought it'd be worth a suggestion before some distributions > started disabling the feature for monospace fonts through their > fontconfig setup... The fault is not with fontconfig, so the best you can do is to add a warning to `90-synthetic.conf'. IMHO, the problem lies one level higher than FreeType. For example, look at Cairo's `cairo-ft-font.c': FT_GlyphSlot_Embolden gets unconditionally called, which is a bug according to your analysis. I suggest that you are going to open a tracker issue for Cairo. A quick look at Qt 4.8.6's `qfontengine_ft.cpp' seems to indicate that they are doing exactly the same error... I guess it's the same in Qt5, too. Theoretically, I could add a configuration option, say FT_CONFIG_OPTION_SAME_ADVANCE_WIDTH_FOR_EMBOLDENED_MONOSPACED_GLYPHS, but I don't see a convincing reason to punish FreeType with such an ugly workaround. For clarity, I've slightly updated the comment in `ftsynth.h'. Werner _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
