/configmgr/

mily 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> 
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>
Related: tdf#162072 compare fallback to what "serif" resolves to 2024-07-28T19:59:41+00:00 Caolán McNamara caolan.mcnamara@collabora.com 2024-07-28T15:17:04+00:00 d01dcab81a6a66fd5b4448ccff348f69c82c538d instead of assuming that the resolved serif font will have serif in its name. Change-Id: I3f85e2a8abd1dbf851debec9196e55d5c2da4e66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171144 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> 
instead of assuming that the resolved serif font will have
serif in its name.

Change-Id: I3f85e2a8abd1dbf851debec9196e55d5c2da4e66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171144
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
tdf#162072 vcl, fontconfig: consider font-family-generic for substitute 2024-07-18T15:45:14+00:00 Miklos Vajna vmiklos@collabora.com 2024-07-18T13:35:49+00:00 6dfac38bacd449c64a13363797b56aff49cf8f52 Open the bugdoc, it has two paragraphs: first with a sans font, second with a serif font. These fonts are missing, but their metadata clearly state that they are sans vs serif. Still, Writer renders both as sans. Investigating a bit, the ODT case imports the "font-family-generic" of these fonts fine, but in the Linux case the fontconfig code ignored this info when building the search pattern for the font fallback. Fix the problem by extending vcl's PrintFontManager::Substitute() to also take the vcl-level "family type" into account, which is about sans vs serif (roman vs swiss). Note that FC_FAMILY is a string list, so once the actual font name is added to the pattern, the next "add" will append to this list, not drop the already added font name. The same problem is still there with the DOCX equivalent. Change-Id: I61f31ae73e524471a5261ac9426e5b566454a09c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170681 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 
Open the bugdoc, it has two paragraphs: first with a sans font, second
with a serif font. These fonts are missing, but their metadata clearly
state that they are sans vs serif. Still, Writer renders both as sans.

Investigating a bit, the ODT case imports the "font-family-generic" of
these fonts fine, but in the Linux case the fontconfig code ignored this
info when building the search pattern for the font fallback.

Fix the problem by extending vcl's PrintFontManager::Substitute() to
also take the vcl-level "family type" into account, which is about sans
vs serif (roman vs swiss). Note that FC_FAMILY is a string list, so once
the actual font name is added to the pattern, the next "add" will append
to this list, not drop the already added font name.

The same problem is still there with the DOCX equivalent.

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