A blank at the end of a line hangs outside the line by design, and the
justification of the line can leave it in the space that an object
reserved for its wrap: the text is stretched right up to the object, and
the blank starts where the reserved space begins. Its underline was then
drawn beside the object, which is no better than drawing it on the
margin.
The room such a blank was formatted against is measured before the line
is adjusted, so the check that keeps it inside the line cannot see this
coming, and the clamp that runs after the adjustment does not reach it:
the blank keeps no width of its own here, neither its own nor an extra
blank width, so there is nothing to compare a remaining room with.
Take the position instead, which is what the question really is: while
painting, the blank's own place in the line and the offset where the
object's reserved space starts are both known, so drop the decorations
of a blank that begins at or after that offset. A blank before an object
that still has room in front of it keeps them, as does one that Word
writes with its "underline trailing space" option on.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1d23a77b7b6767e82eb64ad76335f06f57ebe193
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7881
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit f42c56ae45f98e5081825ac0329226a175b9ed12)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208757
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A hyperlink at the end of a line looked like its underline reached past
the word. The blank after it is not part of the link and carries no
underline of its own, so nothing should have been drawn under it.
The blanks that a line break leaves over go into a hole portion, and the
painter only picks up character attributes for the text, field and tab
groups, which a hole portion belongs to none of. It was therefore painted
with whatever font the portion in front of it had left behind, in this
case the underlined one of the link, and the blank showed decorations
that the document never gave it. Seek the attributes for a hole portion
as well, so it is drawn with the font of the blanks it holds.
The hole was always painted with the wrong font, but it used to make no
difference: 90a83191a4 (Resolves: #i68503#
a SwHolePortion must not be decorated, 2013-01-03) took the decorations
off the hole's font again before drawing it. Since
b36f181bb7 (tdf#168777: Trailing space must
show all decorations, also for ODF, 2025-10-11) the blank keeps them, and
the wrong font became visible.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ie7cd9a5780dc449e12a2b4585c8f0b0c80e94235
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7877
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 84746ca8ab0725d55980a027e4c2744de47a8f94)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208756
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A blank at the end of a line ends up in a hole portion, and it can be
made in two places: SwTextPortion::Format_ splits off the blanks that no
longer fit the line, while SwTextPortion::FormatEOL peels off a blank
that did fit, which is what happens when text wraps around an object and
the line continues after it. Only the first one was taught to show the
blank's decorations, so the blank before such an object stayed bare while
Word underlines it. The test document, saved by Word with its
"underline trailing space" option on, shows both in one line: the blank
before the rectangle was not underlined, the ones at the end of the line
were.
The blank cannot end up decorated outside the space available to it. The
one Format_ makes is only decorated as far as it fits, and the one
FormatEOL makes was part of a portion that already fitted on the line, so
its room is there by construction. Checked against a rectangle moved past
the end of a line in steps of a fraction of a blank: decorations switch
off exactly when the remaining room drops below the blank's width.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I8f3ba57bbb8f00b30b9798cba1ac64270b87c197
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7866
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b3d35b9d0f907b7b2446c8ae26a53c382919e43b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208755
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
I believe that the problem was closing the socket too fast, before OS
could finish its IO; that resulted in TCP Reset (RST) instead of FIN,
and browser showed connection error.
This change implements a graceful shutdown, by closing the sending
half, then using an expiring wait for the peer's ACK/FIN. I suppose
that 5 s timeout is reasonable for local operations.
In fact, I wasn't able to reproduce the problem after commit id
I16efa58ba90b98e71b13a0081dcdcc9d660db0b6 (tdf#101630: Make local
HTTP server cross-platform, using boost/beast); but it could be only
because of HW performance, and I hope the change follows "best
practices".
Change-Id: Ic3e9cf4e841d254197129ea7905527e97cae481a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201715
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 40a71882e983ac28782293cc036479e405e66a1c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201821
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Bolding a word in the attached document scrambled its line: the words were
drawn on top of each other, and walking right through the text took the
cursor backwards at every space.
A line's terminating blank hangs outside the line (see
853e13f914, tdf#57187: make sure to put
trailing blanks to hole portion in narrow lines, 2023-12-30), so it must
not count towards the width the line would have without shrinking. That
was done by leaving out a hole portion with nothing after it, which is
only ever the last one. Since b36f181bb7
(tdf#168777: Trailing space must show all decorations, also for ODF,
2025-10-11) the blank is split in two - the part that may show its
decorations, and the rest - so the first of them was counted.
The line then looked wider than the text area, the last line of a
justified paragraph was block formatted after all, and the shrinking that
follows took the spaces well past zero width: a space of 60 twips ended up
advancing the cursor by -399.
Leave out every hole portion that has nothing of substance after it, not
only the last one, at both places that measure the line this way.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I7895492a20cc1bc3426da983abf298de935010ad
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7843
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 7ec0c8f3b4decace423eabbdb31269b5597c4747)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208742
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Commit b36f181bb7 (tdf#168777: Trailing
space must show all decorations, also for ODF, 2025-10-11) made the
trailing blank of a line show its underline by default. In a justified
paragraph that underline is drawn past the right margin.
A line's trailing blank lives in a hole portion, which deliberately takes
no part in the layout (see 853e13f914,
tdf#57187: make sure to put trailing blanks to hole portion in narrow
lines, 2023-12-30), so it hangs outside the line. When the blank is
formatted, its decorated part is limited to the room then left on the
line - but adjustment happens afterwards, and justification hands exactly
that room to the glue between the words. The blank ends up beyond the
text area with its decorations still on. Right-aligned text has the same
problem, and centred text has it on lines that nearly fill the width.
Reconsider the decorated part once the line is adjusted. The room still
available is the width of the trailing margin portion(s), which is where
adjustment parks whatever is left of the line, so no coordinates are
needed. Lines that need no adjustment at all - left-aligned ones - get no
margin portion, and keep the room they were formatted against.
Where the room no longer fits the whole blank, the hole is split: the
first part is decorated and as wide as the room, a plain hole carries the
rest. A hole holds nothing but blanks, so the characters divide between
the two in proportion to the width, and the cursor still travels over the
whole blank.
The blank also took a share of the justification stretch while being
painted, which made the overshoot about twice the width of a space. It
is not part of the line's content, so exclude it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I82dfe55a10f7b15969bc4561f8f2f04eb7eeee52
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7834
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 6ebdd28de79e412501152305b48a64d25b3609c5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208741
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
/DEBUG:FASTLINK was available from VS 2017 through VS 2022 and is gone in the
VS 2026 toolset:
https://learn.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=msvc-180
Its link.exe (14.51) answers the flag with "LNK4315: /DEBUG:FASTLINK is no
longer supported. Using /DEBUG:FULL instead." and links on, so a dbgutil build
would get that warning once per linked target - exactly what
b14cffdc89f9f38e05f346a9051d3420ee3b45cf ("Only use -debug:fastlink with
linkers that support it", 2026-07-17 11:51:25 +0500) set out to avoid for
lld-link.
That probe short-circuited to "supported" whenever the MSVC linker was
selected, so it never got to see this. Run it against the linker that will
actually be used in all cases (link.exe next to cl.exe, when lld-link is not
selected).
While at it, treat any mention of the flag in the probe output as "unusable",
instead of matching the -debug:full fallback wording alone. A linker that
takes the flag says nothing about it, so any complaint, however phrased, is
reason enough not to pass it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I125a3000ab82aa4b9371069cf4f5fd814a11f599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7818
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 3af47b423bbd0bb1882547e394b0b4c37e92de44)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208662
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
link.exe supports -debug:fastlink for native code, but for a managed/CLR
image it cannot apply it: it prints "/debug:fastlink unsupported; using
/debug:full" and falls back, once per such link. Until now that warning was
swallowed by filter-creatingLibrary.awk (the FASTLINK_IN_CLR_MESSAGE branch).
Handle it the same way the linker-capability and setup_native cases are
handled: simply don't pass the flag where it isn't usable. A target that
produces a managed image carries CXXCLROBJECTS/GENCXXCLROBJECTS at link
scope, so gate -debug:fastlink off when either is set (cli_uno,
cli_cppuhelper, climaker). No warning is emitted, so the awk branch that
filtered it - and the keep_firstline machinery that existed only to serve it
- are removed. This reverts commit
39d1838412 ("Suppress linker warnings for CLR
objects", 2024-02-23), which introduced the awk changes dropped here.
While here, split the decision by when its inputs are known: the static part
(a dbgutil build and a linker that supports the flag, HAVE_LINK_DEBUG_FASTLINK
probed at configure time) becomes a parse-time variable, and the per-target
carve-outs (managed images, setup_native DLLs) stay in an expansion-time
function that can see the target-scoped variables. This also lets the
ENABLE_DBGUTIL ifeq go away.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Idc15341b48d8781698afb1357539539a923fda6c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7223
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 235296b3302d5667c1a78f8cdffd4e03063e883e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208661
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
fastlink speeds up debug-build links, and MSVC link.exe supports it, but
lld-link does not: it prints "/debug:fastlink unsupported; using /debug:full"
on every link and falls back anyway, cluttering the build output with a
warning per linked target.
Add a configure probe (HAVE_LINK_DEBUG_FASTLINK) that checks whether the
selected linker actually supports the flag, and only pass -debug:fastlink
when it does. The probe tests the linker rather than hardcoding "lld has no
fastlink", so a future lld-link that gains support starts using it
automatically, with no further build-system change.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9f2638449909d75e6e627ca1d53ac56ff8035cca
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7156
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit b14cffdc89f9f38e05f346a9051d3420ee3b45cf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208660
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The images in the bug document are anchored to a paragraph that holds nothing
else, inside a text frame of a fixed height, and are centred vertically on
their paragraph's content. Such a paragraph has no text of its own, so its
height is whatever the object's own wrap gives it: the position and the area
it is measured against depend on each other. That circle has no solution
here, because a centred object needs a line of space above and below it
inside the paragraph (2 * 276 + 2400 = 2952 twips), more than the 2880 twips
of the frame. Layout alternated between a paragraph of a single line, with
the object ending up above the frame, and a paragraph filling the frame with
the object centred in it, and kept whichever of the two the pending
invalidations left behind. That is also why the same document changed its
appearance on a refresh and with the window size.
Take the content area of the text frame as the area to centre on, when the
anchor paragraph is the frame's only content and holds nothing but the
object. That is the space the paragraph can occupy, and unlike the paragraph
it does not follow the object, so there is one solution and layout reaches it
in a single pass. An object that fits into its anchor paragraph keeps using
the paragraph, so one placed next to the paragraph's own line stays there.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I8d642ea7328fde505a33d0fad727bc4b7fd2c457
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7833
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 7d264c9f67515623e0152515d00e07f20960d97c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208654
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In Word, an equation that shares its paragraph with other content is
an inline equation, which is typeset in non-display ("text") style:
fraction numerators and denominators (and n-ary limits) are drawn at
a reduced size. Math renders formulas in display style by default, so
an imported inline equation was noticeably taller than in the source;
in a tightly filled document the extra height pushed the following
content onto a new page.
Whether an equation is inline or a display equation (a paragraph's only
content) is not reliably marked in the file: Word decides it from the
paragraph content, and e.g. the RTF export drops the \moMathPara wrapper
that would otherwise flag a display equation. So the writerfilter now
decides it the same way, in one place for both the OOXML and RTF imports.
DomainMapper collects the formulas of each paragraph and, once the
paragraph is finished, puts them into Math text mode (re-fetching their
size) unless the formula was the paragraph's only content.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ia43118f49e0d1ac8f0dea653bf7a61c9063e8996
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7571
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit a555fecc5d5546b15b854b7400589e8010c01310)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208652
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The at-page reformatting loop added in 15c89cf1b7
("tdf#169158: Call FormatObjsAtFrame again, when at-page fly needs that",
2025-11-02) recorded the need for another pass with a page flag that was set by
SwPageFrame::InvalidateFlyLayout whenever it was called while the at-page objects
were being formatted. That also caught invalidations originating from
at-paragraph objects nested inside an at-page fly's content. For a document where
that content does not converge (a nearly frame-wide object centered on an empty
paragraph in a fixed-size at-page frame), those invalidations never stop, so the
flag was set on every pass and the loop never terminated: opening the document
hung.
Pass the invalidated anchored object to InvalidateFlyLayout, and set the flag
only when that object is anchored at the page.
Note that this deliberately narrows the trigger: the object is passed only from
SwFrame::InvalidatePage, the path these invalidations take; the other
InvalidateFlyLayout callers keep the default argument, so at-page invalidations
reaching the page through them no longer request another pass. This covers the
tdf#169158 case and this one; a future at-page scenario that needs the extra pass
through a different path must teach that caller to pass its object too. The
argument type is the SwAnchoredObject base so drawing objects can be passed as
well.
The in-formatting flag (m_bInAtPageFlyFormatting) becomes redundant and is
dropped: the at-page flag is cleared right before FormatObjsAtFrame and read
right after, which already scopes it to that call.
Change-Id: I294fc0e24a9a60bc82db08ba48047b8359d05b4c
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7701
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 0f6e508896252771857c65641b6676bf4a64acdb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208653
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A Ctrl+V changes a cell's content, not whether it is locked. Copying a
protected cell onto a cell the user had directly unprotected used to carry
the Protected flag along, so the target could no longer be edited, the
opposite of what Excel does and what tdf#123974 asks for.
Throughout this change "the cell's protection" means the protection set as
direct formatting on the cell itself. Protection can also come from a cell
style, and conditional formatting sets protection precisely by applying
such a style; those two are one and the same mechanism and, as noted at
the end, are deliberately left untouched here.
The two reports in this area pull in opposite directions: tdf#123974 wants
the direct flag dropped on paste, tdf#150910 wants it always retained, and
they were noted as contradictory. A rule gated on sheet protection (drop
the direct flag only when the sheet is protected and the target was
unprotected) was considered and rejected, because its outcome depends on
the order of otherwise unrelated steps: directly unprotecting a cell,
pasting into it, then protecting the sheet would re-lock it, while
protecting the sheet first and pasting after would not. That is impossible
to explain to a user.
Instead treat a cell's direct protection as a property of the cell that an
interactive paste never changes. Snapshot the destination's directly set
cell protection before the paste and restore it afterwards, so the pasted
attributes overwrite everything except that lock state. Routing both the
replicated-single-row fast path and the general path through the same
restore also removes the single-row versus multi-row inconsistency of
tdf#150910, which shared the same root cause.
Only directly applied protection is preserved. Protection that instead
comes from a cell style, including a style applied dynamically by
conditional formatting, is not touched and keeps following the usual paste
(in theory this could be extended to the effective protection if a need
shows up). The programmatic copyRange path is left unchanged and still
copies attributes verbatim; only an interactive paste opts in. A moved
cell (cut and paste) keeps its own protection and is excluded.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I3a1ec141c3ec698858ca8d058e6d9b1e9126402f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7069
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 39f30bd4b532f7575957210b644216afa14ac28b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208344
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When a document had several frames each containing a match, using Find
Previous only ever selected the match in the last frame; earlier frames
were skipped ("Find Next" and "Find All" were fine).
Backward text search walks the node array through SwNodes::GoPrevSection.
Since 691cfd22c6 ("tdf#159565: make sure to
handle leading hidden section correctly", 2024-02-14) that function stops
at the start of the current global section (here, a fly's start node), so
once the search stepped into a frame it could not move back into an
earlier one and got stuck in the last frame reached. GoPrevious got an
opt-in canCrossBoundary flag back then, but GoPrevSection did not.
Give GoPrevSection the same canCrossBoundary flag (default false, so plain
backward moves keep respecting section boundaries), and let the search
iterator in GetNode() opt in: it walks a range that is already bounded by
the PaM's mark, so crossing fly / header / footer / footnote boundaries
within that range is both wanted and safe. This also restores backward
Find across multiple headers, footers and footnotes. Forward search uses
GoNextSection, which was never limited - which is why Find Next and Find
All kept working.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I0c0971013d2fab19dac1de1e252586d7ea554c2b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 051e00083683db002942b94d0323c5d8fd13e6d4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208242
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When a chart shows a data table, it is drawn as a strip at the bottom of
the diagram, so the plot-area-plus-axes rectangle grows to include it. The
vertical axis title was centered on that rectangle and thus ended up shifted
downwards compared to MS Office, which centers it on the plot area alone.
Center the left- and right-aligned axis titles on the plot area rectangle
(which already excludes the data table) instead of on the plot area plus
axes, so the title stays centered on the axis.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: If21ba0938cea16abc382e686b9c4e2b84caf2dca
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6978
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 48953636f24d522426d5f5e4ed9f0fc5ec6f30f5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208241
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A bent connector (bentConnector3/4/5) that is not glued to a shape at both of
its ends has its path fully defined in the file: the preset geometry and its
adjustment values, in a bounding box that may have been resized by hand. Such a
path has to be kept as authored - re-routing it from the endpoints yields a
different shape, because orthogonal routing is heuristic and differs between
applications and over time (PowerPoint likewise keeps the drawn path and does
not reroute these connectors when they are moved or resized).
So far every bent connector was imported as a routed edge and the authored
handle positions were transferred onto the route as EdgeLine deltas. That is
reliable only when both ends are glued, where the route follows from the two
endpoints. With a free end the route escaped in the wrong direction and dropped
a corner, so e.g. a bentConnector4 arrived with two corners instead of three
and its arrow ended in empty space.
Now a connector that is not glued at both ends gets its authored OOXML path
imposed directly on the edge object via SetEdgeTrackPath, which svx then keeps
as a user-defined track instead of re-routing.
To build that path, the point computation that getOOXHandlePositionsHmm already
performed is extracted into a shared helper getOOXConnectorPointsHmm and reused
both to impose the path and to derive the handles, which are simply the
midpoints of its inner segments; this also drops the duplicated
adjustment/size/transform code.
The changed existing connector tests were checked against PowerPoint:
testTdf164623 and testTdf165180 render visually unchanged (their free connectors
already routed correctly, so only the import mechanism changed), while the newly
handled cases are improved.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I468b341c088f33ec7055747d18fe526975ef16e1
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6813
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 20bf9a09d9e19055f8d1d1da383c44c92585e733)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208152
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Extend PDFGraphicAnnotation with the raw PDF fields — /IRT, /RT,
/State, /StateModel, and /F plus each annotation's pdfium index —
that are needed to reconstruct a thread on the sd side.
The sd PDF filter uses them to:
- mark every imported PDF annotation as threaded (any PDF comment
can be replied to / resolved);
- link replies to their parent via /IRT (page-scoped per spec);
- collapse Acrobat-style state-change annotations into the target's
IsResolved flag — /IRT + /State + /StateModel, with /F carrying
the Hidden | NoZoom | NoRotate bits.
Only /StateModel = "Review" with /State = "Completed" maps to
resolved; other state models are discarded. /RT = "Group" is honoured
as a grouping relationship, not a reply. Acrobat's per-user state
model (each reviewer maintains their own state-change pointing at the
same target) is collapsed to a single boolean per comment — resolved
if any reviewer's latest state is Completed. The mapping is lossy;
the in-code comment on StateChange documents the trade-off.
Also make newly added comments threaded (allowing to resolve), when
the document is PDF.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I88e2bbe1202ada7b2e21a3ed90f2eb28760dcd6f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1455
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 72a729882982ebf29cbbc5bdf5000621b53b2d8a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207212
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Extend sdr::annotation::Annotation and AnnotationData with m_Threaded,
m_Resolved, and m_ParentId so a Draw annotation can carry a reply/resolve
relationship. The three fields are propagated by toData / fromData and
by sd::Annotation::clone; when IsThreaded() is true they are emitted
from Annotation::ToJSON and SdXImpressDocument::getPostIts under the
same keys (threaded, resolved, parentId) that ScModelObj::getPostIts
already uses for Calc.
The fields will be used by the PDF filter (follow-up commits) and left
at their defaults elsewhere; ODP, PPTX and ODF exporters are unchanged
and continue to ignore them. Support for [MS-PPTX] extensions [1] for
comments that introduce state and replies is not in the scope of this
patch series.
[1] https://learn.microsoft.com/en-us/openspecs/office_standards/ms-pptx/161bc2c9-98fc-46b7-852b-ba7ee77e2e54
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I49594e1e4698bfd541f4c5041362a52b675683fd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1454
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit bbde910405829527c92c406a82f75743bc4416c2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207199
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Calc's .uno:InsertThreadedComment slot mutated the note model directly
(GetOrCreateNote, SetText, SetThreadedCommentData, KitCommentNotify) and
never set the document-modified flag, so SFX did not broadcast
.uno:ModifiedStatus. The handler also did not register undo, so the
insert could not be rolled back. The same handler dropped the
SvtUserOptions fallback when the Author arg was passed but empty (the
ternary checked has-arg, not non-empty-value), letting the author land
as "Unknown Author" instead of the per-view WOPI UserFriendlyName.
Mirror ScDocFunc::ReplaceNote: a new InsertThreadedCommentOperation
runs inside ScDocShellModificator, releases any existing note (rescuing
its ScNoteData and a clone of its threaded payload), creates the new
note, builds the threaded payload plus the person-list entry, registers
ScUndoReplaceNote, and does the necessary finalizing calls. The author
resolution now uses the default-then-fallback chain so an empty Author
arg still routes through SvtUserOptions before the catch-all.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I42304b9467e8b290316b0fa8ba3c80c8fc0d9c35
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4142
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit d0935091c608f7184d00669b85f98e5b4b5fe1b4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207111
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When a cell spans across pages, and its text has a "below paragraph" spacing,
that spacing is included into the last follow text frame's bottom margin, not
into precede's. Reformat will check if the follow text could be joined back;
and in that check, it checked if the space available on the previous page was
enough for text height plus the existing bottom margin of the precede. That
could lead to oscillation, when the following join would add the spacing to
the precede, and then the frame became too tall, causing split; in the end,
a loop guard would stop the layout and produce inconsistent result.
This change takes the lower spacing into account. To check that the line is
indeed the last line in cell, it uses a call to GetIndNext(), as already done
in other places. This is only an approximation: GetIndNext() returns the next
sibling within the same cell frame, so it cannot see a following paragraph
that has moved wholly to a later page. It seems acceptable: it is likely that
if a line from the following page will fit to the previous one, then its next
paragraph's line (if any) already were on the same page as that line.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ifc3b9487a85fdd373c92187064b99ebfb65b68a4
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4733
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 459f7b6e4c532cf7abd2acb3975e380b90bdc5a0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206995
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The expression calculates needed narrow blanks, after wide blanks
were calculated. The calculation assumes narrow blank 1/4th of a
wide blank; the possible result is 0 to 3.
Also: drop the variable for 0.5, used once. The operation here is
"multiply by 2"; using "divide by 0.5" for that is confusing, and
unless there is some rationale behind that (like IEEE-754-specific
details giving different results here), better use simpler form.
In this case, the variable came from commit
074f0ab1d7 (tdf#76296 Import MathML's
<mspace>, 2016-11-15), and back then, it was Fraction; there seems
to be no specific need for division here.
Change-Id: I0260580023af005efb00eaba06ab6497cc269d43
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1111
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1169
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit ccf247612e1cfaaf7cd53f250f4a2719a10fa524)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206654
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Seen on my VS2026 build:
"C:\lo\online.build\workdir\UnpackedTarball\python3\PCBuild\pcbuild.sln" (Build target) (1) ->
"C:\lo\online.build\workdir\UnpackedTarball\python3\PCBuild\pythonw_uwp.vcxproj" (default target) (42) ->
(ClCompile target) ->
C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.51.36231\include\experimental\coroutine(37,1): error C2338: static assertion failed: 'error STL1011: The /await compiler option, <experimental/coroutine>, <experimental/generator>, and <experimental/resumable> are deprecated by Microsoft and will be REMOVED SOON. They are superseded by the C++20 <coroutine> and C++23 <generator> headers. You can define _SILENCE_EXPERIMENTAL_COROUTINE_DEPRECATION_WARNINGS to suppress this error for now.' [C:\lo\online.build\workdir\UnpackedTarball\python3\PCBuild\pythonw_uwp.vcxproj]
Use CL env variable to pass the define through MSBuild to cl.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Id9658290bfcd52150e5e1465a8c3f7e7e84de886
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2647
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 2157c69794264ff0567c7327509fb1a2d4fc5cb6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206340
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
An empty picture placeholder on a slide used to export as <p:pic>
with the internal "Insert Image" icon embedded as
<a:blipFill><a:stretch/>, which PowerPoint stretched across the
whole slide. Emit it as <p:sp> with <p:ph type="pic"/> and an empty
<p:spPr/> so geometry, fill and any custGeom from the layout get
inherited.
The layout-side <p:ph type="pic"/> used to be mapped to a
presentation.OutlinerShape and re-exported as <p:ph type="body"/>,
breaking slide-side inheritance on round-trip (the slide's
<p:ph type="pic"/> couldn't find a matching pic placeholder on the
layout and ended up 0x0 and invisible). Map XML_pic to
presentation.GraphicObjectShape on layouts too, matching the slide.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ie21f7dfe6822b8ddf00a443c523db89d926dcadc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3068
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 73f1e76b1760d4e936aa22627623c922dcda964b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205693
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add SID_INSERT_THREADED_COMMENT slot (.uno:InsertThreadedComment) and
SID_RESOLVE_THREADED_COMMENT slot (.uno:ResolveComment) to the Calc cell
shell. The insert handler creates a note with ScThreadedCommentData,
generates a random GUID for the comment and a deterministic UUID v5
(SHA-1, RFC 4122) for the person entry. The resolve handler toggles the
resolved state.
Include "threaded" and "resolved" fields in the COKit comment JSON
payload; when COKit is active, send the actual threaded root text
instead of the legacy fallback.
Rename .uno:InsertAnnotation label to "Insert Note" in Calc, and add
.uno:InsertThreadedComment as "Insert Comment" — matching Excel's
terminology where Notes are the old-style and Comments are threaded.
The unit test for this is on the Online side (cypress).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I398ee844d8706626eb859447021c4d4630d48631
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/804
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 894a2346a3fd37f9404147137f6bc5fe94c2fc99)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205352
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
C:/lo/online.build/workdir/UnpackedTarball/breakpad/src/client/windows/crash_generation/minidump_generator.cc(180): error C2653: 'stdext': is not a class or namespace name
C:/lo/online.build/workdir/UnpackedTarball/breakpad/src/client/windows/crash_generation/minidump_generator.cc(180): error C2059: syntax error: '>'
make[1]: *** [C:/lo/online/engine/solenv/gbuild/LinkTarget.mk:398: C:/lo/online.build/workdir/GenCxxObject/UnpackedTarball/breakpad/src/client/windows/crash_generation/minidump_generator.o] Error 2
As documented at https://learn.microsoft.com/en-us/cpp/porting/features-deprecated-in-visual-studio,
the class checked_array_iterator is dropped in MSVC 14.51 (it was deprecated since VS 2022 17.8).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I29ad7dcf10a6ccc79e66dd21a96d80a69d8f0f99
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2683
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 2450d80b2790bd47c534bdf45e0e839839e9cf64)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205370
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Store the full threaded comment data as loext: extension elements inside
office:annotation: root text, GUID, person-id, datetime, resolved flag,
and replies. The person list is written as a separate loext:persons
element at the spreadsheet body level, referenced by person-id from
each annotation.
The loext:resolved attribute on office:annotation is not used for Calc
annotations, since resolving only applies to threaded comments; the
flag is an attribute on loext:threaded-comment instead.
Extend the libreoffice ODF schema with loext:threaded-comment,
loext:reply, loext:persons, and related attributes. Add xmloff tokens
for the new element and attribute names.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ibdb6cca545c853b196a8ec234b26542d392967bb
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/803
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8cddb66d12942025e223d0d54f6bca03ac3b7f94)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205296
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Write xl/threadedComments/threadedComment*.xml per sheet and
xl/persons/person.xml at the workbook level. Add Relationship enum
entries for THREADEDCOMMENT and PERSON. Link the legacy <comment> to its
threaded counterpart via the guid attribute. Use sax_fastparser::UseIf
for optional attributes.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I53ac1e4ce761956201d09cf96376a79b6d041e1b
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/802
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit cfdad0c5ad529ecbfef4237850dbfa31ac0e4937)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205295
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Register the threadedcomments namespace and tokens in oox. Add
PersonsFragment (workbook-level) to import xl/persons/person.xml and
ThreadedCommentsFragment (worksheet-level) to import
xl/threadedComments/threadedComment*.xml. The fragment runs after
CommentsBuffer::finalizeImport() so that ScPostIt objects already exist;
it attaches ScThreadedCommentData with root text, reply chain, and
resolved flag to matching notes. Both the legacy fallback text and the
actual threaded comment text are preserved in the document model.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I0a47c74dc31ae8bb008d2a8da76a97ae3957dcc0
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/801
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 205ea7e4fb13b18b1940f287f4cbad60c8aee9cc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205294
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add ScThreadedCommentData, ScThreadedCommentEntry, and ScPersonData
structs to support the Excel "threaded comments" feature ([MS-XLSX]
sections 2.3.7, 2.6.205). ScPostIt gains an optional
mpThreadedCommentData member with IsResolved()/SetResolved() accessors
for the "done" flag, and ScDocument gains a person list (AddPerson,
GetPersonById). Clone() preserves threaded data in both code paths.
This is the document model foundation for comment resolution in Calc;
import/export/LOK/Online follow separately.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ic782f9126c38088292b068066ba0de3889563531
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/800
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 3f8cd9c6ab6738a434788cb9280373413a0b7205)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205293
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
In this case, a floating table had too large row height to fit on page;
an attempt to split failed, but the table didn't move to the next page,
because the height of the fly was limited to the bottom of the page, so
fitted.
This change adds a special handling of the anchor frame for floating
tables. When the floating table is too high (taller than its fly, which
is limited to the page's available space), the anchor height itself is
increased to match the table height. This would initiate a split of the
frame, or its move to the next page, as appropriate.
This fixes both the hang in testSplitFlyInTextSection, and its layout.
Change-Id: I8d2353a6b978fcf885d409726377b59a37ada435
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/164
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 2396da33a195e9f4468377fa9c44c24f2bf74157)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205208
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Split floating tables (or rather, their flys) anchor to a single split
paragraph (so there is a sequence of follows), where the whole content
of the anchor paragraph is in the last follow frame. All the previous
text frames have empty m_xParaPortion.
SwTextIter requires a frame with non-empty m_xParaPortion.
SwEditShell::GetCurWord gets current cursor, then its point's node;
and finally, the node's layout frame - the first in the sequence. This
commit avoids the crash by getting the correct follow frame.
Change-Id: I8bf0025144642127057c0bdeab0a4dfcd798c261
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/48
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit ae632b50ef91d64a8aa84b9c9c80d8217e4d8e50)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203634
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
This is safe to ignore both, when one of them empty, as opposed to a
case when both are non-empty, but have different number of elements.
Allows to read some broken real-life documents.
A possible TODO: maybe consider to warn about a broken package, and
only open in repair mode?
Change-Id: I0697dcc73933aa1761ba59a766a519965872a0ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202552
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 92e7f28f9a (Related: tdf#104718
Use package repair request and behavior, 2023-11-29) made repaired
documents behave like templates, requiring user to explicitly choose
a name on save.
Since switching to template mode happens in this case rather late in
the loading procedure, at this point, lock file is already created
for the original file. Switching to template mode clears media URL;
and after that, media can't remove the lockfile.
This change releases the lock (and removes the lockfile) prior to
clearing URL.
Change-Id: Ibd4794e2b82dc8e1b1c96e22fa2089b9dd597744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202521
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When EndTOX() closed the TOC field during the last paragraph's run, the }}}
went into m_aRunText and ended up before \par, putting the \par outside the
field result. Word then ignored paragraph properties for that last paragraph.
This change defers outputting the closing braces until after \par is written.
Change-Id: I6d7ab3b516e725938fc2151f8ec4f4b834f33068
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202379
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit Ic9da5b2f8b47818a47e03cac620440108e0ca595 handled the non-rotated case
by using LayoutSize instead of the Size property. But for images that are both
rotated AND scaled (e.g., relative width + rotation), Size still gave the
unstretched unrotated dimensions — wrong for both wp:extent and a:xfrm/a:ext.
Derive the scale factor from the bounding box (LayoutSize), the unscaled size
(Size property), and the rotation angle. Get the stretched-but-unrotated size
scaling Size by it. This handles all three cases.
There is some difference how rotated+scaled objects are layed out by Writer
and Word. This change improves the export to DOCX, but not perfectly.
Change-Id: I013659d324b9f3e9f5f2e9ee737544ea5610bd17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202408
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The fix for tdf#138953 changed the DOCX image export to always use the
UNO Size property (unrotated dimensions) instead of the frame LayoutSize.
This is correct for rotated unstretched images, where LayoutSize includes
the rotation bounding box. But for non-rotated images where Size differs
from LayoutSize (e.g., frames with style:rel-width="100%" imported from
HTML or saved by older LO versions), it used the unstretched size, giving
wrong image size.
Only use the Size property when the image is actually rotated.
Note: if an image is both rotated AND scaled, Size still gives the wrong
(unstretched unrotated) dimensions. The correct fix for that case would
require deriving the scale factor from Size, LayoutSize, and the rotation
angle.
Change-Id: Ic9da5b2f8b47818a47e03cac620440108e0ca595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202386
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
A deadlock seen with the following call stacks.
Main thread is trying to paint in a timer event, and is waiting for
the FormComponentPropertyHandler's mutex:
ntdll.dll!NtWaitForAlertByThreadId()
ntdll.dll!RtlpWaitOnCriticalSection()
ntdll.dll!RtlpEnterCriticalSectionContended()
ntdll.dll!RtlEnterCriticalSection()
sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 65
pcrlo.dll!osl::Mutex::acquire() Line 63
pcrlo.dll!osl::Guard<osl::Mutex>::Guard<osl::Mutex>(osl::Mutex & t) Line 144
• pcrlo.dll!pcr::FormComponentPropertyHandler::getPropertyValue(const rtl::OUString & _rPropertyName) Line 307
pcrlo.dll!pcr::OPropertyBrowserController::impl_getPropertyValue_throw(const rtl::OUString & _rPropertyName) Line 907
pcrlo.dll!pcr::OPropertyBrowserController::propertyChange(const com::sun::star::beans::PropertyChangeEvent & _rEvent) Line 661
cppuhelper3MSC.dll!cppu::OPropertySetHelper::fire(long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, unsigned char bVetoable) Line 733
comphelper.dll!comphelper::OPropertySetAggregationHelper::propertiesChange(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyChangeEvent> & _rEvents) Line 420
cppuhelper3MSC.dll!cppu::OPropertySetHelper::firePropertiesChangeEvent(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames, const com::sun::star::uno::Reference<com::sun::star::beans::XPropertiesChangeListener> & rListener) Line 961
tklo.dll!ControlContainerBase::ImplUpdateResourceResolver() Line 1698
tklo.dll!ControlContainerBase::ImplStartListingForResourceEvents() Line 1675
tklo.dll!ControlContainerBase::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & rxModel) Line 1428
tklo.dll!UnoDialogControl::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & rxModel) Line 348
svxcorelo.dll!sdr::contact::`anonymous namespace'::ControlHolder::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & _m) Line 186
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::createControlForDevice(const sdr::contact::`anonymous-namespace'::IPageViewAccess & _rPageView, const OutputDevice & _rDevice, const SdrUnoObj & _rUnoObject, const basegfx::B2DHomMatrix & _rInitialViewTransformation, const basegfx::B2DHomMatrix & _rInitialZoomNormalization, sdr::contact::`anonymous-namespace'::ControlHolder & _out_rControl) Line 1097
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::impl_ensureControl_nothrow(const sdr::contact::`anonymous-namespace'::IPageViewAccess & _rPageView, const OutputDevice & _rDevice, const basegfx::B2DHomMatrix & _rInitialViewTransformation) Line 1037
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::ensureControl(const basegfx::B2DHomMatrix * _pInitialViewTransformationOrNULL) Line 963
svxcorelo.dll!sdr::contact::`anonymous namespace'::LazyControlCreationPrimitive2D::create2DDecomposition(const drawinglayer::geometry::ViewInformation2D & _rViewInformation) Line 1539
drawinglayercorelo.dll!drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & rViewInformation) Line 79
svxcorelo.dll!sdr::contact::`anonymous namespace'::LazyControlCreationPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & _rViewInformation) Line 1523
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 43
drawinglayerlo.dll!drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 374
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::Primitive2DContainer & rSource) Line 67
svxcorelo.dll!sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo) Line 303
svxcorelo.dll!sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo) Line 128
svxcorelo.dll!SdrPageWindow::RedrawLayer(const o3tl::strong_int<short,SdrLayerIDTag> * pId, sdr::contact::ViewObjectContactRedirector * pRedirector, const basegfx::B2IRange * pPageFrame) Line 422
svxcorelo.dll!SdrPageView::DrawLayer(o3tl::strong_int<short,SdrLayerIDTag> nID, OutputDevice * pGivenTarget, sdr::contact::ViewObjectContactRedirector * pRedirector, const tools::Rectangle & rRect, const basegfx::B2IRange * pPageFrame) Line 304
svxcorelo.dll!SdrPaintView::ImpFormLayerDrawing(SdrPaintWindow & rPaintWindow, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 798
svxcorelo.dll!SdrPaintView::EndCompleteRedraw(SdrPaintWindow & rPaintWindow, bool bPaintFormLayer, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 653
svxcorelo.dll!SdrPaintView::EndDrawLayers(SdrPaintWindow & rPaintWindow, bool bPaintFormLayer, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 726
basctllo.dll!basctl::DlgEditor::Paint(OutputDevice & rRenderContext, const tools::Rectangle & rRect) Line 547
basctllo.dll!basctl::DialogWindow::Paint(OutputDevice & rRenderContext, const tools::Rectangle & rRect) Line 124
vcllo.dll!PaintHelper::DoPaint(const vcl::Region * pRegion) Line 316
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 618
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!vcl::Window::ImplCallOverlapPaint() Line 645
vcllo.dll!vcl::Window::ImplHandlePaintHdl(Timer * __formal) Line 668
vcllo.dll!vcl::Window::LinkStubImplHandlePaintHdl(void * instance, Timer * data) Line 649
vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 105
vcllo.dll!Timer::Invoke() Line 75
vcllo.dll!Scheduler::CallbackTaskScheduling() Line 615
vcllo.dll!SalTimer::CallCallback() Line 53
vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 169
vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 443
vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 499
vcllo.dll!InnerYield(bool i_bWait, bool i_bAllEvents) Line 389
vcllo.dll!Application::Yield() Line 502
vcllo.dll!Application::Execute() Line 365
sofficeapp.dll!desktop::Desktop::Main() Line 1681
vcllo.dll!ImplSVMain() Line 230
vcllo.dll!SVMain() Line 249
sofficeapp.dll!soffice_main() Line 122
soffice.bin!sal_main() Line 51
soffice.bin!main(int argc, char * * argv) Line 49
soffice.bin!invoke_main() Line 79
soffice.bin!__scrt_common_main_seh() Line 288
soffice.bin!__scrt_common_main() Line 331
soffice.bin!mainCRTStartup(void * __formal) Line 17
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
while the worker thread is holding the mutex and is sending a message
to the main thread synchronously:
win32u.dll!NtUserMessageCall()
user32.dll!SendMessageWorker()
user32.dll!SendMessageInternal(struct HWND__ *,unsigned int,unsigned __int64,__int64,int)
user32.dll!SendMessageW()
vclplug_winlo.dll!WinSalInstance::SendWndMessage_impl(HWND__ * hWnd, unsigned int Msg, unsigned __int64 wParam, __int64 lParam) Line 689
vclplug_winlo.dll!WinSalInstance::SendComWndMessage(unsigned int Msg, unsigned __int64 wParam, __int64 lParam) Line 700
vclplug_winlo.dll!WinSalFrame::ReleaseGraphics(SalGraphics * pGraphics) Line 1052
vcllo.dll!vcl::WindowOutputDevice::ReleaseGraphics(bool bRelease) Line 905
vcllo.dll!vcl::Window::dispose() Line 487
vcllo.dll!ImplBorderWindow::dispose() Line 1614
vcllo.dll!VclReferenceBase::disposeOnce() Line 38
vcllo.dll!VclPtr<ImplBorderWindow>::disposeAndClear() Line 224
vcllo.dll!ScopedVclPtr<ImplBorderWindow>::~ScopedVclPtr<ImplBorderWindow>() Line 351
vcllo.dll!ScopedVclPtrInstance<ImplBorderWindow>::~ScopedVclPtrInstance<ImplBorderWindow>()
vcllo.dll!Dialog::GetDrawWindowBorder(long & rLeftBorder, long & rTopBorder, long & rRightBorder, long & rBottomBorder) Line 1389
tklo.dll!VCLXDialog::getInfo() Line 2302
basctllo.dll!basctl::DlgEdForm::getDeviceInfo() Line 1642
basctllo.dll!basctl::DlgEdObj::TransformFormToSdrCoordinates(long nXIn, long nYIn, long nWidthIn, long nHeightIn, long & nXOut, long & nYOut, long & nWidthOut, long & nHeightOut) Line 351
basctllo.dll!basctl::DlgEditor::AdjustPageSize() Line 1182
basctllo.dll!basctl::DlgEditor::SetDialog(const com::sun::star::uno::Reference<com::sun::star::container::XNameContainer> & xUnoControlDialogModel) Line 351
basctllo.dll!basctl::DlgEditor::ResetDialog() Line 409
basctllo.dll!basctl::DlgEdObj::_propertyChange(const com::sun::star::beans::PropertyChangeEvent & evt) Line 1147
basctllo.dll!basctl::DlgEdPropListenerImpl::propertyChange(const com::sun::star::beans::PropertyChangeEvent & evt) Line 44
cppuhelper3MSC.dll!cppu::OPropertySetHelper::fire(long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, unsigned char bVetoable) Line 733
comphelper.dll!comphelper::OPropertySetAggregationHelper::propertiesChange(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyChangeEvent> & _rEvents) Line 398
comphelper.dll!comphelper::OPropertySetHelper::fire(std::unique_lock<std::mutex> & rGuard, const long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, bool bVetoable) Line 594
comphelper.dll!comphelper::OPropertySetHelper::impl_fireAll(std::unique_lock<std::mutex> & rGuard, long * i_handles, const com::sun::star::uno::Any * i_newValues, const com::sun::star::uno::Any * i_oldValues, long i_count) Line 487
comphelper.dll!comphelper::OPropertySetHelper::setFastPropertyValues(std::unique_lock<std::mutex> & rGuard, long nSeqLen, long * pHandles, const com::sun::star::uno::Any * pValues, long nHitCount) Line 748
tklo.dll!UnoControlModel::setFastPropertyValueImpl(std::unique_lock<std::mutex> & rGuard, long nPropId, const com::sun::star::uno::Any & rValue) Line 1247
comphelper.dll!comphelper::OPropertySetHelper::setFastPropertyValue(long nHandle, const com::sun::star::uno::Any & rValue) Line 393
comphelper.dll!comphelper::OPropertySetAggregationHelper::setFastPropertyValue(long _nHandle, const com::sun::star::uno::Any & _rValue) Line 528
cppuhelper3MSC.dll!cppu::OPropertySetHelper::setPropertyValue(const rtl::OUString & rPropertyName, const com::sun::star::uno::Any & rValue) Line 264
• pcrlo.dll!pcr::FormComponentPropertyHandler::setPropertyValue(const rtl::OUString & _rPropertyName, const com::sun::star::uno::Any & _rValue) Line 465
pcrlo.dll!pcr::OPropertyBrowserController::Commit(const rtl::OUString & rName, const com::sun::star::uno::Any & _rValue) Line 1326
pcrlo.dll!pcr::OBrowserListBox::valueChanged(const com::sun::star::uno::Reference<com::sun::star::inspection::XPropertyControl> & _rxControl) Line 637
pcrlo.dll!pcr::PropertyControlContext_Impl::impl_processEvent_throw(const comphelper::AnyEvent & _rEvent) Line 291
pcrlo.dll!pcr::PropertyControlContext_Impl::processEvent(const comphelper::AnyEvent & _rEvent) Line 272
comphelper.dll!comphelper::AsyncEventNotifierBase::execute() Line 138
comphelper.dll!comphelper::AsyncEventNotifier::execute() Line 155
salhelper3MSC.dll!salhelper::Thread::run() Line 40
salhelper3MSC.dll!threadFunc(void * param) Line 190
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void *),1>(void * const parameter) Line 97
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
In this case, there is no reason to hold the mutex so long. It is only
needed to get copies of the object state, so only lock the mutex for
that necessary time frame.
Change-Id: Iab8bedb901295a6936d85de1cfb20efa2ce8a4f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202299
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit b3bfae88b6 (separate ImpSdrPdfImport's
by prefix, 2025-10-17) introduced a prefix to font filenames, apparently
to avoid same filenames in different imports. It used ImpSdrPdfImport's
pointer for that. However, it may happen that the next time it imports, the
new instance of ImpSdrPdfImport may get allocated at exactly same address.
Then afdko's cbConvert may abort because of failed fileopen.
This adds a static counter to the prefix string. I decided to keep also
the pointer, to avoid a hypothetical clash in case of a font name statring
with a short number like 0 or 1. In theory, we should use methods that
create unique temporary names instead.
Change-Id: Ia52b45002d3fe9e008bed33bc90cec190929e519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201785
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C3083: 'FileBase': the symbol to the left of a '::' must be a type
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C2039: 'getSystemPathFromFileURL': is not a member of 'osl'
C:\lo\core\include\osl/getglobalmutex.hxx(29): note: see declaration of 'osl'
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C3861: 'getSystemPathFromFileURL': identifier not found
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C3083: 'FileBase': the symbol to the left of a '::' must be a type
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C2039: 'E_None': is not a member of 'osl'
C:\lo\core\include\osl/getglobalmutex.hxx(29): note: see declaration of 'osl'
C:/lo/core/sw/source/uibase/misc/glosdoc.cxx(452): error C2065: 'E_None': undeclared identifier
Change-Id: I96d48b961522c508a71c99d3046046842b2ad865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201535
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A follow-up to commit 309461e70e.
Thanks cloph for the := immediate assignment idea. Additionally, no
need to spawn inner shells to cd and pwd.
On my system, running 'make firebird.clean && time make firebird',
without the patch, I see
real 8m15.444s
user 0m0.109s
sys 0m0.062s
and with the patch:
real 2m48.370s
user 0m0.015s
sys 0m0.015s
Change-Id: If299139372b3c20d791f4dc1b77a9b127c478384
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201534
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The patch relies on $(ROOT) being an absolute mixed (using /) path.
With that assumption, it's enough to replace / with \, without a
need to start a shell and call cygpath.
On my system, running 'make firebird.clean && time make firebird',
without the patch, I see
real 15m9.346s
user 0m0.015s
sys 0m0.015s
and with the patch:
real 8m15.444s
user 0m0.109s
sys 0m0.062s
Change-Id: I72866a92e88a6977339e447b7d9ab1a9b1be84fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201527
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When e.g. fTextLeftDistance was 0, and fTextRightDistance was large,
the old code made fTextLeftDistance negative.
Interestingly, a scale-to-textsize approach does not work, I tried this:
const double correctionFactor = fWidthForText / (fTextLeftDistance + fTextRightDistance);
fTextLeftDistance *= correctionFactor;
fTextRightDistance *= correctionFactor;
which correctly gave non-negative distances with their sum equal to
fHeightForText; but the text was still not positioned correctly. But
this change puts the text to the expected position, despite the sum
of the distances is still greater than text size.
The numbers in the unit test reflect correct rendering using current
method.
Change-Id: Ie6fab6570a4a5675d4356c074d5f7eb54e6b5026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201337
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For the case when mnShapePresetType >= 0, the code setting it was added
in commit c50e44b270 (tdf#126060 Handle
text camera z rotation while pptx import., 2019-10-16). But it omitted
the other case.
This change also improves positioning of the rotated text, initially
implemented in that commit. The rotation is now added to the block text
decomposition as a separate transform primitive. The text center is now
obtained directly from the decomposition. After the change, I see about
1-pixel difference compared to PowerPoint render at 100% zoom (before
that, the offset was tens of millimeters).
testTdf128212 had to be corrected, because the metafile now has a new
element in the parsed XML, and the final positioning has changed (it is
better now). Unfortunately, I don't know what would it now produce if
the fix is broken, so I had to remove respective comment.
This change does not fix tdf#128206.
Change-Id: I86cbd0710744b14e8b9b68a436affc5b08703a12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201286
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Before this, the function created at most 1024 rows in ScTableInfo,
which is OK for notmal pages, but is limiting whole sheet export.
Change-Id: Ie1663147476f56e879673a7532ec9ae8bb28ac68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201204
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
The assertion added in commit 58f2c1e6ab
(tdf#135413: sw: Add UItest, 2025-03-04) used page count 16, obviously
because that is what Writer shows opening the file. But the number is
caused by a wrong layout; the table in the document unexpectedly takes
two pages.
Testing the UI test on Windows, I see
AssertionError: '16' != '15'
and that's the same what Stephan reported on
https://gerrit.libreoffice.org/c/core/+/130940/comment/5a512c89_ff82b3a3.
So let the test assert on "no less than 15".
Change-Id: I3df87d40eb4b7e810f30123683e91f85f9632588
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201176
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This patch removes surrogates and PUA from scriptList, to match how
Excel calculates.
It also simplifies implementations of lcl_RightB / lcl_LeftB.
Change-Id: I4af1069eda790df0dda7f402fe4b5f3c47c42c34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201161
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Introduced in commit 0946de1e2f
(Resolves: #i121120 Support RightB(), LeftB(), LenB() and MidB(),
2013-06-11), it assumed that scriptList (added in the same commit)
was strictly sorted. However, that wasn't enforced. This change
adds a couple of static asserts, making sure that each pair is
strictly ordered ('from', 'to'); and all pairs have 'to' of the
previous pair less than 'from' of the next.
The complex check in 'is_sorted' is because at least on Windows,
simple "l.to < r.from" predicate returns 'sorted' for overlapping
ranges, because it only checks that negation of the predicate is
false for the pair "next, prev".
That discovered an element in the array, that was most definitely a
leftover from development: the element with index 2 had 'from' and
'to' in reverse. The interesting thing is, that if reversed back,
they form a range completely covering from element index 1 to index
3. It is likely that the element index 2 was intentionally reverted
(and put in that position) - to not participate in the search. This
change drops that leftover.
Two elements - index 2 and index 4 - had overlapping ranges. That
meant that they actually formed a single large range; this change
merges them. Important to notice, that this range includes blocks
with surrogates and PUA; that explains handling of SMP characters
(tdf#171165): the two UTF-16 code units, which are surrogates, are
checked, instead of the code point.
This patch is not expected change the result from the function.
The single place where scriptList was used was simplified.
Change-Id: I8c94265c1faa21a26f66317eff5627681f511aaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201151
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
An omission from commit f5d97d14a2
(uitest: add a way to optionally use the same soffice process for
a testsuite, 2023-03-20).
When testing locally, on some exceptions, soffice process was left
running, and following attempts to run the test failed because of
that.
Change-Id: I3f24c7756020835182dc53565e0be7660ee9f040
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201003
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Added in commit 4baec725e0 (WIN run
main thread redirects ignoring SolarMutex, 2017-09-26), it tried to
handle SendMessage calls without releasing SolarMutex in the calling
code. The idea seemed to be, that the calling thread keeps holding
SolarMutex while waiting for the main thread, and main thread has
this mode that turns all calls to acquire/release/test solar mutex
to noop (which was safe, since the thread holding the mutex is known
to be blocked).
Unfortunately, that doesn't work. The many hangs discovered since
then (e.g., commit 1e2e51607a - Try
to use CoWaitForMultipleHandles magic to handle COM message loop,
2025-01-10) required to unlock solar mutex when calling SendMessage
(implemented in commit 23afeaedf4 -
tdf#168431: Release solar mutex when sending window message to main
thread, 2025-09-09). It made it possibe, that SolarMutex::doRelease
called from non-main thread got false from IsCurrentThread, because
the NoYieldLock mode was active, and SalYieldMutex::IsCurrentThread
only checked that current thread is main; that caused abort().
This change removes this special mode. The intention is, that every
call to SendMessage must release solar mutex, and allow main thread
to lock it. Hope this is a reasonable approach.
Change-Id: I838be4d366b24727cd93610d9cacfbe14992923e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201007
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
No idea why it passes elsewhere; the problem was, that the top focus
window changes when activating the chart.
Change-Id: Iaf96103cd6a4e91e3e06af4aea49a898ffb9251b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201000
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously changed in commits 9f428717f9
(Fix a UITest on Windows, 2024-03-11),
and 2642643ec0 (tdf#160622: Let
SalLayout::GetBoundRect return basegfx::B2DRectangle, 2024-04-19).
I re-run the test, and it changed again - and again, no idea why.
Change-Id: I1ca63fc4908f92c5d5b7f47619d6fae8fe60390b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200997
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
After commit 54b76f7ca0
(Avoid parameter introduced in Python 3.12, 2026-02-13), it failed
on Windows with
Traceback (most recent call last):
File "C:\lo\build\instdir\program\python-core-3.13.12\lib\contextlib.py", line 162, in __exit__
self.gen.throw(value)
~~~~~~~~~~~~~~^^^^^^^
File "C:\lo\core\uitest\uitest\test.py", line 220, in create_doc_in_start_center
yield component
File "C:/lo/core/sd/qa/uitest/impress_tests2/tdf170386.py", line 55, in test_tdf170386
xModel.storeAsURL(url, [])
~~~~~~~~~~~~~~~~~^^^^^^^^^
tdf170386.com.sun.star.task.ErrorCodeIOException: SfxBaseModel::impl_store <file:///C:/lo/build/tmp/tmp8d1tnp7g.odg> failed: 0x507(Error Area:Io Class:Access Code:7) at C:/lo/core/sfx2/source/doc/sfxbasemodel.cxx:3304
That was because tempfile.NamedTemporaryFile locks the created file
on Windows, unless some specific conditions are true (documented at
https://docs.python.org/3/library/tempfile.html).
Fix it by creating a custom context manager, which checks platform,
and calls tempfile.NamedTemporaryFile with delete_on_close=False on
Windows.
Change-Id: I122fabc89e469a02802c1e5237052d71cdf8bcdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200994
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
After commit 9e67072a21
(tdf#153368: Support optical size for variable fonts, part 1,
2023-03-02).
C:/lo/core/vcl/qa/cppunit/complextext.cxx(885): error C3861:
'addFont': identifier not found
If the test is expected to run on Windows, the definition of
`addFont` must be made available there.
Change-Id: I184f0dc1cc6363faba4c2ca147a812ddd4a98c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200872
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Mike Kaganski