include/vcl/glyphitemcache.hxx | 5 +++-- odk/Package_examples.mk | 8 +++++--- odk/Package_odk_headers.mk | 14 ++++++++------ vcl/qa/unx/generic/generic.cxx | 30 ++++++++++++++++++++++++++++++ vcl/source/gdi/impglyphitem.cxx | 7 ++++++- 5 files changed, 52 insertions(+), 12 deletions(-)
New commits: commit f786e2e3338eb6b6bcb5b2176b8a883d82306b80 Author: Hossein <[email protected]> AuthorDate: Sat Jul 27 15:24:50 2024 +0200 Commit: Caolán McNamara <[email protected]> CommitDate: Thu Aug 8 16:05:24 2024 +0200 No LibreOfficeKit headers and examples for macOS LibreOfficeKit has issues in macOS, as discussed in LibreOffice development mailing List and also in tdf#145127. LibreOfficeKit unrunnable on macOS https://lists.freedesktop.org/archives/libreoffice/2024-July/092256.html Therefore, let's not ship the LibreOfficeKit headers and examples with LibreOffice Community for macOS. If the above issue is solved, then it will be possible to ship those again later. Change-Id: I5ba62ee84432a09732d96a5d86eb0a1bf866671f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171095 Reviewed-by: Patrick Luby <[email protected]> Tested-by: Jenkins Reviewed-by: Hossein <[email protected]> (cherry picked from commit 67afda89557cd0d3bd181e7c3c8d1406075ea364) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171414 Reviewed-by: Michael Stahl <[email protected]> Tested-by: Caolán McNamara <[email protected]> Reviewed-by: Caolán McNamara <[email protected]> diff --git a/odk/Package_examples.mk b/odk/Package_examples.mk index 28d60b329016..568735ec1ff7 100644 --- a/odk/Package_examples.mk +++ b/odk/Package_examples.mk @@ -428,9 +428,11 @@ $(eval $(call gb_Package_add_files_with_dir,odk_examples,$(SDKDIRNAME)/examples, cpp/Convertor/Convertor.cxx \ cpp/Convertor/Makefile \ cpp/Convertor/test.odt \ - cpp/lokconvert/lokconvert.cxx \ - cpp/lokconvert/Makefile \ - cpp/lokconvert/test.odt \ + $(if $(filter-out $(OS),MACOSX), \ + cpp/lokconvert/lokconvert.cxx \ + cpp/lokconvert/Makefile \ + cpp/lokconvert/test.odt \ + ) \ cpp/Draw/Draw.cxx \ cpp/Draw/Makefile \ cpp/DocumentLoader/DocumentLoader.cxx \ diff --git a/odk/Package_odk_headers.mk b/odk/Package_odk_headers.mk index c103c23d4b27..e9af36c0fe25 100644 --- a/odk/Package_odk_headers.mk +++ b/odk/Package_odk_headers.mk @@ -184,12 +184,14 @@ $(eval $(call gb_Package_add_files_with_dir,odk_headers,$(SDKDIRNAME)/include,\ uno/mapping.hxx \ uno/sequence2.h \ uno/threadpool.h \ - $(if $(ENABLE_GTK3),LibreOfficeKit/LibreOfficeKitGtk.h) \ - LibreOfficeKit/LibreOfficeKit.hxx \ - LibreOfficeKit/LibreOfficeKitEnums.h \ - LibreOfficeKit/LibreOfficeKit.h \ - LibreOfficeKit/LibreOfficeKitInit.h \ - LibreOfficeKit/LibreOfficeKitTypes.h \ + $(if $(filter-out $(OS),MACOSX), \ + $(if $(ENABLE_GTK3),LibreOfficeKit/LibreOfficeKitGtk.h) \ + LibreOfficeKit/LibreOfficeKit.hxx \ + LibreOfficeKit/LibreOfficeKitEnums.h \ + LibreOfficeKit/LibreOfficeKit.h \ + LibreOfficeKit/LibreOfficeKitInit.h \ + LibreOfficeKit/LibreOfficeKitTypes.h \ + ) \ )) # vim: set noet sw=4 ts=4: commit 978497038f962e2464269a1daf1c4cef904e82b8 Author: Miklos Vajna <[email protected]> AuthorDate: Wed Jul 31 13:08:42 2024 +0200 Commit: Michael Stahl <[email protected]> CommitDate: Thu Aug 8 16:05:13 2024 +0200 tdf#162280 vcl: consider font family type for glyph caching 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 <[email protected]> (cherry picked from commit ef1870810ec8c069e26538fd7626ad0656bed276) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171298 Reviewed-by: Xisco Fauli <[email protected]> (cherry picked from commit 6b5f3ed531325c3d92f3e92b525f1a8534e5f631) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171300 Reviewed-by: Mike Kaganski <[email protected]> Tested-by: Michael Stahl <[email protected]> Reviewed-by: Michael Stahl <[email protected]> diff --git a/include/vcl/glyphitemcache.hxx b/include/vcl/glyphitemcache.hxx index 79f05e606550..373f270a65bc 100644 --- a/include/vcl/glyphitemcache.hxx +++ b/include/vcl/glyphitemcache.hxx @@ -72,8 +72,7 @@ public: { } -private: - struct SAL_DLLPRIVATE CachedGlyphsKey + struct CachedGlyphsKey { OUString text; sal_Int32 index; @@ -94,6 +93,8 @@ private: tools::Long w); bool operator==(const CachedGlyphsKey& other) const; }; + +private: struct CachedGlyphsHash { size_t operator()(const CachedGlyphsKey& key) const { return key.hashValue; } diff --git a/vcl/qa/unx/generic/generic.cxx b/vcl/qa/unx/generic/generic.cxx index 60f91266e067..8b79d99e510a 100644 --- a/vcl/qa/unx/generic/generic.cxx +++ b/vcl/qa/unx/generic/generic.cxx @@ -10,6 +10,10 @@ #include <test/unoapi_test.hxx> #include <vcl/font.hxx> +#include <vcl/vclptr.hxx> +#include <vcl/wintypes.hxx> +#include <vcl/window.hxx> +#include <vcl/glyphitemcache.hxx> #include <font/FontSelectPattern.hxx> #include <unx/fontmanager.hxx> @@ -53,6 +57,32 @@ CPPUNIT_TEST_FIXTURE(Test, testFontFallbackSerif) // i.e. we got a sans fallback for a serif pattern, which is clearly poor. CPPUNIT_ASSERT(aPattern.maSearchName.endsWith(u"Serif")); } + +CPPUNIT_TEST_FIXTURE(Test, testFontFallbackCaching) +{ + // Given a vcl-level text layout, created for the serif Verdana: + ScopedVclPtrInstance<vcl::Window> pWindow(nullptr, WB_APP | WB_STDWORK); + VclPtr<OutputDevice> pOutDev = pWindow->GetOutDev(); + vcl::Font aFont; + aFont.SetFamilyName("Verdana"); + aFont.SetFamily(FAMILY_ROMAN); + pOutDev->SetFont(aFont); + OUString aText = u"1-1-2017"_ustr; + sal_Int32 nIndex = 0; + sal_Int32 nLength = aText.getLength(); + tools::Long nLogicWidth = 0; + SalLayoutGlyphsCache::CachedGlyphsKey aKey1(pOutDev, aText, nIndex, nLength, nLogicWidth); + + // When creating a layout for the sans Verdana: + aFont.SetFamily(FAMILY_SWISS); + pOutDev->SetFont(aFont); + SalLayoutGlyphsCache::CachedGlyphsKey aKey2(pOutDev, aText, nIndex, nLength, nLogicWidth); + + // Then make sure these two layouts don't match: + // Without the accompanying fix in place, this test would have failed, the Noto Serif layout was + // reused for the Noto Sans layout if those were selected as fallbacks. + CPPUNIT_ASSERT(aKey1 != aKey2); +} } CPPUNIT_PLUGIN_IMPLEMENT(); diff --git a/vcl/source/gdi/impglyphitem.cxx b/vcl/source/gdi/impglyphitem.cxx index a08a3b043626..1b40291736b7 100644 --- a/vcl/source/gdi/impglyphitem.cxx +++ b/vcl/source/gdi/impglyphitem.cxx @@ -548,9 +548,14 @@ SalLayoutGlyphsCache::CachedGlyphsKey::CachedGlyphsKey( o3tl::hash_combine(hashValue, artificialBold); o3tl::hash_combine(hashValue, layoutMode); o3tl::hash_combine(hashValue, digitLanguage.get()); + + // In case the font name is the same, but the font family differs, then the font metric won't + // contain that custom font family, so explicitly include the font family from the output device + // font. + o3tl::hash_combine(hashValue, outputDevice->GetFont().GetFamilyType()); } -inline bool SalLayoutGlyphsCache::CachedGlyphsKey::operator==(const CachedGlyphsKey& other) const +bool SalLayoutGlyphsCache::CachedGlyphsKey::operator==(const CachedGlyphsKey& other) const { return hashValue == other.hashValue && index == other.index && len == other.len && logicWidth == other.logicWidth && mapMode == other.mapMode && rtl == other.rtl
