| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
noticeable since:
commit ad4b72a0eacf6bb6887236ea3a3807b1264de822
Date: Thu Mar 21 12:10:40 2024 +0100
tdf#160301 import DOCVARIABLE fields as user fields
but not really caused by it
Change-Id: I44910756df3938829589f230716363beaf0f4f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166023
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The last (5th) paragraph in the index was on page 2, even if page 1
still had space for it.
This is a regression from commit
397d72e582c725d162c7e0b819dc6c0bb62e42b0 (Related: tdf#158986 sw
floattable: fix unexpected page break with sections, 2024-02-23), in
case SwLayAction::FormatLayout() doesn't calc its lower content frames
then this bugdoc is good, but the old bugdoc moves its floating table to
the next page, which would be bad.
Fix the problem by making the condition for this "calc lower in
FormatLayout()" action more strict: only do this for content frames
which are in sections, followed by sections.
Note that probably a cleaner way would be to completely stop calculating
content frames in SwLayAction::FormatLayout() and only do that in
FormatContent(), but then it's not clear how to re-fix tdf#158986, and
at least this resolves the regression.
Change-Id: Id671b3b68d8af8ad1cca3399a9aa028de58df3a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165878
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The bugdoc has a very large header containing hidden text changes height
when toggling Formatting Marks. When toggling on, it crashes, because
UnHide() iterates the text frames in all headers, but after the first
one empty pages at the end of the document are removed, so UAF.
Remove the pages without content earlier; SwLayAction::InternalAction()
already does it after the "normal" page loop, but the 2nd page loop
following that may also move content off pages, so do it again.
Change-Id: Iaae6a16842b3494f25cba8fc036d15049b71961f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165801
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Which means we get boxes (cells) grouped by lines (rows), instead of a
flat list of all cells in a table.
Change-Id: Ibb14c6fb26b2f4b502b18544d9a08d964c45a97e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165806
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
DOCVARIBLE fields in *.doc files are imported as user fields.
Change-Id: Ib723d8a586ca644e0b158f839caef33b2b6225a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165096
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
The command NewGlobalDoc is not supported by Calc, Impress and Draw, so they should not exist in the Tabbed UI. Otherwise, a gap appears, since there's no info about this command.
Change-Id: I0dd2b4639cfb44437d6726d6f138c4767c5a3175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165351
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
to reproduce the underlying problem: data, calc, recalculate hard:
which asserts that cell I367 is dirty during parallel calc
checking the dependencies for a parallel calc is supposed to find what
cells it depends on and either: ensure they are not dirty or detect its
not possible to do the parallel calc
checking starts in J9 where::
J9: =SUM(H$8:H9)-SUM(I9:I$9)
J10 =SUM(H$8:H10)-SUM(I10:I$9)
for the first sum it detects that the input range is H9:H367 and checks
that for dirty results, but for the second sum it detects a range of
just I9 and the dirty I367 is not detected and the problem arises on
calculation
The code to detect the range is:
// The first row that will be referenced through the doubleref.
SCROW nFirstRefRow = bIsRef1RowRel ? aAbs.aStart.Row() + mnStartOffset : aAbs.aStart.Row();
// The last row that will be referenced through the doubleref.
SCROW nLastRefRow = bIsRef2RowRel ? aAbs.aEnd.Row() + mnEndOffset : aAbs.aEnd.Row();
where for the I9 case has nFirstRefRow true and nLastRefRow false so we
just get a range of I9:I9 instead of I9:I367.
Trying to create a doc from scratch to reproduce this case proves
tricky, so trim down the original document to the sheet and subset
of columns that can trigger it.
Change-Id: I44bfd1f6d3a3ee13db9024c5b2efa2588cc30521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165510
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Open the document, press tab to switch to a field, start typing, nothing
shows up.
Looking at the doc model dump, it turns out we inserted characters
between the field start and the field separator dummy characters,
instead of the field separator and the field end ones, which is quite
bad.
Turns out that in the meantime commit
c80606bb23fd42e41710d70a96b7ffaf948384a6 (tdf#109272: make sure that
Delete / Backspace move cursor correctly, 2024-01-18) fixed this, kind
of by accident: the comment says the motivation there was change
tracking.
Add a testcase to to make sure this now continues to work.
Change-Id: I1a300d8064f7c2a30aafeefc6cb5612bfcd9a06a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165368
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Bug exposed with 6.1 5259ab8104cfba60c40748ed0cd59d93df038c5b
sfx2 store: create temp files next to local files
tested on .doc format, code-read suggests it affects xls/ppt too,
but they throw exceptions, apparently before hitting this section.
I was seeing an infinite loop on SfxOleSection::SaveProperty's
while((rStrm.Tell() & 3))
rStrm.WriteUChar( 0 );
because nothing checks to confirm that the tempfile
is actually created/useable.
Now, instead of an infinite loop, we get a crash...
Change-Id: I9e093432361a8ad6f928ec9b47290274b3d4ef06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164840
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
The purpose of the doc model dump is to give an idea of the doc model as
it's in the memory. SwNode::GetTableBox() is far from trivial and can be
problematic when invoked from e.g. an already crashed process.
Rather show SwTable::m_TabSortContentBoxes, which knows the (cell) start
node, and then this can be avoided in SwStartNode::dumpAsXml().
Change-Id: Ie81181cfd41de4d4df38a8b7a430ecd5f67bc8a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164560
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
No interesting existing unit tests.
make CppunitTest_sw_ww8export4 \
CPPUNIT_TEST_NAME=testTdf160049_anchorMargin
Change-Id: Ib855d9f35db9e0f47aff18400b69a990cd1ad5ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164444
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I'm really surprised this wasn't found much earlier.
Even DOC format isn't handling this.
compat15 gets rid of this inconsistency.
Surprisingly, there were no interesting unit tests matching this.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf160049_anchorMarginVML
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf160049_anchorMargin15
Change-Id: Ic5c316569ad3640ba0e786d39a6e5c006c74d665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164443
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I'm really surprised this wasn't found much earlier.
Even DOC format isn't handling this.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf160049_anchorMarginVML
Change-Id: I92ee8eceb6c6bab5f027663bae94d7acdf01be3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164442
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from commit 6d8da2b2deb4be2182ca1852cec7eb38a4c654eb
(tdf#96943 sw Hide Whitespace: don't create pages for widow / orphan
..., 2016-01-07), the reduced bugdoc has 3 paragraphs, 1.5 paragraphs
are on page 1, 1.5 paragraphs are on page 2. Hiding whitespace moves the
entire paragraph 2 to page 1, which is unexpected.
Checking the original use-case, the
CheckPageHeightValidForHideWhitespace() call in
SwTextFrameBreak::IsInside() can be removed, and still the original
"type character at the end of the document results in a new, unwanted
page" problem is not back. Likely at some point in the meantime we gave
up on these reduced page heights for the last page, so the original
tweak for widow/orphan lines is not needed anymore.
Fix the problem reverting the original, no longer needed fix, but
keeping its testTdf96943 test in the CppunitTest_sw_uiwriter4 suite.
Such reducing of last page doesn't happen with Word 2021, so probably
this change in behavior is wanted.
Change-Id: I5d46d0cd84d0071ffb9ef3f8e4ca7335e61bb226
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164408
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
If the body-anchored thing is in the background,
then if any header stuff was NOT in the background,
then it would show up above the body thing,
and that should not happen in a DOCX world.
This test was not easy to produce.
ODT kind of knows that headers are special,
and so it tries really hard to put stuff in the background
without any wrap - at least after a round-trip.
So I had to hand-craft from my example DOCX
that exhibited a behindDoc which actually
had some wrapping component to it.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_headerBehind2
Change-Id: I31617cd7bf2d38add2233a7a06ffe9a8ec00ec0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164130
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Regression from commit ce2fc5eb29b4e252993b549dee002fa8948c8386
(tdf#158341 sw floattable: fix layout loop when fly is below the body
frame, 2023-11-29), open the bugdoc, add an empty paragraph at the
start, Writer layout crashes. The immediate problem is that
SwTabFrame::MakeAll() assumes that in case HasFollowFlowLine() is true,
then GetFollow()->GetFirstNonHeadlineRow() is always non-nullptr,
similar to the situation in commit
223d2fac61e061478721a7a4a89b1362f5037d8f (sw floattable: fix crash by
trying harder to split tables, 2023-11-22).
The deeper problem is that the bugdoc has a repeated table header row,
the fly frame temporarily gets shifted down, so nominally the header
doesn't fit anymore, and this leads to a modification of the doc model,
which creates inconsistency: the model now says we have no header rows
but the layout still contains table row frames where the header bit is
true. This is problematic in theory, but in practice caused no problem
so far.
Fix the problem by disabling this mechanism for floating tables: trying
to have a table header that doesn't fit the table is asking for trouble
anyway, and this way at least we have a layout that is consistent with
the model, which also avoids the crash, now that nobody violates the
"HasFollowFlowLine -> follow's FirstNonHeadlineRow != nullptr"
invariant.
Also extend the layout dump, so it's easier to see when the master's
flag and the follow's row list gets out of sync.
Change-Id: I52b51f6d86ab4e0bab560f892e9cceb183aecd5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164136
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The bugdoc's 2nd para started with 'Sect I.01', while Word rendered this
as 'Sect 1.01'.
The reason for this difference is that there is an "is legal" boolean
property on the numbering that we ignored from [MS-DOC] during
import/export.
Fix the problem by WW8ListManager::ReadLVL() and
WW8AttributeOutput::NumberingLevel() to handle this, building on top of
the existing DOCX work.
RTF still needs doing.
Change-Id: I57ec402c1dd829251afa639ddfa7fc6620da1125
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164000
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Extract a new helper method `BuilderBase::isToolbarItemClass`
to identify whether a widget class is one of those used for
toolbar items.
Related: Gtk's GtkToolItem doc [1].
(But this commit just moves the existing logic without
looking into that Gtk doc further.)
[1] https://docs.gtk.org/gtk3/class.ToolItem.html
Change-Id: I1e39e4afb13db374ae77a3cdb6a4dd9eca7ee3ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163957
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This affects patterns as well as textures/images.
make CppunitTest_sw_ww8export3 CPPUNIT_TEST_NAME=testTdf101826_xattrTextBoxFill
Change-Id: I2742a6f333fc6688b3570772a1dbc8371741f210
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163948
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
The bugdoc had a floating table, immediately followed by a section
break. The floating table went to the second page, should be on the
first page.
The trouble is that RTF's section break is just a special symbol, so we
can have a section break right after a floating table. This is in
constrast with DOCX where a non-last section break is a paragraph
property, so it's guaranteed to have at least a paragraph start after a
floating table and before a section break, which can nicely serve as an
anchor point for the floating table.
Fix the problem similar to what the OOXML tokenizer did in a similar
case in commit 01ad8ec4bb5425446e95dbada81de435646824b4 (sw floattable:
fix lost tables around a floating table from DOCX, 2023-06-05), by
injecting a paragraph before the section break.
Handling this at a tokenizer level seems to be the right place, since
the DOCX version of the same document was already imported OK.
Change-Id: Ic945c472c08ba872a5c46e2b8f75e919678aa0a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163929
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit c303981cfd95ce1c3881366023d5495ae2edce97
(tdf#156724 sw: layout: fix tables not splitting due to footnotes
differently, 2023-08-24), the floating table in the DOCX version of the
bugdoc went from page 1 to page 2.
It seems what happens is that the first page has 2 section frames, and
we used to directly recalc the last lower of the first section frame,
which triggered a recalc of the second section frame, so the table moved
from page 2 to page 1 once the top of the second section frame was
reduced (so the table could fit on page 1). But this direct recalc was
removed because it caused problems for split tables and footnotes in
tdf#156724.
Fix the problem by conditionally restoring the OptCalc() call in
SwLayAction::FormatLayout(): only do it for the last lower of section
frames, which is enough for the DOCX version of tdf#158986, but it keeps
the old tdf#156724 use-case working (the layout of that bugdoc doesn't
modify with this change).
The RTF version of the bugdoc (which was the originally reported
problem) still needs more work, but that's hopefully not a layout
problem but an RTF import one.
Change-Id: I1134ec3a27aec8ee871b535d81dedf9d27bd6bd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163805
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Ideally each class should just dump itself.
Change-Id: I8b7251553d12673258ae885436c56e342b3ddf8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163801
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The 2nd para of the bugdoc has a leading word, then a redlined anchored
shape, finally a redlined checkbox content control. The Writer import
result's content control starts at para start, while it should only
start after the anchored shape.
What happens is that writerfilter::dmapper::DomainMapper_Impl::PushSdt()
gets called to remember the SDT start, then
DomainMapper_Impl::applyToggleAttributes() deletes some content since
commit 8726cf692299ea262a7455adcf6ec25451c7869d (tdf#142700 DOCX: fix
lost track changes of images, 2021-07-08), which invalidates the SDT
start position, finally PopSdt gets called, but that fails because our
start position is no longer valid. This used to abort the import
process. Since commit 1b0f67018fa1d514ebca59e081efdd24c1d7811b (docx
import: correct redline content-controls, 2024-02-20), the import
finishes the but start of the SDT is incorrect: it's at the para start,
while it should start in the middle of the paragraph. The direct reason
for the invalidation is a call to SwXTextRange::Impl::Notify(), which is
from a content deletion from applyToggleAttributes().
Fix the problem by not deleting content when we're past PushSdt() and we
haven't called PopSdt(): extract the redlined anchored shape code into a
new DomainMapper_Impl::MergeAtContentImageRedlineWithNext() and call
that also in DomainMapper_Impl::PushSdt() early, so it won't be called
when we're in the middle of an SDT.
This way createTextCursorByRange() should not fail, so warn in case it
still fails in DomainMapper_Impl::PopSdt().
Change-Id: Ic4198804a92088ec268203d44c0da2d6997754b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163678
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from 868140fcc1311259b9d5f666637b33d226511a53 (tdf#60558 sw
floattable: allow wrap of table on the right of a floattable,
2023-12-05), the bugdoc layout looped on load.
Somehow the big while() loop in SwTabFrame::MakeAll() never finishes: it
always tries again but can't reach a state where all of frame area
position, frame area size and frame print area is valid.
Fix the problem by going back to the old behavior (floating table is
wrapped by text frames, not by table frames) for the nested table case:
that keeps the old tdf#60558 use-case working and fixes the new
tdf#159285 use-case.
At some point it would be useful to support the combination of nested
floating tables and the "floating table wrapped by table" combination,
but that will be a new layout feature.
Change-Id: Ia3fdbd08de87e13ddef086ae1339e79a8833674d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163630
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Ideal would be to show the entire table box, we used to show
pBox->GetFrameFormat()->GetAttrSet(). Improve this to at least show
pBox->GetFrameFormat(), which exposes the name of the table box format,
which should help debugging.
Change-Id: Ifd024e6c0720ab20d0f89b50f0d1472cd5762a40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163473
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
open a calc doc in light mode (view 1) and again in another view (view
2) and toggle the second view to dark mode.
Now edit a cell in the dark mode view and in the light move view the
edited cell background is drawn as dark.
bisected this to:
commit f0adebce7a64b6c7dd57e10811cbe45767c6a540
Date: Wed Dec 13 17:50:44 2023 +0100
lok: calc: fix for rendering issues on in place editing
Change-Id: I5bdd0c1afaf5fa942c1b1f8bc1009b9057656840
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163401
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Regression from commit e2076cf7a92694bc94bdc9f3173c2bddbe881a89
(tdf#155682 sw floattable: fix DOCX with big pictures causes endless
loop, 2023-10-25), the bugdoc's body text was wrapping around the
floating table from the header, while the expectation was that the top
of the body frame is below the bottom of the header frame.
It seems IsFollowingTextFlow is only needed when the relation of the
floating table is not "page", and this bugdoc has has an examplicit
vertical relation of page.
Solve the problem by limiting the IsFollowingTextFlow=true request for
the floating table to the VertOrientRelation=page case, which fixes the
bugdoc and keeps the old use-case working.
The doc model for the new bugdoc now matches the WW8 import result.
Change-Id: Ia3da65cd52d70b357e448a26a50ffb92a39795e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163290
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The field type doesn't own its format fields, is just aware of them. So
just show the pointer there, the matching text attribuet will do a full
dump, as it's the owner.
This fixes dumping e.g. post-it fields twice for no reason.
Change-Id: I3ff40da059d25eddc87a2ce329c29af5f01d049c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163153
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Copy a cell with boolean TRUE and FALSE from google docs to Calc, the
paste result is a TRUE and a FALSE string.
The problem is that boolean is meant to be a float 0 or 1 with custom
cell format, but we don't build this doc model.
Fix the problem by ParseDataSheetsValue() to write the properties of the
cell similar to what the normal HTML import would extract from our own
markup, like:
<td height="17" align="right" sdval="1" sdnum="1033;0;BOOLEAN">TRUE</td>
This requires passing around both the value and the numbering
properties, since the cell format just decides it's a boolean, but the
cell value will decide if it's TRUE or FALSE.
Change-Id: Id558ced56e02bbe24330d82c3998b047dc8febdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163108
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
regression from
commit 8ce36e943f0e50970925b2dd77729ef6036b4a49
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sun May 26 15:15:41 2019 +0200
move some searching inside IDocumentMarkAccess
where I called the wrong method from inside Writer::FindPos_Bkmk
The code was then removed in
commit 7bad1516c5f2a85b5bae3f49261ac2494cbb7162
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jul 17 05:41:08 2019 +0200
loplugin:unusedmethods
Change-Id: I3f1e14a1e3ae2dd134738363e6b2679d2a2f418a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163095
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The bugdoc had no header in Word, but had one in Writer, since commit
17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header
should always set default headers as well, 2014-11-21).
The code has changed a log in the meantime, today we import first page
headers and left/right page headers as a single page style, but still
code was missing to detect the case when <w:headerReference
w:type="first"> was not followed by <w:titlePg>, which is an indicator
that the first page header/footer should be used.
Fix the problem by new flags to SectionPropertyMap to track if we ever
seen a first/left/right header. This allows making an informed decision
in SectionPropertyMap::setHeaderFooterProperties(): if the header is on,
but we effectively don't have none of a first, left or right header,
then it's time to turn it off, similar to what the DOC import does.
Note that this only changes behavior for headers, but if there is a
practical need, then the same could be also done for footers as well.
Instead of adding a new test, notice that testTdf112694 in
CppunitTest_sw_core_header_footer explicitly tests this case: a first
header which is not a title page. So change that testcase to assert the
behavior now matches Word and drop the FIXME.
Change-Id: Ib604e786d7a5a197d4b562533326206697de882a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162992
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
And fix a creative XML attribute name. 'm_aAttr.getItem()' is not really
well-formed, try 'attr-item' instead.
Change-Id: I108cba8c6cff8d19c388710bbf693e3e8214f3f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162926
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The problem in the bugdoc was the directory entries. These entries
are valid in ZIP packages (even if not common); they may be useful
to e.g. define per-directory permissions (ACLs).
In normal mode, ZipFile reads central directory; there we can read
if the entry has FAT file attributes; and then, if the entry is a
directory. Then it is OK to skip it.
In repair mode, central directory is not used, local file headers
don't contain a "directory" flag. A workaround is used, checking
if there are entries that represent directories of other entries.
Also this change fixes some places that didn't pass the recovery
flag correctly.
Change-Id: I324671841a2c4d0f279b03801d95c8f2eeb99b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162888
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The A2 cell in the bugdoc has 01 in it, which was auto-converted to 1
(float) value on import, even if it was text originally.
This is hard to solve for HTML in general, which is not typed, but this
input is coming from google sheets, which has an additional
data-sheets-value attribute on <td> that does tell us about the type of
the cell.
Fix the problem by handling that attribute, and in case it explicitly
says it's text, then apply the matching number format.
Other types are not yet handled.
Change-Id: I2986ef864e97d9c46d191aba25ca5740a1151a71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162869
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I4977fc6ef2c6da356051ac5573ed088707d3b311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162834
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This fixes the test testTdf158586_0 and testTdf158586_0B to look like in
Word; the case appears a bit esoteric, hopefully Word won't actually
create such documents? But Word will round-trip such bugdoc to a DOCX
where the first w:p contains all of w:framePr and w:sectPr and w:br...
Change-Id: I6ec09478a774e1e9c785e9482618c1afc388df0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162778
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Writer doesn't really support tables in footnotes, see the warning at
the top of SwFlowFrame::MoveFwd(). Still, there is some initial support
for them, since commit 11c51eefe8c3210cef2b5850f401ba67a401d01
(tdf#95806 tdf#125877 tdf#141172 DOCX: fix tables in footnotes,
2021-03-28). Similarly, redlines really just track insertion and
deletion, but some initial support for table operations were added in
commit eebe4747d2d13545004937bb0267ccfc8ab9d63f (tdf#144270 sw: manage
tracked table (row) deletion/insertion, 2022-01-12).
The combination of these is a bit fragile, but the bugdoc happened to be
imported as an inline table (in a footnote, with recording changes)
before commit d477fa8ac1b0d3ee81427217bbb5950278ab16db (sw floattable:
unconditionally map <w:tblpPr> to SwFormatFlySplit, 2023-03-17).
Fix the problem by explicitly importing floating tables as inline in the
footnote + redline case to restore the working use-case.
DOCX import of this combination can be enabled again once Writer layout
works for the produced model.
Change-Id: I9cd0a1fabb9807f5117cb5a36ec8597d6646eece
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162733
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
`AccessibleEventId::SELECTION_CHANGED_ADD` and
`AccessibleEventId::SELECTION_CHANGED_REMOVE` events
need to be sent for the selection container whose
selection changed, not the child that was (un)selected.
The latter should be set as the `NewValue` of the event,
see the doc in
offapi/com/sun/star/accessibility/AccessibleEventId.idl .
Therefore, adjust the handling for (un)selected shapes
in Writer: Set the doc view's a11y object as the source,
just as it is already done for the
`AccessibleEventId::SELECTION_CHANGED_WITHIN` case,
and set the (un)selected shape as the `NewValue`.
With a Writer doc having two shapes and the first
one selected, clicking on the other one to switch
selection to that one would previously result in
this warning when using the qt6 VCL plugin with
Orca running:
warn:vcl.qt:114611:114611:vcl/qt6/../qt5/QtAccessibleEventListener.cxx:363: Selection add/remove event without the (un)selected accessible set
warn:vcl.qt:114611:114611:vcl/qt6/../qt5/QtAccessibleEventListener.cxx:363: Selection add/remove event without the (un)selected accessible set
Using gtk3 and this pyatspi script:
#!/usr/bin/python3
import pyatspi
def listener(e):
try:
if e.host_application.name != 'soffice':
return
except:
return
print(e)
pyatspi.Registry.registerEventListener(listener, 'object:state-changed:selected')
pyatspi.Registry.registerEventListener(listener, 'object:selection-changed')
pyatspi.Registry.start()
would previously give this output for that case:
object:state-changed:selected(0, 0, 0)
source: [panel | Shape 1]
host_application: [application | soffice]
sender: [application | soffice]
object:selection-changed(0, 0, 0)
source: [panel | Shape 1]
host_application: [application | soffice]
sender: [application | soffice]
object:state-changed:selected(1, 0, 0)
source: [panel | Shape 2]
host_application: [application | soffice]
sender: [application | soffice]
object:selection-changed(0, 0, 0)
source: [panel | Shape 2]
host_application: [application | soffice]
sender: [application | soffice]
(i.e. both, the "state-changed:selected" as well as the "selection-changed"
AT-SPI events were previously sent for the shapes.)
With this change in place, this gives the expected output:
object:state-changed:selected(0, 0, 0)
source: [panel | Shape 1]
host_application: [application | soffice]
sender: [application | soffice]
object:selection-changed(0, 0, 0)
source: [document text | Untitled 1 - LibreOfficeDev Document]
host_application: [application | soffice]
sender: [application | soffice]
object:state-changed:selected(1, 0, 0)
source: [panel | Shape 2]
host_application: [application | soffice]
sender: [application | soffice]
object:selection-changed(0, 0, 0)
source: [document text | Untitled 1 - LibreOfficeDev Document]
host_application: [application | soffice]
sender: [application | soffice]
Change-Id: Id2017f70a8e53043b4c303f69464ddd39f280097
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162519
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
If shape selecion changed, just send the same
`AccessibleEventId::SELECTION_CHANGED_ADD` event(s)
regardless of whether only a single or multiple shapes
are selected.
This unifies the handling and also prepares for sending the
event with the correct source and `NewValue` set.
The `AccessibleEventId::SELECTION_CHANGED` doc doesn't
expclicitly mention whether the source should be the
selection container (i.e. the parent, which is the doc view
in the case here) or the selected object, and this is
currently handled inconsistently across the codebase.
I tend to think that this event should have the
container as the source (just as for the
`AccessibleEventId::SELECTION_CHANGED_ADD` case,
that will be fixed in an upcoming commit), and this
is at least what the handling e.g. in the gtk3 a11y
bridge assumes (s. `AtkListener::notifyEvent`), but
there seems to be no added value in handling the
case of a single selected shape specially here in the
first place.
This may have been inspired by the MSAA/IAccessible
equivalent, `EVENT_OBJECT_SELECTION` [1]:
> The selection within a container object has changed. (...) This event
> signals a single selection: either a child is selected in a container
> that previously did not contain any selected children, or the selection
> has changed from one child to another.
But then, the selection taking place here might also be from
multiple objects being selected to just a single one, and
`SELECTION_CHANGED_REMOVE` is sent for any previously selected
but now unselected shape anyway, so using
`AccessibleEventId::SELECTION_CHANGED_ADD` seems more
consistent to me anyway.
[1] https://learn.microsoft.com/en-us/windows/win32/winauto/event-constants
Change-Id: I1525ed27434bbbb4cf181df2148669c7bc6850b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162518
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
As described in
commit 69e708868f6046cada955a16bca966370ce3218a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Feb 20 08:14:36 2020 +0100
tdf#130794 qt5: Actually, ignore non-spontaneous QEvent::ShortcutOverride
and the previous
commit 034f56015c1c7a61faede33fb5306f63b5585632
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Feb 17 10:38:15 2020 +0100
tdf#126785 qt5: Ignore external QEvent::ShortcutOverride
it refers to, duplicate events of type
`QEvent::ShortcutOverride` are received when a11y is
active, so those commits introduced ignoring of the
non-spontaneous one, and leaving processing for the
spontaneous event only, thus preventing duplication of
typed text.
However, keyboard shortcuts like Ctrl+V were still
processed twice: While they're only processed once
in `QtWidget::handleEvent` (for the spontaneous
event of type `QEvent::ShortcutOverride`), the keyboard
shortcut was additionally handled as the shortcut to
activate the action that's used for the menu entries,
e.g. the "Edit" -> "Paste" menu entry for Ctrl+V
(s. class `QtMenu`, where those are set).
Accept the non-spontaneous `QEvent::ShortcutOverride`
event to prevent that from happening.
Quoting the `QEvent::ShortcutOverride` doc [1]:
> Key press in child, for overriding shortcut key handling (QKeyEvent).
> When a shortcut is about to trigger, ShortcutOverride is sent to the
> active window. This allows clients (e.g. widgets) to signal that they
> will handle the shortcut themselves, by accepting the event. If the
> shortcut override is accepted, the event is delivered as a normal key
> press to the focus widget. Otherwise, it triggers the shortcut action,
> if one exists.
With this commit in place, the shortcut is only
processed once, as expected.
Potentially, this should ideally be addressed on Qt
side in the future, see the discussion in tdf#126785.
The duplication happens since this qtbase commit
(no longer with a local revert of it): [2]
commit 7c532891e0be2cf78c89738e175b3d312d305e4e
Date: Tue Apr 17 16:45:09 2018 +0200
Send ShortcutOverride event when receiving a non-spontaneous key press
Since 2020, there a pending Qt change by Alexander Volkov
suggesting to avoid the duplicate events by filtering them
out in `QSpiApplicationAdaptor::eventFilter` on qtbase
side: [3]
With that change not being merged yet, fix this on LO side
for now.
[1] https://doc.qt.io/qt-6/qevent.html#Type-enum
[2] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7c532891e0be2cf78c89738e175b3d312d305e4e
[3] https://codereview.qt-project.org/c/qt/qtbase/+/295892
Change-Id: I28cb11914ae81284e050bff0deb39d95e8073ce0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162430
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
No matter what z-index I chose, it always ends up being above
a relativeHeight. Since a heaven z-index is 0+,
that means that all relativeHeight's need to be treated as negative.
IsInHeaderFooter is a complication, because these are ALWAYS treated
as if they are below the text, and yet behindDoc relativeHeights
still need to be below their counterparts.
While this algorithm could never cover all the situations
(it would require transitioning to a sal_Int64 to do that)
it should be fine for practical purposes.
Plus, there are some unknown complications surrounding this.
If I increase the behindDoc relativeHeight by 1 in
tdf159158_zOrder_behindDocB.docx
the yellow star actually moves on top of the blue star,
which totally debunks my theory.
RTF doesn't really use relativeHeight,
but if it did, these changes should apply anyway.
Change-Id: I62e1f9ae8fe6f99534a2a799692120508204c553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This fixes documents where both a z-index and a relativeHeight are in
the hell-layer. z-indexes indicate behindDoc with a negative number,
so prior to this patch relativeHeights were always above z-indexes,
but in fact the reverse ought to be true.
The reason why this works so well is because relativeHeight
can be at maximum 1DFF FFFF, and we are subtracting 7FFF FFFF
which makes it a very low number that z-index is very
unlikely to ever reach.
I don't see any reason at all why this logic would be limited
to headers and footers. I assume that was done just to limit
the potential regression hate, but in that case a comment
should have been made stating that.
documentation: previous patchsets contain a list of unit tests
that have behindDoc without being in the HeaderFooter.
None were interesting...
The unit tests I modified were generally not surprising,
since I am changing the zOrder and getShapes() is based on zOrder,
so either refer to the shape by name when the order is not important
(and might change depending on ODT import, no z-index defined etc),
or else change the number to match the moved-to location
if it changed because of initial import.
The interesting one was the compat15 document which is
specified as behindDoc but that is supposed to be ignored...
perhaps if() could have just used m_bOpaque, but that is a logic
step a bit too far to take.
This can (and should) affect RTF as well, since
{\sn fBehindDocument}{\sv 1}
is documented as a shape consideration in the RTF spec.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_behindDocA
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_behindDocB
Change-Id: Ic9eaecee28fd412f9aecce61b1e3a607f26d424a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162030
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
relativeHeight treats its content as unSigned values,
but it needs to share the zOrder with z-index
which is a signed value (negatives indicating the belowDoc position).
Thus, it is logical that relativeHeight would have a maximum
value, and based on trial and error it was determined
to be 1DFF FFFF for DOCX.
Change-Id: If3fc16061730fb034c187ce4f639e1b2e50e044f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162233
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
in multiple views, while the invalidations rectangles should be reported
at the same place from each view.
on load, ScTabView::SetZoom gets called with the zoom stored in the
document settings, which both calls sets Zoom on the ViewData, and then
calls ZoomChanged, which syncs the GridWindows MapMode from the ViewData
derived GetDrawMapMode().
Later lok sets zoom via setClientArea which leaves the GridWindows
MapMode untouched and out of sync with the newly changed ViewData
MapMode.
Typically then, on e.g. on deleting text in one view then
ScViewFunc::DeleteContents or similar is called which calls
ScTabView::UpdateCopySourceOverlay which calls
ScGridWindow::UpdateCopySourceOverlay and that sets the GridWindow
MapMode to the DrawMapMode but then *for lokit* returns early (among a
few other unlikely early return cases) while every other similar func
restores the orig GridWindow mode before returning. So the view which
is used to make the change ends up with GridWindows synced to the
ViewData MapMode, which looks like accident. While the other view
remains with GridWindows with MapModes unsynced with that views
ViewData MapMode.
So on invalidate, the view that was used to make the change has
GridWindows with MapModes that report the correct rectangle, while the
other unsynced view will report an incorrect rectangle, until something
happens in that view to get it to exec UpdateCopySourceOverlay and get
synced.
Here add the sync to ScModelObj::setClientZoom so the two MapModes
remain synced once that is called.
Change-Id: I2da59f50ae2b0e3ea6b7ef8b54debdab1ee98266
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162312
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162322
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Bugdoc has autoTitleDeleted set to false (so title should be visible), but then an empty title is given.
In this case no default string should be added to the title, only in case of Pie Charts.
Any other Chart types show the default title in MS-Office.
Co-authored-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Change-Id: Ib445099a4a3d113cff6b1ffdfd093fe41c34716b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155681
Tested-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
The bugdoc contains a table with most rows having a hidden-paragraph
field in every paragraph, and no cell border or padding.
The SwTabFrame is initially split across 6 pages, which should all be
joined, as there are only 3 visible rows, but the last follow is never
joined.
This is because SwTabFrame::Join() of the next-to-last follow doesn't
invalidate the SwTabFrame, because Grow(0) doesn't invalidate, and
later formatting anything in the moved SwRowFrame doesn't invalidate
either as it is all height 0.
Try to fix this by guessing that the row will have height 0 (even if
it's not formatted yet).
Change-Id: Ic8246ac91c741f5a215f89dc159c44d7c7cf2ce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162203
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
The problem is that the code tries to check for a table on a clip-
board doc, but doesn't find any so it propagates nullptr back to
the caller, which is then used without being checked thereby
leading to a crash. The fix is to check the result of the table
check of clipboard doc before doing any operations with it, thus
preventing the crash.
Change-Id: Ieb4a52d0c1cb713d5c14930e5e559e5bf520b330
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162033
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The problem is that when a user cancels the password dialog
during recovery, the code tries to do something with the
doc, but there is no doc yet because the file is password
protected and not opened, so it crashes. The fix is just
to check for the absence of errors before using the doc
(canceling the password dialog is considered an abort/
general IO error).
Change-Id: Ia76d8e4ff8212427d6b7b0a67ce1971b9ea8a48d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161844
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The problem was that the bugdoc had an empty paragraph with superscript
(as char format) enabled and that was simply lost in the layout. Adding
text to the paragraph or removing the superscript formatting worked
around the problem.
What happened is that SwSubFont::GetHeight() has a somewhat surprising
explicit check for escapement, and there the CalcEscHeight() call might
be invoked on an SwSubFont whose m_nOrgHeight is 0, while the intent is
to just return the original height in case of automatic subscript or
superscript.
Fix the problem by checking the result of GetDefaultAscentAndHeight() in
SwLineLayout::CalcLine(), and in case it would simply turn the line into
an invisible one for an empty line with sub/subscript then go back to
the already correctly calculated line height.
This needed adjusting a test in CppunitTest_sw_ooxmlexport12 because the
bugdoc there had such a paragraph, effectively testing if we lose
content during layout, which is not wanted.
Change-Id: I1e836531851ea5c9a983ae69da5be8a042cc6e39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161588
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
When we move the paragraphs, we can just take the unique_ptr of
ContetNodes out of the EditDoc and move it to new position inside
EditDoc, like it is done for ParaPortions in ParaPortionList.
No need to muck with the raw pointers and releasing the ContentNode
from a unique_ptr and later moving it back again.
Also just use a std::vector for ParaPortions instead of a new
instance of ParaPortionList.
Change-Id: I8634ccc83121c1ee683be4c2cfb0cedbd469c05d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161531
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
