With this new version, the build started to fail with
error: ‘XML_Size XML_GetCurrentColumnNumber(XML_Parser)’ is deprecated: please use XML_GetCurrentColumnNumber64 instead [-Werror=deprecated-declarations]
so we need to check the expat version in case the system expat
is older than 2.9
Also add 0001-fix-XML_GE-is-not-defined-evaluates-to-0-Werror-unde.patch
to fix
error: "XML_GE" is not defined, evaluates to 0 [-Werror=undef]
1087 | # if XML_GE == 1
| ^~~~~~
cc1plus: all warnings being treated as errors
Change-Id: If4f1d652941b7766ed94b65a6eaa018f37c89387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211867
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
if wrapping the case insto a block, Xcode 16 is happy.
Solves building on macOS 14 that is stuck with Xcode 16 (at least
when not trying to sideload anything newer)
Without the block it fails with "error: expected expression" on the
variable declaration lines.
Change-Id: I0888fc5d2d6088f6071a72cde0c26532779cedad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211633
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
Sonoma (macOS 14) builds with Xcode 15.2 can't find locale_t when
building fontconfig. Later OS versions and Xcode builds don't seem
to have that problem.
In file included from fcarch.c:24:
./fcint.h:682:9: error: unknown type name 'locale_t'
typedef locale_t FcLocale;
^
Fontconfig added "#include <xlocale.h>" recently in c24472116 to
fix the issue, but also switched to the Meson build system which
is the only mechanism by which HAVE_XLOCALE_H gets defined. Given
that LibreOffice uses fontconfig's old configure-based system and
it's a bunch of work to switch to meson here, we're not going to
bump fontconfig just for this. For now just assume all Apple
platforms have xlocale.h, which they do.
Change-Id: Ida9ef328dbd79e0c54b3d37355c344d7ca8d1b4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211630
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Patches:
- external/pdfium/extractpatterns-fill.patch.1 is now upstream
- external/pdfium/extractpatterns-stroke.patch.1 as well
- external/pdfium/fix-windows-build.patch.1 as well
- external/pdfium/system-icu.patch.1 as well
- external/pdfium/system-dragonbox.diff is a new dependency, patch the
code to use our bundled dragonbox
- update external/pdfium/system-abseil.diff to apply again
Adapted tests:
- CppunitTest_vcl_pdfexport goes back to its previous expected values
after pdfium.git commit 17cf94b52e01507108da6460ebca6b48995a698e
(Revert "Fix mixed-direction line extraction", 2026-09-17)
- CppunitTest_vcl_pdfexport2 as well
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I09bf5fc9f54b697eed2e144c3f57c3b72f3bbc37
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13508
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 0272de3a9b98d0c3ef4479e0dc12abe8cc040447)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211551
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Add new paragraph justification option "Split compound words" for
custom compound-based "smart" hyphenation. Add compound-based "smart"
hyphenation support for Danish, Dutch, Esperanto, Estonian, German,
Norwegian, Swedish (and potentially, Icelandic, Finnish and
Latvian) languages by fixing Hunspell morphological analysis and the
associated lingucomponent code. (Previously compound-based "smart"
hyphenation was enabled only for Hungarian.)
With the new option it's possible to keep MSO/MS-DOCX interoperability,
also introducing a better hyphenation algorithm for several languages.
Details:
* Add check box to Alignment in paragraph formatting dialog window;
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaIsCompoundBased
* Implement it by checking the new option in the previously
added commit f9f694f5d9f39c5801bc5fec45867252c293bbcb;
* Add ODF import/export (loext:compound-based);
* Add ODF unit tests by the new tdf173389_smart_hyphenation_nl.odt
and tdf173389_smart_hyphenation_hu.odt. Now use the previous
tdf119908_smart_hyphenation_hu for disabled compound-based "smart"
hyphenation, also the new tdf119908_smart_hyphenation_nl.odt.
Note: the Dutch test document results better compound-based
hyphenation in two positions.
* Add Hunspell patch to fix Danish, Dutch, Esperanto, Estonian,
German, Norwegian, Swedish (and future Icelandic, Latvian,
Finnish) morphological analysis for compound word constituents;
* hyphenimp.cxx hyphenate(): fix tokenization for consecutive
pa: elements, like resulted in the fixed Hunspell dictionaries.
Follow-up to commit f9f694f5d9
"tdf#173389 sw: add compound-based “smart” hyphenation for readability".
Change-Id: I4414bd588646ecf6dc86b77642833ac9c7820a98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211341
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
I had to replace "scheherazade" with "Noto Naskh Arabic", which
is a similar font, in vcl/source/font/PhysicalFontCollection.cxx
in order to avoid the following assert in gerrit_linux_clang_dbgutil
(not reproduced locally):
[_RUN_____] testBtlrCellChinese::TestBody
WPSDocument::isFileFormatSupported()
warn:sal.file:2772196:2772196:sal/osl/unx/file_misc.cxx:397: Invalid directory URL
warn:basic:2772196:2772196:basic/source/uno/namecont.cxx:949: Cannot access extensions!
warn:sal.file:2772196:2772196:sal/osl/unx/file_misc.cxx:397: Invalid directory URL
warn:basic:2772196:2772196:basic/source/uno/namecont.cxx:949: Cannot access extensions!
cppunittester: /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/gdi/impglyphitem.cxx:318: void checkGlyphsEqual(const SalLayoutGlyphs &, const SalLayoutGlyphs &): Assertion `l1 == l2' failed.
Change-Id: I26cd80cee639cf0e17d7e71c3abdc49bf984de9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202933
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
- fix build against our bundled ICU
- update external/pdfium/extractpatterns.patch to work after the
upstream commit fc790866bf26d977b2ea3a0c3938bb52895309ea (Consolidate
CFX_RenderDevice and remove CPDF_WindowsRenderDevice, 2026-06-29), which
folded CFX_DefaultRenderDevice into CFX_RenderDevice.
- update CppunitTest_vcl_pdfexport2: mostly likely needed after the
upstream commit 2f7a54a926a1b8e51aff9ac2aca5cccb29920aae (Partially
fix RTL character and line reading order in CPDF_TextPage, 2026-07-24)
- CppunitTest_vcl_pdfexport: same
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I25612e6696a24588b9bf045e666047e6c2955d7c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8557
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit a7149002917e82ef07250d2e964537118294993a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210417
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
the update to nss 3.128 put the -DHAVE_PLATFORM_GHASH define behind a
check for the variable LITTLE_ENDIAN, but the makefile based system only
had a check for that added to the coreconf/Linux.mk file instead of e.g.
the UNIX.mk one that would also be included in the macOS makefile
(Darwin.mk)
So as a workaround specify it on the commandline - our configure already
tests for it, so we don't need a dedicated compile check or patch to the
nss bits.
Not having the define results in having duplicate methods in both gcm.o
as well as ghash-aarch64.o and the macOS linker fails:
duplicate symbol '_gcm_HashInit_hw' in:
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/gcm.o
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/ghash-aarch64.o
duplicate symbol '_platform_ghash_support' in:
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/gcm.o
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/ghash-aarch64.o
duplicate symbol '_gcm_HashZeroX_hw' in:
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/gcm.o
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/ghash-aarch64.o
duplicate symbol '_gcm_HashWrite_hw' in:
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/gcm.o
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/ghash-aarch64.o
duplicate symbol '_gcm_HashMult_hw' in:
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/gcm.o
/Users/cloph/build/workdir/UnpackedTarball/nss/nss/lib/freebl/out/Darwin_SINGLE_SHLIB/ghash-aarch64.o
ld: 5 duplicate symbols
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Change-Id: Ic662115581aef7c2083f73079b2cff99b941ecd5
KillPython runs an inline CodeTaskFactory task that compiles a temporary
dll and loads it. Two parallel builds on one machine race over that dll,
and one build fails to find it:
pyproject.props(176,5): error MSB4175: The task factory "CodeTaskFactory"
could not be loaded from the assembly "...\Microsoft.Build.Tasks.Core.dll".
Could not find file '...\tmp\rmlsuizu\rmlsuizu.dll'.
KillPython only kills a stray python.exe that holds the output file open
across an incremental rebuild. A clean build has none to kill, so pass
/p:KillPython=false to override pythoncore.vcxproj and skip the target.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ic6cc3d51d4409bce6cc95137626debcab67dbc53
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10183
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit a287185f62eaa49f03ab0b3b2e5d956221ef9997)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210291
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Their subsets were embedded as simple TrueType fonts. Simple TrueType
fonts select glyphs through the cmap table of the subset font, and we
had to give the subset font a fake cmap table that mapped codes to glyph
ID sequentially. This was a gross hack.
Embedding them as CIDFontType2 instead lets the CMap and the CIDToGIDMap
do the mapping, as they now already for fonts with a CFF table. The cmap
table is not needed as all now.
PDFium grows the top of the glyph bounding box by a 64th for composite
fonts but not for simple ones, which makes many tests to now fail. We
now patch that out to keep both kinds of embedding measuring glyphs the
same.
Change-Id: I4d136b0e5d2c63afd56e25a81aec16364e570cca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208839
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
as seen e.g. at
> In file included from engine/cppuhelper/source/defaultbootstrap.cxx:27:
> In file included from engine/cppuhelper/source/servicemanager.hxx:35:
> In file included from engine/external/boost/include/boost/container/small_vector.hpp:31:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/small_vector.hpp:27:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/vector.hpp:61:
> In file included from engine/workdir/UnpackedTarball/boost/boost/move/algo/adaptive_merge.hpp:16:
> engine/workdir/UnpackedTarball/boost/boost/move/algo/detail/adaptive_sort_merge.hpp:261:17: error: unused function template 'needed_keys_count' [-Werror,-Wunused-template]
> 261 | static SizeType needed_keys_count(SizeType n_block_a, SizeType n_block_b)
> | ^~~~~~~~~~~~~~~~~
and
> In file included from engine/vcl/source/outdev/eps.cxx:22:
> In file included from engine/include/vcl/metaact.hxx:45:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/vector.hpp:61:
> In file included from engine/workdir/UnpackedTarball/boost/boost/move/algo/adaptive_merge.hpp:16:
> engine/workdir/UnpackedTarball/boost/boost/move/algo/detail/adaptive_sort_merge.hpp:261:17: error: unused function template 'needed_keys_count' [-Werror,-Wunused-template]
> 261 | static SizeType needed_keys_count(SizeType n_block_a, SizeType n_block_b)
> | ^~~~~~~~~~~~~~~~~
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: I1c81650c82df717317846769ea3ac016d9a14652
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7281
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit fd3a8cc0417525806d45522fc6752c6678b2d433)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208736
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Drop the exterals patches as VCL internals don’t support this anymore,
and drop the LOK addfont change as it wouldn’t work now. I don’t know if
LOK addfont has any use now, but I left it.
Change-Id: I2798679d0bb59bb6c2c6e0eae329287f36662223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208546
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
The FreeType/fontconfig font backend was spread over three directories
mostly for historical reasons. Lets clean this up and consolidate it
under one directory.
helper.cxx holds the psp path helpers, so it goes to print/ next to the
rest of the printing code.
Change-Id: I67d20e3e4bdf71d978a79e672bb31d3dd1460595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208522
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Xisco Fauli