After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
The dates in core.xml must fall in the range of 1601 - 9999.
This applies to all docx files,
and ECMA_376_1ST_EDITION (2007) versions of the other formats.
No existing unit tests had ANY dates outside of that range.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf169072_illegalDates
Change-Id: Ic2c81d13a1a8ed9d2ce29f7fea761900aa2f2d20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193552
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The "hidden paragraph mark" feature is implemented to match the
feature of MS Word. In Writer, it is implemented using the same
"merged paragraphs" machinery as redlines; and some code doesn't
make distinction between the two.
The code, that calculates a number string, uses three internal
lists in SwTextNode to take redlines into account: mpNodeNum,
mpNodeNumRLHidden, mpNodeNumOrig, which reflect the hierarchy
effective for each mode. In "hidden redlines" mode, there are
no removed elements in the respective list. Therefore, number
string will be calculated from a different structure, and will
differ from the string generated from the original structure.
That is considered in SwTextFormatter::NewNumberPortion, which
calls SwTextNode::GetNumString with SwListRedlineType::HIDDEN
and SwListRedlineType::ORIGTEXT flags, compare the results, and
add the original text in [] after the current text.
Removal of elements hidden by redlines from mpNodeNumRLHidden
happens in CheckParaRedlineMerge, which finds fidden nodes, and
calls SwTextNode::RemoveFromListRLHidden for them. This change
makes sure that it is not called, when a node is not hidden by
a redline.
Change-Id: I93bc2c47bfefca115c1cbe47e53c7b0f7a119e4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193583
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
sd::DrawViewShell::FuTemporary() is quite long,
FN_TRANSFORM_DOCUMENT_STRUCTURE handling inside that is also long, so
make that a separate function.
Change-Id: Ief9e3704b8148900eb972ce0c144c444b03e640c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193584
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This is using the test document from fdo73254-1.xls.
Importing and exporting to XLSX and then running officeotron generates an error.
The xdr:twoCellAnchor has mandatory subelements, so we cannot skip writing them,
even if we have no graphic or media URL.
The code I am removing seems to be from
commit cbcffbaee2
Author: Jan Holesovsky <kendy@collabora.com>
Date: Tue Sep 5 16:53:14 2017 +0200
tdf#106867: Export videos in PPTX.
Change-Id: Ie095bad8ea9bf92b553448205f00c9cacf42d513
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193538
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 4158108427515dce8452dd1026a4f0412ce3ca9a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193570
Tested-by: Jenkins
Refines the password dialog for a cleaner user experience.
The main prompt now shows just the filename instead of the full path.
A the label clarifies whether a password to "open" or "edit" the
file is needed.
The OK button is disabled until a password is entered.
Change-Id: I1288fc94b81984b32f9ade33bd0cd52aa4439b1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163924
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
When solid lines are used for rendering the grid,
different input agruments are expected by DrawGrid() method.
The start position of the lines is needed, which is determined
by the edge of the drawing area.
Also move the DrawGrid() call out of the loop. It's enough to call
the rendering code once for the vertical and once for the horizontal
lines.
Change-Id: I1f1eddd2c3c9abd91fbd3e48eaee9bd10385ef6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193541
Reviewed-by: Tamás Zolnai <zolnaitamas2000@gmail.com>
Tested-by: Jenkins
The underlying problem was fixed in GTK 3.24, so this
workaround is no longer needed after
commit c392f7b8a6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 5 17:44:57 2025 +0100
gtk3: Require GTK >= 3.24
Change-Id: Idf5434f57e14285c2a0d3de1ab36e4eafeea9400
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193523
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
individual files and dirs with many files as well,
if they are related to any non-linux build, such as
Win, Mac, Emscripten, IOS, Android
Preparation for making this everybody elses problem,
but for now, only on linux builders
Change-Id: I94b0c76a8d7043538df930379e0703af7416bb3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192750
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Diagrams (SmartArt) had their separate counters for ids, and
when saving animation details, the shape to target wasn't
found, resulting in tags like this, where negative spid
is invalid:
<p:spTgt spid="-1"/>
See "19.5.72 spTgt (Shape Target)" in OOXML spec.
Ids can't be completely unified, as it would affect naming
in ppt/diagrams and on the UI to have large numbers
(eg. in the 40-60 range), while users would expect them
to start from 1.
At least ids to "p:cNvPr" under "p:graphicFrame" should be
unified.
The large number is because shapes are numbered consecutively
over all slides, while for the most part they could restart
on each slide, changing that is not in scope for this fix.
Change-Id: I9790036cc0743313e98f5926d4dc365c8051bd04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193479
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to 17a0bd4d2fdf9d53bc44bbea8391f000824948cc
- Fix help build after 2b322af4b9473210ed6a332115dac381f07039d6
+ Extra single quotes removed.
Change-Id: I1942ba10f3522ea8bfb0ee36239a21de971a0f98
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/193549
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
to increase IWYU coverage to some silently failing corner cases
found with bin/find-unneeded-includes --finderrors mode
Change-Id: Ifd85fceb56ff60c6e33229c36a427c3987778f67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192749
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
MS PowerPoint reports a corrupt presentation
if one of the ppt/media files contains non-ascii characters.
make CppunitTest_sd_export_tests-ooxml3 \
CPPUNIT_TEST_NAME=testTdf148478_transitionMusic
Change-Id: Ide5c5d38b4517e7a933fb8d414d901b49b15faca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193435
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Spotted with include/o3tl/vector_utils.hxx
it can happen that IWYU starts to consider a header having
all correct includes, in this case it does not give a list of
proposals.
This makes the previous method of spotting obsolete exclusions
ineffective in these cases.
Start watching for the "foo.hxx has correct #includes/fwd-decls"
announcement and consider every exclusion as obsolete
Change-Id: I46dd8dd4e2765a972ceaa7aa950d92c9e0a2d1b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192747
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
we install one when we create a document, so detect if that was removed
by something, which has happened historically on save, or export of a
selected element, but we want the original XInteractionHandler to be
restored when those complete.
Change-Id: I0886dd038a9167fd1b53e0b382fd52e6cb8a7610
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193465
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
at which point the cached value of the 'Modified' timestamp is that
of the pre-overwrite time. Drop the cached value and fetch it again
on next demand.
Otherwise another overwrite#2 attempt will compare against the
timestamp of the pre-overwrite-#1 and not of the post-overwrite#1
and a 2nd overwrite behaves differently that a 1st overwrite.
It assumes that the timestamp mismatch means the file has been modified
by an external event and requests an XInteractionHandler intervention to
approve the 2nd overwrite (but not the 1st overwrite).
This is indistinguisable from the 1st overwrite if there is no XInteractionHandler
during the 2nd overwrite, but not if there is an XInteractionHandler
set.
The QuietInteractionHandler, used for headless and silent mode, defaults to
aborting the save for queries it doesn't recognize, so will throws an exception in
this case.
The result is that CppunitTest_sfx2_misc 'testOverwrite' fails if the
same interaction handler present during the 1st overwrite is still
present during the 2nd overwrite. Which the next commit will introduce.
Change-Id: I80b997ce6adba38049c0e92bd8b18d160a0a2292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193522
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
SwTextNode represents a single paragraph. ParagraphIdleData stores word
and character counts. Each paragraph's text is limited by the underlying
text buffer (OUString) index, which is sal_Int32 (~2.1B chars). Using
sal_uInt32 (4.3B capacity) safely covers all possible characters per
paragraph, voids overflow and halves memory compared to 64-bit counters.
Change-Id: I421e3b455ea5019d955db7c25edcac99eb927dbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193012
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
This should whittle down this absolutely massive file and make it easier
to read and understand.
Change-Id: If2246b0b06ca5d1e9e92d45df2c8b3cfc1628178
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190883
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Otherwise the expanded field value is not visible in the dump, which was
interesting when working on tdf#165472.
Change-Id: I024ab4293d6131367eaccefbc23dae318362ac6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193515
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update helpcontent2 from branch 'master'
to 2b322af4b9473210ed6a332115dac381f07039d6
- simplify help makefile a bit
by copying the en-US file a single pattern rule can be used without the
need of using a generator/eval to add the targets/dependencies
Change-Id: Ie63fce1e3687f1e1ba46583529e6f4997c0aba44
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/192835
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
* Update helpcontent2 from branch 'master'
to 1e66ff8bd5bc9a11551a0b7246b443b992cdccd4
- tdf#168917 Sort options includes natural sorting
+ Refactor
+ Added text for the natural sort choices
+ Update how to get
Change-Id: If6ed18510baa49a9a95ead9145a67aa0c2396c1b
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/193499
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
No need to re-invent std::abs. Also drop some static_casts, to
allow warnings in case there will be unexpected values.
Change-Id: Iad1bc7fd22a1c517e4cdce28d156aa42fc5e6ec6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193507
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
If the node is in a fly, this can only print:
sw/source/core/doc/doclay.cxx:1619: Found a FlySection but not a Format!
This is a regression from commit
e07feb9457 which used the wrong node's
anchored objects: of course the fly is never anchored to itself, so this
will never find anything.
It turns out that there is already a function SwNode::GetFlyFormat()
that can do most of the work, even using the layout to speed it up, so
just use that to get the anchor.
Change-Id: I7a22231f929175ed7c5c11724882b03890781cfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193476
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
SwXShape::setPropertyValue() allows anchoring a shape to its own
textbox; this actually happens in testTdf146955.
Detect this and throw IllegalArgumentException.
Also catch the exception in GraphicImport::lcl_attribute() so the test
doesn't fail.
Change-Id: I236e12384e07793e0cf3474fc92657967d9249f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193475
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
... when there is an anchored object in the footer, and the last field
fits only partially on the line.
This stopped working with commit 8e3afdb598
removing the IsFooterFrame() check in SwTextFly::GetTop().
Previously a new line below the last line that fits on the page started
with the field rest portion, when the not-fitting line is deleted in
SwTextIter::TruncLines() this caused pDel->IsRest() to be true and
setting SetFollowField(true) which later caused the mbFieldFollow to be
set in the follow text frame.
Now the pDel->IsRest() is false because the line contains only a big fly
portion due to the fly in the footer, and then SetFieldFollow(false) and
the follow doesn't start with the rest of the field.
There is a long standing bug in lcl_NeedsFieldRest() causing this, it
simply doesn't work if there are multiple fields in a line, it
erroneously considers the first field to be the last one in the line.
Change-Id: I99e9f68e8e9f8019e4d22ce5d7874d4cdac285e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193474
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
The sal_uInt64 type should be appropriate for the nHex parameter because
the Out_Hex function's buffer holds up to 16 hex digits. To represent
the full range of those 16 hex digits you need a 64 bit value. Each hex
digit requires 4 bits, so 16 hex digits require 64 bits: 16 * 4 bits.
Change-Id: I21f73e7c7076368294df28fb009bf04aab983742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193309
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Instead of calling GetLocalizedChar for every character in the string to
be localized, we now just call a replacement function that returns the
offset to apply for digits. That means that in the likely case that the
offset is zero we can skip scanning the string altogether and just
return the original one.
Change-Id: I8b1ffa3ba38d5a8ed491668c7c1a242327bce626
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193462
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Apparently U+107B5 isn’t in the version of Noto Sans used by Debian so
the test fails for them. Seeing as it doesn’t really matter what the
character is as long as it’s outside of the BMP, let’s change the test
to use a character that is available in Debian to make things easier for
the package maintainers. I checked whether the new character should be
available by downloading the DejaVu Sans package from
packages.debian.org.
Change-Id: Ie0bd8d1e141ee41e84727bf7dee4f523a65ef210
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193497
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: René Engelhard <rene@debian.org>
Tested-by: Jenkins
Gabor Kelemen