Re: [ft] Suggestion/Inquiry: keeping metrics.horiAdvance for emboldened fixed-width fonts

[Werner LEMBERG]

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