tdf#162280 vcl: consider font family type for glyph caching HEADmaster

Open tdf105820-1.doc from crashtesting in a dbgutil build, save as PDF,
we assert in checkGlyphsEqual().

This is a problem since commit 6dfac38bacd449c64a13363797b56aff49cf8f52
(tdf#162072 vcl, fontconfig: consider font-family-generic for
substitute, 2024-07-18), because now the font name no longer determines
the fallback name alone, so 2 paragraphs may share the cached vcl-level
text layout, even if the underlying fallback font is different. One
would naively expect that in the SalLayoutGlyphsCache::CachedGlyphsKey
ctor, the fontMetric.GetFamilyType() already has the correct family
type, but it turns out that is always the default, and only
outputDevice->GetFont().GetFamilyType() has the up to date setting:

debug:12372:12372: SalLayoutGlyphsCache ctor: output device font family name is 'Verdana', output device font family type is roman, font metric family name is 'Verdana', font metric family type is 'swiss'
debug:12372:12372: SalLayoutGlyphsCache ctor: output device font family name is 'Verdana', output device font family type is swiss, font metric family name is 'Verdana', font metric family type is 'swiss'

Fix the problem by explicitly including the output device font family
type in the cache key.

Note that this only happens in practice if the same font is used in the
document with different family types, which is probably never the
intention of the user. E.g. Verdana is meant to be sans, a serif Verdana
is some weird corner-case.

Change-Id: Id6cc60809a35a3dcdc6e83122a559ddfbe5d5d0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171280
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

0 files changed, 0 insertions, 0 deletions