Since Windows can synthesize certain font traits for us, we
used to register these in the font database so that we could
match against them. But after change
469b139169, this in principle
no longer happens, because we opt out whenever there is a
style name (which there usually is, this could be e.g.
"Regular" for a normal font). The result of this was that
if we looked for a bold variant of a font, we would not find
it.
In cases where a multi-engine was used, the request for bold
would still survive in the multi engine's fontDef, so we would
still pick it up later and apply the synthesis. But when
NoFontMerging was set, then we would override the weight in
the fontDef with the one from the font database.
Since the comment documents that the additional registrations
are there to make sure all the variants that Windows can
synthesize are available for matching, it does not make sense
to skip them just because the font has a style name. So this
is a partial revert of 469b139169.
Note: This exposed an error in QFontDatabase::isSmoothlyScalable().
The style parameter here is not the "styleName" (as in sub-family),
but actually predates that API. Instead it is the "style" as
returned by QFontDatabase::styles(), which may be the style
name, but it can also be the generated description of the style
and weight. In the latter case, we would return false for fonts
that are actually smoothly scalable, which is incorrect. This
caused a failure in tst_QFontMetrics::metrics(). To remedy this,
we add an additional condition, and also match the style if it
matches the generated descripion of the style key.
[ChangeLog][Windows] Fixed an issue where bold/italic would not
be synthesized for fonts if QFont::NoFontMerging was set.
Pick-to: 5.15 6.1
Fixes: QTBUG-91398
Change-Id: Id2166a47ae2d386536cf6e5e27ff09165ae8a23a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
f385b8827a