Age | Commit message (Collapse) | Author | Files | Lines |
|
It turns out that commit 4652b911c4376048a452709c953197e1a879a921 wasn't
quite right: writing out the m_aRunText doesn't necessarily put it in
the right place, it just happened to work on that bugdoc but in other
cases the shape may be written before the paragraph properties of the
paragraph it's in...
So instead change the text frame case to save and restore the run
related buffers and members, so that the text frame itself can do
whatever it wants, and the result is appended to m_aRunText.
The members saved are a superset of those saved in
WriteHeaderFooter_Impl(), writeTextFrame(), TextFootnote_Impl().
Also another thing was missing is that OLE objects would trigger the
assert because they are also buffered into m_aRunText, e.g.
ooo46760-1.odt.
Change-Id: Icc6988f8ed19724c593760df46e0254792cd1735
Reviewed-on: https://gerrit.libreoffice.org/83105
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I4bf9002d31f7f6e2e7adcb46c7623cc8a14c82bf
|
|
The 4*4 autostyle table matrix has no box format that can handle
a table with a single column or single row. So the first
and last row/column boxes need to be combined to get all
of the necessary borders.
This could easily be seen by setting one column and X rows
using the default table style - missing right border.
It could also be seen by setting one row and X columns using
Box List yellow - missing bottom border.
Change-Id: Ib2cf873b6d4e10ba5145e680ea7b3e2e3aea3970
Reviewed-on: https://gerrit.libreoffice.org/82998
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
in table cells, ie. using paragraph styles with bottom
margin setting or direct paragraph formatting of bottom
margin. Both of them overwrite the table style based
bottom margin.
Change-Id: I527b16c24fe47df8412291089ff86fadd3f9430b
Reviewed-on: https://gerrit.libreoffice.org/82800
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ic2ffd8f0418e208d7e17ac419a0ac7d98ffad30c
Reviewed-on: https://gerrit.libreoffice.org/83118
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
|
|
This expands the test from tdf#125103 to include more use cases
and validate the import of the exported document (tdf#128460).
Change-Id: Ifb8615b6b90931996becb8cb44d846eb30956971
Reviewed-on: https://gerrit.libreoffice.org/83038
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This changes the default set in commit
4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor
to as-char by default, 2019-07-04), to have a better compromise, taking
both Word defaults compatibility and usability into account.
The problem is that users are used to just inserting an image and being
able to drag it to its final location, which is broken with as-char
anchoring.
So default to at-char anchoring, this is still something that is fully
interoperable to Word (unlike the old to-para anchoring), but allows the
easier image move again.
Change-Id: Ibc61ae167fc9e5cc31b04c83e854556309e27fd4
Reviewed-on: https://gerrit.libreoffice.org/83089
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
::RedoImpl() and SwUndoInserts::UndoImpl().
The bookmarks will be deleted again by DelContentIndex(), which also
adds them to m_pHistory, but RemoveIdxFromRange() deletes them without
adding them to m_pHistory so they won't be restored.
There is some funny commit c50f2e0a69204b8760c2e06313a18b6194f2d109
which is a mystery: if the rPam has to be saved across the
RemoveIdxFromRange() call, then either the rPam that's passed to
RemoveIdxFromRange() is wrong, or the rPam that is restored after the
call is wrong... just revert it and set the same values to rPam.
Change-Id: I9e93ef75bcd2931594aeae07e761c48752d31d9b
Reviewed-on: https://gerrit.libreoffice.org/83084
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
... in SwUndoSaveContent::DelContentIndex().
The problem is that the fieldmark survives but its dummy characters are
all deleted; this will eventually lead to unhappiness in Undo.
Another issue is that SwHistoryBookmark doesn't know about dummy
characters, so use the SwHistory*Fieldmark instead.
This still doesn't work completely because SwUndoDelete::RedoImpl() is
quite borked.
(regression from 4dc1615c80e8e66d339dc86fa95bbc76e884d988..d9030ad6298e2f49ee63489d6158ea6ad23c0111)
Change-Id: Ia98d143fa46e79348fde200be5462cc461455b58
Reviewed-on: https://gerrit.libreoffice.org/82815
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
add annotation
Change-Id: I97e9282cb8568378de01764802b0a6d30e71f259
Reviewed-on: https://gerrit.libreoffice.org/83064
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
See tdf#94879 for motivation.
Change-Id: Ia0b6909ff037c4126e0cba1e63a672d166f6784f
Reviewed-on: https://gerrit.libreoffice.org/83059
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
and drop the unused FORSPELLCHECKFLOWTO
Change-Id: I128e84d386c10d001aa63f93b4b6dcb7238a1242
Reviewed-on: https://gerrit.libreoffice.org/83060
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
On import, it was calculating the escapement before reading
the character size. If there is a fontsize SPRM in the
character run, make sure that is processed first.
Also, use the new MAX_*_ESC values since 100% is not nearly
enough as a maximum.
I looked for a mechanism that could delay processing, but
found nothing. I thought about creating such a mechanism,
but that could get extremely complicated, as loops would
need to be detected (co-dependencies, etc). In the
end, it seems likely that SOME function would need to be
re-run (for example make Read_SubSuperProp runAgain at
the end of the character properties) since there
(likely) is no guarantee of the order of SPRMs.
From my code-reading, it looks like Read_Fontsize is
re-entrant-able, so that seems like the simplest
solution in this case. This is mature code, so
no real call for creating new mechanisms...
Change-Id: I1269989c74cf34e38f8db77bd6fc510e395ee864
Reviewed-on: https://gerrit.libreoffice.org/82248
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I0f71c9b31456b37130a9b6ef9f47d204b9c21aa1
Reviewed-on: https://gerrit.libreoffice.org/83006
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... also test exported XML directly
Change-Id: I50237593dd111e7c7974452769c8d49c22012713
Reviewed-on: https://gerrit.libreoffice.org/83005
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As with previous commit 18ae77a065cb8ae6940d4067f6ab7e99a3f74047, this
will start showing parse errors on invalid files which previously just
opened without warnings, silently losing the invalid stream part. Any
bug bisected to this commit is not a regression from this commit! The
real problem was already before, and was just disclosed by this (which
is the actual goal).
Also simplify unit test data for tdf#128820, which will now be enough
after the change.
A unit test (testN779627) revealed unexpected throws when parsing; this
was fixed.
Change-Id: I5a21b9001874ec6e3b8273c10043ef930bf1cc82
Reviewed-on: https://gerrit.libreoffice.org/82981
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... that is protected; Writer can also protect the content of text
frames, which doesn't(?) appear to be possible in Word.
Form protection has annoying side effects like disabling field UI for
the whole document, even inside sections that are unprotected via
\sectunlocked1.
Change-Id: I2bf9503202779f5cb7c6e27ea7f533b2e3acb9d2
Reviewed-on: https://gerrit.libreoffice.org/82804
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I0dae9e73e85cef74f041535f3787e3afb45bb94d
Reviewed-on: https://gerrit.libreoffice.org/82989
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Without that, simple text shapes inside groups were written in
<pic:wsp> elements, with many child elements also having pic::
prefix.
Change-Id: I114cf3499e03aa5ca042211d7b134aaf5b0e7fbf
Reviewed-on: https://gerrit.libreoffice.org/82980
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I332cf55883bab679c395b9643d54e558ce0c1c64
Reviewed-on: https://gerrit.libreoffice.org/82974
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6234bc252dac5b1c29e3f1ef844cf51f56aaa7ac
Reviewed-on: https://gerrit.libreoffice.org/82970
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
the SvXMLImport superclass already constructs a parser
Change-Id: I6ff53caf4329da439b590e4b581d2ece92d8f96d
Reviewed-on: https://gerrit.libreoffice.org/82796
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the SvXMLImport superclass already constructs a parser
Change-Id: Ie99ccc4988d1daeb39e5e06ac0682f19648f3a6f
Reviewed-on: https://gerrit.libreoffice.org/82788
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from commit 61cf196631a2a846e0d3b8b83c0805cf4d1d14b2 (sw
ContinuousEndnotes: fix moving them to the previous page, 2019-10-25),
the problem was that the SwFootnoteFrame::mpReference was not updated on
frame split. This meant that by the time the frame was joined,
SwTextFrame::JoinFrame() thought that the follow has no footnotes, so
the footnote reference was not updated, resulting in a dangling pointer.
Fix the problem by going back to using bEnd for endnotes (both the Word
compat and the normal case), this means that
SwTextFrame::ConnectFootnote() will invoke
SwFootnoteBossFrame::ChangeFootnoteRef(), fixing the dangling pointer.
Then fix the original problem differently: similar to the in-section
endnotes, just remove + append them, this makes sure that the endnotes
(in the Word compat case) move to a previous page on page delete.
Change-Id: Ia1b8e54b4a0b0f385c703f8e7016011c3ac57a03
Reviewed-on: https://gerrit.libreoffice.org/82778
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
When direct formatting of a table paragraph set only top margin,
but not the bottom margin, also there was no paragraph style setting
for the bottom margin, the paragraph was imported using docDefault
bottom spacing instead of the table style bottom spacing.
Change-Id: Ib7f5f80dd2485a0fd4ab8e0645b7d730a7ec3c5c
Reviewed-on: https://gerrit.libreoffice.org/82771
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
SwWW8ImplReader::ReadChar() inserts a U+0002 control character to
temporarily mark a footnote anchor; this is then deleted and replaced
with a real footnote hint by SwWW8ImplReader::End_Footnote().
The assumption is that it is necessary to insert a placeholder
character to be able to apply formatting to it.
But if the document is corrupted, the control character could survive
the import, which sounds less than ideal.
So either make this magic character more explicit by documenting it in
hintids.hxx and removing any outstanding ones at the end of the import,
or use a non-offensive character instead; since this should only affect
invalid documents, choose the solution with the least effort.
Change-Id: I76d396258b32e0f0fb6393942a58a4dc57912211
Reviewed-on: https://gerrit.libreoffice.org/82723
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Sanitize string before calling InsertString().
This segfaults since:
commit b522fc0646915d4da94df38dd249c88b28f25be7
Date: Tue Sep 24 18:11:45 2019 +0200
sw: maintain fieldmarks in DeleteRange()/DeleteAndJoin()/ReplaceRange()
Change-Id: I9ef73d924420686f6838fa21900ec57b4d25c905
Reviewed-on: https://gerrit.libreoffice.org/81949
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a partial revert for LO 6.0's bug 55528 commit
e69473539a33da5450d3878999eba7f9bfb9e631
Apparently Word tables can float without a frame, but in LO they
need to wrapped in a frame? The relative size is supposed to be
relative to the container they are in - so floated tables must
not be assigned a relative value - otherwise the tablesize becomes
relative to the custom frame that was created to float it.
The fix was easy to make, but then trying to figure out whether
to test using InLocalApo(), or just m_xSFlyPara took a lot of time.
The documentation is sparse and unclear. In the end I settled on
ignoring relative width if pFlyFormat exists, since certain
conditions can cancel (bNoFly) a FloatingTableConversion.
I tested what happens if a real frame is created and then a
relatively sized table is dropped inside. I confirmed that relative
SHOULD be relative to the frame. That case still works fine
since it isn't considered an x_sFlyPara - I think because it actually
is a textbox that the table is anchored onto. LO round-trips
frame/table as textbox/table.
Conclusion: tables inside of frames/textboxes MAY be relative,
but if the table itself is floating (a WORD-ONLY feature)
then it should not be relatively sized.
Change-Id: I2b0bd525051a33b5606b79d2b26665d3edeb5357
Reviewed-on: https://gerrit.libreoffice.org/82647
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I95845d7217fc5e77e3f8e205030e9cd761ad0cc5
Reviewed-on: https://gerrit.libreoffice.org/82116
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idbb3e70c1a09be7dd7c43747250f3a6368251cd9
Reviewed-on: https://gerrit.libreoffice.org/82662
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
RtfAttributeOutput::OutputFlyFrame_Impl() writes SdrObject into
m_aRunText buffer, but for a text frame it writes directly
into m_rExport.Strm(), also writing m_aRunText into it in the middle.
So if you have both SdrObject and text frame at the same anchor
position, first the shape goes into the buffer and then the first part
of the text frame is written to the stream before it and the last part
after it, and we get this:
sw/source/filter/ww8/rtfattributeoutput.cxx:1886: m_aRunText is not empty
And Word refuses to open the file with a funny error message about
running out of memory.
Reportedly this is a regression from commit
d53dd70b15f0e3f7c8a05a93f8fcd70e1147c1f7 but really it was broken
already in commit a8b59ef5951fe76b0b733ecef739173c1d104f6f.
Change-Id: If01465dee71b63531b46c39dd557066f804c425d
Reviewed-on: https://gerrit.libreoffice.org/82702
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I173b3aaca84a707799f0ee78cddcbd70524897bc
Reviewed-on: https://gerrit.libreoffice.org/82561
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I294c0f2092e0274839b7294be50efc00a13231fd
Reviewed-on: https://gerrit.libreoffice.org/82465
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Regression from the commit 7fe64353dc9950e19182a59a486a1ecac27cf98e
(tdf#84806 Writer: drag and drop selected tables, don't empty).
Change-Id: I9061b80dd8fab29aa5ec74655dc6c3f7686a91ee
Reviewed-on: https://gerrit.libreoffice.org/82579
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I115e014cafb9c4a85558567ccd6cd2987cabdfd6
Reviewed-on: https://gerrit.libreoffice.org/82483
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
|
|
Change-Id: I431fa4cd0daa52c885030dbadcc4052b5a890d34
Reviewed-on: https://gerrit.libreoffice.org/82553
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Tested-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Reviewed-on: https://gerrit.libreoffice.org/82576
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Paragraphs with disabled numbering using non-existent numId=0
haven't got inherited left indentation in MSO. Keeping them resulted
unnecessary indentation, moreover, missing (non-visible) text
in narrow table cells.
Change-Id: I46003031d36f578b0b260dea74d7d45e75905261
Reviewed-on: https://gerrit.libreoffice.org/82509
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Custom visited hyperlink style reset to default in Word.
Change-Id: I6a36c900788bb17d4f31c60048cf65960490a46b
Reviewed-on: https://gerrit.libreoffice.org/80043
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
can just cast the parent member
Change-Id: I990bd4da3afbd78da819038c7907c28de87faaaf
Reviewed-on: https://gerrit.libreoffice.org/82567
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1b41fe50e93dc14db60c7548a1ae0c54113da329
Reviewed-on: https://gerrit.libreoffice.org/82542
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I3787f6e3a326c1f8e93fc966f890ea2c7cdacc29
Reviewed-on: https://gerrit.libreoffice.org/82549
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
was wrong since:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=1a5b12aa5da2c718848d3cc5d9bce7bfcdeacf54
Here's the root cause:
const bool bAlreadyInserted(
- mpListItemsList->find( &rNodeNum ) != mpListItemsList->end() );
+ mpListItemsList->insert( &rNodeNum ).second );
OSL_ENSURE( !bAlreadyInserted,
"<DocumentListItemsManager::addListItem(..)> - <SwNodeNum> instance already registered as numbered item!" );
- if ( !bAlreadyInserted )
- {
- mpListItemsList->insert( &rNodeNum );
- }
Change-Id: I0cc5786a18fe2df5fd86284c18638de90604edf9
Reviewed-on: https://gerrit.libreoffice.org/82560
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The comment that was added with commit
71f13a801608538f56a0cb2bce07a03faa5856f6 "#i29942# SwTxtNode::Update for
bookmarks fixed. Bookmarks no longer grow on either side."
suggests not to expand bookmarks in any case but in case the start and
end position was the same, the start position was still moved so the
mark expanded anyway.
Unfortunately meanwhile commit c91024891ff10c2ae01e11a28a9aecca2f36b6c3
"tdf#96479 workaround bookmark end pos handling when inserting text
into a text node." added a requirement that bookmarks with start==end
*are* expanded.
For the case where a new field is inserted, shortcut the insertion
to do only one InsertString call so that any expansion of bookmarks will
expand it over the entire field, not just its CH_TXT_ATR_FIELDSTART.
Change-Id: If2608c9cf34a217330156e7ea566dcf528890c45
Reviewed-on: https://gerrit.libreoffice.org/82521
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I8397452eae8eaf83e5f928f96f30269fc70e46b1
Reviewed-on: https://gerrit.libreoffice.org/82534
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I160fb9e5afdf10f64bcd7422e5c4198fe8bb538d
Reviewed-on: https://gerrit.libreoffice.org/82480
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I189dad65e35c7947a9479885d22d066c05c25f8a
Reviewed-on: https://gerrit.libreoffice.org/82538
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I8a7dc4324890a69dacd271e0a689018d87e13f5a
Reviewed-on: https://gerrit.libreoffice.org/82537
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I3d7d49cc225afc0dee542205690d56643a0c2e64
Reviewed-on: https://gerrit.libreoffice.org/82532
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I061868a0cf9163624026dc1ff164af3d98923aa6
Reviewed-on: https://gerrit.libreoffice.org/82531
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|