...which, according to callgrind, reduces instruction fetch count spent on
compiling sw/source/core/layout/paintfrm.cxx (randomly selected because it is
rather large) by 5% from 41,992,064,226 to 39,861,989,855 (function main() in
clang-6.0).
This is best done by forwarding ignoreLocation calls from Plugin to the
PluginHandler signleton, but due to the tight mutual coupling between plugin.hxx
and pluginhandler.hxx that unfortunately required some reorganization (and two
outstanding TODO clean-ups of temporarily introduced using declarations in
plugin.hxx).
Change-Id: Ia4270517d194def7db7ed80cb6894e9c473e9499
Jens says he was unhappy with the 80 cols limit, so clang-format was
explicitly avoided for these new files, but now that the both the config
and TEMPLATE.SOURCECODE.HEADER says 100, it's fine to reformat these to
enforce consistency from now on.
Change-Id: Ia6f0a65920ad2c9d7b0834a0712356568c39624e
Left indent was set to non-zero in the style, but direct formatting set
it back to zero. Teach deduplication to remove the
NS_ooxml::LN_CT_PPrBase_ind SPRM itself in case the last attribute was
removed.
Change-Id: I01b202f0241b02816b2b392326737b1150caffc2
Reviewed-on: https://gerrit.libreoffice.org/44385
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...when workdir/UnpackedTarball/lcms2/include/lcms2.h is included from
workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp
(Library_pdfium). Even with -std=gnu++17, GCC only emits a warning (that is not
promoted to an error when building external Library_pdfium) about "register",
but at least recent trunk Clang does emit an error by default. (Clang used to
have a bug by which it failed to emit any warning/error for uses of "register"
on function parameters, but that got recently fixed with
<http://llvm.org/viewvc/llvm-project?view=revision&revision=317140> "Fix missing
-Wregister warning when 'register' is applied to a function parameter", causing
an --enable-werror build failure now when building in C++17 mode with
<https://gerrit.libreoffice.org/#/c/43851/> "Build as C++17 when GCC/Clang
supports it" locally included.)
So instead of trying to further demote any warnings/errors about those uses of
"register", just patch them away for good.
Change-Id: I7c8757e654d87be710eaaafa871300656d9ee8ff
The WriterSpecificAutoFormatBlock class actually writes a length
into the file that covers the offending SwFormatVertOrient item.
Put in a gross hack to read either 32-bit or 64-bit in
SwFormatVertOrient::Store depending on that length.
The length also covers another item, so we'll just hope nobody ever
changes this stuff ever again!
Change-Id: Idf2f05cc00c098571508adb849f60940966c3328
Reviewed-on: https://gerrit.libreoffice.org/44254
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
There exists no documents produced by LibreOffice, where text on OLE
objects has worked, because import expects the paragraphs inside the
draw:object element, but LO has written them outside. The patch
changes LO to write the paragraphs inside the draw:object element.
The patch does not enable LibreOffice to read the paragraphs in
old documents. But versions at least since 5.1 will be able to read
text on OLE objects from documents which were produced by versions
with applied patch.
Change-Id: I879135f1a869e46c32361db653ede05227bab95e
Reviewed-on: https://gerrit.libreoffice.org/43696
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
... instead of an arbitrary reference range read from a binary
file format, here 4k sheets resulting in >3GB allocated listener
memory.
Change-Id: I629297f4249fdf16a0ede098b63d9648fda69ac3
Test: English word "Ian" are "item" are not allowed as "İan", "İtem" now.
Patch list with commit ids in Hunspell repository:
commit 66badb7449c2053c89456f11a7f71f3f5916b550
Extend dotless i and dotted I rules to Crimean Tatar language
commit 88cf975c295e3ec808efb77bb1a2a031d77f0c89
Allow dotted I in dictionary, and disable bad capitalization
commit 39b785a6b03b35cc8a27f43f6005dcaa432694e1
FORBIDDENWORD precedes BREAK
commit 0f691abe68788d0a58e72ab66877a9f670cd2741
Remove forbidden words from dash suggestion list
commit 15b2cde4f01706f0a648518a5cfc57394d015448
tdf#95024 fix compound handling for new Hungarian orthography
commit de3ae6844af62300e473f7b7b66a56e54153b4b9
fix compound word part "pa:"
Change-Id: Id12b5629b0c975464072b5b144743cbe40fe45a3
Reviewed-on: https://gerrit.libreoffice.org/44200
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
No idea how to check what fonts are installed on Windows/Mac;
only safe thing to do is to disable the tests if --without-fonts.
Change-Id: Ia27d866d9964f7e4e1ebfaba7ee4a7ce53b800b0
The TEST_FONTS_MISSING is already handling the --without-fonts case,
but if we build fonts we need a dependency.
Change-Id: I5164fc5c5974bbce7481b0b1ef4d6013eb9c0a11
When including a PDF as an image, it's represented internally as
a Bitmap with additional PDF data. On SwapIn, LibreOffice just
imported the PDF data missing the PDF preview. The Graphic also
gad the wrong image type, which results in a busy loop on master,
with a strange / unhelpful STR_COMCORE_READERROR generated by
SwNoTextFrame::PaintPicture.
This is a workaround to generate the Bitmap on SwapIn, which
will really slow down LibreOffice when importing many PDFs.
I guess the job of generating the PDF previews should probably
be deferred to a thread or a low priority Scheduler task, just
like the general image loading is handled.
Change-Id: I8084e4533995ecddc5b03ef19cb0c6a2dbf60ebd
Reviewed-on: https://gerrit.libreoffice.org/43906
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
1. Linking problem on Windows due to Windows macros via
<vcl/sysdata.hxx> include
2. Drop the custom MOC target for the old KF5 plugin
3. Correctly handle QT5 build without using QFont
4. ImplJobSetup is in the VL library, not the gen plugin
Change-Id: Iad97b1b9b57a8c356aaa88178aff03d0c14558c7
Since we implement SalGraphics handling like the gtk3 backend, we
need damage tracking to queue updates.
Since there is no native damage tracking in Qt5, we have to log
the damage in our subclassed QPainter, which will queue an update
on destruction.
Change-Id: Ife17770750a5be9959c2fc2633b422908d196869
