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>
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Replaces the memcpy() and memmove() with std::copy_n() and
std::copy_backward() in fastserializer.cxx.
Change-Id: I6d971f18d1138f03ab62a5007db5d0da63f7679a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203377
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Since some code needs flexibility in error handling, where hardcoded
error value of -1 wasn't handy, o3tl::convertToHex was changed to
accept the error value as its template parameter.
Change-Id: Ifc771cc8fa29a801d4556dea969fc3ea7e620df5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199367
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
lcl_isLeapYear used a simple "is divisible" method to check if a given
year is leap. But that didn't take BCE into account: we use historical
numbering system, where before year 0001 was year -0001; and that year
was leap.
Use comphelper::date::getDaysInMonth for that, which is correct, and
also deduplicates the code. Make sure that years beyond sal_Int16 are
considered an error: they are not representable in css::util::Date,
and comphelper::date::getDaysInMonth takes years as sal_Int16.
Change-Id: I34f1ad4d5d03e05a7cf787f9997b04b1d705b583
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193302
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
we will need the length anyway, and in the case that its constructed
from OString then that strlen can be elided. (For the const char* case
then std::string_view[4] will compute the len)
Change-Id: Ifc06595573625cf93f07dd72ceec8a20745e12f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182123
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
We use the same funciton all over the place, so create a common
function in o3tl and use that in all instances where we duplicated
the code.
Change-Id: I74091fbbde8c2ba8c7e4ab30194ab53e2a338e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180372
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Since
commit 2e25618fe7
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Mon Jul 8 12:12:49 2024 +0500
Make convert*Angle strict
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
Change-Id: Ie0c9059e18518cae46854715fa7d39cc9c942549
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175933
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Previously, Converter::convertMeasure parsed measure strings and
performed unit conversion in a single call. This was appropriate, as all
such measure strings could be converted to a common unit ahead of time.
tdf#36709, however, will introduce measures that are relative to the
current font and font size. In order to perform layout, the original
measure unit must be preserved and passed along with the original value.
This change introduces Converter::convertMeasureUnit, which parses a
measure string and returns both the value and the unit. Existing unit
conversion code has been refactored to facilitate this change.
Change-Id: Ic8dfda432e1ca117ad80c05c1939ebaf43e79a9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175937
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
ODF uses in several places data type 'angle' (18.3.1, ODF 1.3). That is
a double followed by unit identifier 'deg', 'grad' or 'rad' or a unit
less value in degrees. LO uses in the API angles in degrees, 1/10 of
degrees and 1/100 of degrees in data types 'double', 'short' and 'long'.
Without the fix LO does not interpret the units, but takes only the
number part.
Change-Id: Ib3f2a518a25199e3cf7a7a8572e169785f75c427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169360
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
.. and draw:rotation in <draw:hatch> element.
ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2
it is specified as double with unit "deg", "grad" or "rad", or without
unit. The unit-less value is specified to be in degrees. But OOo, AOO
and all LO versions had written the value unit-less in 1/10th of a
degree in some cases.
To fix it, LibreOffic will be enabled to read units. When then the
active versions are able to read units, starting with the then actual
version, LibreOffice will write angles with unit 'deg'.
This has already be done for gradients, see tdf#89475. This patch
starts the first step to make LibreOffice able to read units for
dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO
FillHatch.Angle). I have not found further cases of writing 1/10deg.
The patch still writes unit-less 1/10th of a degree for export to
ODF 1.3 and earlier. When it is time to write unit degree or when
LibreOffice supports the next ODF versions, some places need to be
adapted. They are marked.
The converter convertAngle is renamed to convert10thDegAngle() to
indicate, that it is special. The parts, which were specific to
gradients are moved to the gradients, so that it is now usable for
dr3d:angle and draw:rotation too.
I intend to write next a patch that enables LibreOffice to read angle
units for cases where LibreOffice already writes unit-less values in
degree. That is not so urgent, but to bring LibreOffice nearer to ODF,
reading angle units should be implemented nevertheless.
The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc
to have access to it from xmloff/source/draw.
Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Seen in a fedora:40 container, using --with-system-libcmis,
--with-system-liblangtag and --with-system-xmlsec.
Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Xisco Fauli