Age | Commit message (Collapse) | Author |
|
Change-Id: Ie3877811e482c1ec395a00ec6bf67155220b2b64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156675
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156729
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Crashreport signature:
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::handleIndex(tools::SvRef<writerfilter::dmapper::FieldContext> const&, rtl::OUString const&)
writerfilter/source/dmapper/DomainMapper_Impl.cxx:6116
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand()
include/rtl/ustring.hxx:527
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper::lcl_text(unsigned char const*, unsigned long)
writerfilter/source/dmapper/DomainMapper.cxx:3735
program/libwriterfilterlo.so
writerfilter::rtftok::RTFDocumentImpl::singleChar(unsigned char, bool)
writerfilter/source/rtftok/rtfdocumentimpl.hxx:718
Change-Id: I4e0f93ce50c8c9a1f9a1a0f9204bd4fee70cdde4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151350
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
TOC creation entered a malformed state where it interfered with
the creation of other elements (e.g. annotations and textboxes).
This change is also a fix to tdf#154481, so the patch from
94de79e7d3c98 can be removed.
Change-Id: I423f9d048b8c5b89fd38229c4f3ad41213d5ab67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151103
Tested-by: Jenkins
Reviewed-by: Ashod Nakashian <ash@collabora.com>
(cherry picked from commit 5431b756d45bebe74beaba2026704552ee6891f0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151282
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit b5034017e566cd4e5a236bf59555196598fd01cf.
It was added for T38690 and removed for T41585
Change-Id: Icca77965ddeece69c01129aebb7b4af3092cd85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150294
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
... in group shapes"
This reverts commit c4f3aa127ad33fe691b00336cdc9d6c88a9ebfb9.
It was added for T38690 and removed for T41585
Change-Id: I55631e3e2b0035bb133363761d30f2724f6c4741
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150288
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit 05eaee071ba6eb93ccc4da31b11ee01d102a960c.
It was added for T38690 and removed for T41585
Change-Id: Ia50f6bff6e7f15dd7d5f28795fdfe9df7ad048ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150287
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
(Likely broken) DOCX documents exported by Writer raised a SAX
exception, when PopFootOrEndnote() tried to access to a
not-existent footnote, because PushFootOrEndnote() failed to
create that.
Note: the original ODT contains hundreds of frames, and
these and the text content of the document have been put
into the TOC section during Writer's DOCX export, resulting a
broken document.
Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357
"tdf#76260 DOCX import: fix slow footnote import".
Change-Id: I9e32feb0cae778a87f034a8b5c41989fec90899d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134934
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 73696a01224a3758bde686f32ec7e6f4c90877fe)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149727
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
The problem was that the top margin was being applied
to the new paragraph after the split.
This is absolutely attrocious in MS Word before 2013.
If I am going to be in error, I want to error on the side
of being compliant with compat15, since all other versions
of MS Word are now unsupported.
I think I have the logic of it mostly figured out.
In compat15, the top margin never applies after the break.
In compat14, if the paragraph properties are not applied
to a run before the break, then they can be applied after the break.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf153964_topMarginAfterBreak14
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf153964_topMarginAfterBreak15
Change-Id: I8816b391e898cfea58c2e0dbf01c881f87bbc4c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148451
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149226
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
If there are deferred column or page breaks before an SDT,
then before starting the SDT we need to determine if the
existing run needs to split - same as everywhere else.
There was only one existing unit test that had any defered
page or column breaks, so only two example documents to work from.
That was tdf125778_lostPageBreakTOX.docx.
Change-Id: I02d71577af13399d8aaf3ba0ce40fc6bed5e6e3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148148
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148195
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from 2110597ac730fa07dbbdd603fda82b182ed27c9e
"tdf#147485 sw: fix group shape crash using std::shared_ptr".
Details:
1) Using reference instead of copy assignment in SwTextBoxHelper.
2) Cleanup: Unused parts of SwTextBoxHelper were removed.
3) Fixing destruction of textboxes, in case when first the shape
is removed, with clearing all textboxes from the doc and the shape
before the pointer is released. All of this only have to be done if
the call is not coming from the swdoc dtor, unless there will be
double freeing.
4) Missing style conversion was fixed in writerfilter.
5) Don't import sections in textboxes, unless the hack of dummy
paragraph before tables in sections will be applied and the paragraph
with anchored objects inside will be removed with the objects;
6) ConvertTextRangeToTextFrame also fixed, so embed frames in
frames are imported from now. (Also textboxes in frames, this
can be useful when there is a floating table having group
textbox with nested complex content inside, or floating table
in floating table, etc...) Note: Follow up commit will enable
group textbox import in frames and tables.
7) Import of group textboxes with complex content in header/footer
was impossible, from now this is also supported both from DOCX and
ODT (test included).
8) Guard class for blocking unwanted recursive textbox sync
has been introduced, and maybe some speedup with group
textbox import has been achieved.
9) The anchor sync method got a new function which avoids
unnecessary sync when the anchor is the same.
10) Sync of As_char textboxes during layout calculation caused
crash so that has a workaround from now, for DOCX import anchor
change and Undo. That syncs starts before the layout calculation
so sync not needed later.
11) A memory leak was found in Undo, which has been fixed.
Note: layout test "testTdf147485Forcepoint" has to be limited
to Windows and Mac builds, because font substitution
causes crash on the Unix based systems.
Change-Id: I69d5d79cc120e3a70ba9285be32ec36a434b2a04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136192
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143373
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Either we have to read sal_uInt32
(which I can't figure out how to do)
or else we have to write it out as sal_Int32.
Microsoft isn't much help here because their documentation
does not give any example of a non-tabsltop,
and one errata document indicates that MS Word
simply ignores tabIndex altogether for Sdt (and ffData).
According to the documentation,
tabIndex is a CT_UnsignedDecimalNumber
which we do not have in our model.xml
so it was defined as being a CT_DecimalNumber
which works fine for reading something human sensible like -1.
However, in our exporting we were exporting a sal_uInt32
which creates large, all positive numbers
which were not being read on import.
Nothing I tried worked to read these large numbers.
Perhaps it is even illegal to do so in MS formats?
Since it doesn't seem to matter to MS Word,
and for a human it is easier to understand -1,
and it is easier to solve in export than import,
I'm taking the easy road.
Change-Id: I6b296703c9a37149d9e11f29901e6db32bd041b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146149
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146296
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Text boxes in group shapes were imported as shapes, losing
complex text content: tables (tdf#66039), colors (tdf#73022),
images (tdf#81958), lists, paragraph styles, hyperlinks
(tdf#122960) and track changes.
Note: a few unit tests have been deactivated temporarily.
Test document "groupshape-trackedchanges.docx" of
testGroupshapeTrackedchanges is imported correctly now:
with track changes, and the test was modified accordingly.
Follow-up to commit 2951cbdf3a6e2b62461665546b47e1d253fcb834
"tdf#143574 OOXML export/import of textboxes in group shapes".
Change-Id: I6eb918dbf64393fd723fe43f798f93b5b9a12575
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125051
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143371
Tested-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In this part, oox module has been modified in order to prepare
for WPG handling during OOXML import. Note: Wpg is the drawingML
equivalent of v:group, supporting text boxes in the group.
1) Added new parameter for WpgContext to support nested
Wpg shapes, and WPS enabled for the WPG member shapes.
2) A bug has fixed, where group member line shape and
connector shapes have wrong positions before in the group.
3) Unit tests had to be modified, and 3 of them disabled
temporarily due to missing Writerfilter implementation (what
will be the next commit)
Now group shapes can have textboxes and the text is imported
for that, but complex content is still missing (this will be
fixed in writerfilter by the next commit).
Known issue: WPG shapes with textboxes in floating table
have issues during import at floating table conversion, so until
this is not fixed this function is disabled for shapes in tables
(will be fixed a follow-up commit later).
Follow-up to commit 19394a924fdc486202ca27e318385287eb0df26f
"tdf#143574 sw: textboxes in group shapes -- part 4".
Change-Id: I71032187697807087bd8f27f7c3a7b052e174bd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124964
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143367
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I19ad3ef7c911943075d7ddc01626047cdf11d5db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145070
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 1a79594a27f41ad369e7c387c51e00afb1352872)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145649
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Adds a unified UNO property for theme colors *ColorTheme
(CharColorTheme and FillColorTheme) which uses XThemeColor, that
replaces the properties *Theme, *TintOrShade, *LumOff, *LumMod.
The properties are still present for backwards compatibility and
to keep ODF support working in tests as that needs a bigger change.
Reactor the code and tests to accomodate for this change.
Change-Id: If7983decb4ba528b49fe7b5968aa9efc696a9efc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144783
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 197e5f81213d14fdcbff40edf73385ecd4cd9815)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145553
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
This change extends writerfilter to use oox::ThemeFragmentHandler
to read the theme properties, and sets that to the one and only
draw page of a Writer document.
This change also removes ThemeTable and replaces it with the
ThemeHandler, which takes theme font data from svx::Theme
instead.
In addition, a test has been writen, which loads a document with
a theme, and asserts the draw page has the theme and the theme
properties currently supported.
Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 312100003fc7cae358038aaec853584782c698f8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145388
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
1. Make the mapping in StyleSheetTable::ConvertStyleName match the
opposite direction mapping happening in MSWordStyles::GetWWId and
ww::GetEnglishNameFromSti. Add missing styles, provide comments to
clarify the process and find respective pool format ids.
2. Instead of appending " (user)" to conflicting style names, which
is the method used by SwStyleNameMapper to disambiguate API names,
append " (WW)", which allows to avoid unwanted merging conflicting
styles.
Change-Id: I47b1c7f570da6e6e21155669fdd1b77de5cc17da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145349
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145377
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
OOXML supports theme colors and tint/shade value that additionally
changed the theme color. Read back which theme color + tint/shade
value was applied in the resulting color and add this attributes
as properties to be used by writer.
In sidebar theme panel the changing the theme colors now doesn't
takes this into account and changes the colors correctly.
Change-Id: I3a2d49d485fd37a1611483ee0bb5e6034ac5f88e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143697
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit df9f3f3fd81d4f81ee2ff984d1e19999abea2963)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145350
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Now roundtrips the w15:appearance value which dictates whether there's
an effect when hovering a placeholder.
Change-Id: I3c911a0cfe31e235b9d981bbff0c1bb5827a85ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144845
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 2fe73bd2362287afc8242289a900821186b36137)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144994
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Squashed commit including
NFC cleanup docxattributeoutput: use existing function to clear
fd14dd0e4c6a7ea0866a686f653db90301d664b6
Follow-up to 100c914d44ae8f362924fe567d7d41d0033ae8ad
which added the initial id preservation for DOCX.
adding DOCX block SDT grabbaging, ODF import/export
[content controls can't exist in DOC format]
The ID field is CRITICAL to preserve for VBA purposes.
This patch adjusts BlockSDT to also round-trip the id
instead of just creating a random one.
m_nRunSdtPrToken <never equals> FSNS(XML_w, XML_id) since 2021
with 5f3af56b2c0ef6c628a7cfe5ce6e86f8e1765f5f,
so I removed that part of the clause.
I had thought about changing the ID to use a string instead of an int,
but then the integer version was adopted to fix a regression
in the commit mentioned earlier.
I think it is AWFUL to have a number as the identifier
when it will be used in StarBASIC. The VBA guys have to deal
with it, but it would be nice to do something reasonable
for LO native access to content controls.
However, the concern would be if we allow VBA macro content created in LO
to be exported to DOCX format - that would cause problems converting
from a string ID to a number ID. VBA editing already is happening to
some extent, and mmeeks seems interested in enabling it.
So over-all it seems best to just stick with an integer ID.
I used the commits for <w:alias> and <w:tag> to compose this patch.
XML_ID already existed in include/xmloff/xmltoken.hxx
and "id" already exists in xmloff/source/token/tokens.txt
The ID can be used in VBA to select a specific control.
The id (which is a positive or negative integer in DOCX)
specifies a unique control - either by passing the number as a string
(of the UNSIGNED value) or by passing as a float (specified with #).
For example:
msgbox ActiveDocument.ContentControls(2587720202#).ID
msgbox ActiveDocument.ContentControls("2587720202").ID
but not as an integer since that is used for index access.
dim index as integer
index = 1
msgbox ActiveDocument.ContentControls(index).ID
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
Change-Id: I5c4022dc932d941fad9da6d75ce899ee1ff66ff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142818
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144625
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
This has to be vital to keyboard navigation.
Certainly it is good to have it imported
before we start to consider tab-movements
for form controls.
All tabIndex 1's are processed (in placement order)
and then the 2's etc. 0's are to be done last.
XML_TAB_INDEX already existed in include/xmloff/xmltoken.hxx
and "tab-index" already exists in xmloff/source/token/tokens.txt
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
No existing unit test found containing blockSDT with tabIndex.
Change-Id: I8a958844e6192b079a2b22a62dedfd8739021f4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143603
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144623
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
ShowingPlaceHolder causes all the text in the control to be
selected when the control gains the focus. Otherwise, just a
cursor is placed at the click point.
While round-tripping this attribute worked for inline SDTs,
it was lost for block SDTs. But BlockSDTs are very easy
to create. The MS templates are full of them.
Also, these are boolean, but it could have a val=0 specified,
in which case it is off, but we were importing it as on.
Change-Id: I167afa935311a63bba408ecd489ae819485a5cb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143818
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144621
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
DOCX SdtControls can be locked in two ways:
-Content Control cannot be deleted (sdtLocked)
-Contents cannot be edited (contentLocked)
or both (sdtContentLocked)
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport4 CPPUNIT_TEST_NAME=testSimpleSdts
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_sw_macros_test CPPUNIT_TEST_NAME=testVba
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
Change-Id: I5a82d9f6b5103a4902f59af66cd8a99addd4e690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143542
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144553
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
The tag is critical for VBA access.
Although we do not yet import blockSdts as content controls,
losing this would break any VBA macros for MS Word.
So make sure it round-trips.
I can't imagine why it wasn't treated the same as alias.
I guess because Alias is seen, while tag appears to have
no valuable function (until VBA, where it becomes the most
likely ID field.)
Change-Id: I05a04faa9d2314c7b37c5b86f107bd1a16019509
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143830
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144552
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Crashreport signature:
program/libwriterfilterlo.so
writerfilter::dmapper::SettingsTable::GetListSeparator() const
writerfilter/source/dmapper/SettingsTable.cxx:489
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::convertFieldFormula(rtl::OUString const&)
include/rtl/ustring.hxx:226
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::handleFieldFormula(tools::SvRef<writerfilter::dmapper::FieldContext> const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&)
include/rtl/ustring.hxx:527
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand()
writerfilter/source/dmapper/DomainMapper_Impl.cxx:6458
Change-Id: I7f48f76cacffa00d633d92f0a51b2d82f96d1e74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144314
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I20f4439abfbf73485734fd8373fffb2916d390f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143470
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit dda4867a0b5a2d29d8a01a3656e0c8dac7626d2f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143441
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
We generate such files currently. Fixing that will be another commit.
Change-Id: I788501e346cba63c08a767c0e05e063bc1172089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143223
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 9a7945f36ce95a48e0d525bc444e722b9ec5c452)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143171
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Exporting the DOCX bugdoc back to DOCX resulted in a document that can't
be opened in Word.
Examining the output, the problem is that the document had 2 inline
<w:sdt> elements with <w:id>, and we mapped such <w:sdt> elements to
both grab-bags and content controls, leading to duplicate <w:sdt>
elements on export. This is schema-valid, but it goes against the
intention of the spec and Word can't open it.
The initial fix was just a writerfilter/ tweak to avoid grab-bagging
<w:id> for inline <w:sdt>, but CppunitTest_sw_ooxmlexport4's
testSimpleSdts points out that in other cases we already require
preserving <w:id>. Fix the problem by storing <w:id> in the content
control, which is essentially a subset of
<https://gerrit.libreoffice.org/c/core/+/142818>.
Thanks to Justin Luth! - he prototyped the DOCX filter for <w:id>.
(cherry picked from commit 100c914d44ae8f362924fe567d7d41d0033ae8ad)
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport18.cxx
Change-Id: I9f002b770049ce8be30253d0b39410d9a58981dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143139
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Found during a code read, while attempting to add another property.
(cherry picked from commit e960d3fea28fe4c180dc5612ce00682e432e9772)
Change-Id: I342c51c81f23e1e3178e7d412f9af685f3fd4ae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143138
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
- Replace SwContentControl::HasListItems(), which assumed that the type
is dropdown if we have list items. This is not valid, it's OK to have
a dropdown with no list items. Add a GetDropDown() instead to check
for the type, explicitly.
- UNO API sets the dropdown bit when list items are set and the type is
not expilcitly combo box or drop down, to keep backwards
compatibility with existing documents.
- No change to the edit shell, SwDropDownContentControlButton already
checked if items are empty and used STR_DROP_DOWN_EMPTY_LIST in that
case, but that was dead code previously.
- ODT & DOCX filters are now updated, ODF has a new
<loext:content-control loext:dropdown="..."> attribute to specify that
the type is a dropdown, explicitly.
(cherry picked from commit 56db6406b0b63a2d2d99024e7c311ebd874f3893)
Conflicts:
xmloff/qa/unit/text.cxx
Change-Id: Id577ba9639151549a8f953aab31685a73a898504
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142544
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The document had a 2022 date in document.xml, but had a 2012 date in
data binding. Writer used to show 2022, while Word picks 2012.
Data binding for dates were disabled in commit
de90c192cb8f1f03a4028493d8bfe9a127a76b2a (sw content controls, plain
text: enable DOCX filter with data binding, 2022-09-19), because the
formatting of those date timestamps were missing, so it was better to
just not update them from data binding, temporarily.
Fix the problem by adding a new read-only DateString property on
SwXContentControl, this way the import filter can set not only the
timestamp but the formatted date as well.
This shares the SwContentControl::GetDateString() code with the UI,
which already had the need in the past to turn a timestamp into a
date string, based on a provided language and date format.
(cherry picked from commit 58002ab85d992c7ac44d8bb4d135246b67aa5cc7)
Conflicts:
sw/source/core/unocore/unomap1.cxx
Change-Id: I842a9483a675f895129a9854caec347be6b6b84e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141867
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Footnote/endnote numbers in the footnote area didn't get
superscript etc. formatting in non-English locale
settings because of the writerfilter mapping to
the English localization ("Footnote Characters" and
"Endnote Characters") instead of the correct
programmatic character style names ("Footnote Symbol"
and "Endnote Symbol") according to
SwStyleNameMapper::GetChrFormatProgNameArray().
Testing: unit test of tdf#82173. Manual: e.g. open test
document of tdf#138625 in an Italian build, after setting
Italian locale in it in Tools->Options...->Language Settings->
Languages->Language of user interface.
Follow-up to commit 707eb4db1918658e0c2c2c2033c6a69f80c4eafd
"tdf#82173 writerfilter: charStyle XnoteReference->Xnote Characters".
Change-Id: I36b3c5ff065e9f80289d051e27f618b40e0c9355
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140918
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 5a1c668747f3495ddc7567ae95f2145663565647)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140891
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
in DomainMapperTableManager::endOfRowAction()
See https://crashreport.libreoffice.org/stats/signature/writerfilter::dmapper::DomainMapperTableManager::endOfRowAction()
Probably since 116cadb5d2582532c69677a2f8499e8e9b7b9b80
"tdf#59274 DOCX import: fix tables with incomplete grid"
Change-Id: I12f2842107885fbbc62be2186511102f642e3efc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139657
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit b69a37e567a6a0b6c24a4438a0da906497c750f0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139660
|
|
Dropdown content controls have list items, and each list item can have a
display text and a value. These are optional, and the bugdoc has a list
item where the value is set, but not the display text.
The trouble is that later in DomainMapper_Impl::PopSdt() we check if the
length of the display texts and values array match and if not, then we
throw away these arrays to avoid creating an inconsistent document
model.
Fix the problem by checking what display text and value we got at the end
of each list item; if any of them is missing, we add an empty string,
which matches the internal representation in SwContentControlListItem.
This also helps in case these array sizes matched by accident, but
display texts and values from different list items were mixed
previously.
(cherry picked from commit f726fbc2699b05199a8dec3055710a7131e0aad6)
Change-Id: Ib1eeabd2479963af4a84d4229d4f0ce4572e0f01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141162
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is similar to <w15:color> to preserve <w:tag>.
Resolves
<https://gerrit.libreoffice.org/c/core/+/137399/2#message-a5ba9f1e0dc9e586034758ee7c0a94e1533e8922>.
(cherry picked from commit 5262aab9d220675f616579720b4bb43ee03cccfb)
Conflicts:
sw/source/core/unocore/unomap1.cxx
Change-Id: I4fdab44aaf13ca812502ae79f38f32ec9468db11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141025
Tested-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is similar to <w15:color> to preserve <w:alias>.
Related to
<https://gerrit.libreoffice.org/c/core/+/137399/2#message-a5ba9f1e0dc9e586034758ee7c0a94e1533e8922>.
(cherry picked from commit 481a082469802ffce08cd8c110e715260015eb97)
Conflicts:
sw/source/core/unocore/unomap1.cxx
Change-Id: I774b7204c5ca02ec6db89f5cbd3a6de6f2bf82a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141024
Tested-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Map the ComboBox UNO property to:
<w:sdtPr>
<w:comboBox>
...
</w:comboBox>
</w:sdtPr>
and the opposite on import.
(cherry picked from commit 01b1f57a90172a76faa1489b3b72250ee76169a6)
Change-Id: I50e0b961bca99f4ecca86d6784d2e6a13f469314
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140432
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Export of this document to DOCX wrote not-well-formed XML output,
resulting in an assertion failure in debug builds.
writerfilter/ maps a selection of <w:sdt> tags to Writer content
controls (a safe subset), and leaves the rest unchanged, which means we
continue to map those to grab-bags. The trouble is that a combination of
content controls and grab-bags leads to bad output on export, as we
start the <w:sdt> element twice, but only close it once.
Fix the problem by extending writerfilter/ code to not do any grab-bags
for the richText type, we already did that in the past for dropDowns.
In the long run, we should never do grab-bagging for any <w:sdt>
elements that we map to Writer content controls.
(cherry picked from commit 7ad44f3dd271a591529b048212c4391d8b38ed9d)
Change-Id: I27a0b814efd667cc0477d8f492f7f956c938c854
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140431
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
- writerfilter/ had explicit code to not map plain text SDT to Writer content
controls if it has data bindings specified, lift this limitation and set the
value of content control from data binding, like Word does and Writer did it
for input fields since b5c616d10bff3213840d4893d13b4493de71fa56 (tdf#104823:
support for sdt plain text fields, 2021-11-24)
- call DocxExport::AddSdtData() on the export side to do the opposite on export
- give up on the idea to export content controls to DOCX by finding the text
attribute in SwWW8AttrIter::OutAttrWithRange(): this needs buffering in both
directions (need to start the SDT before the start of the run, need to end it
after the end of the run), and solving this using marks and merges at a
fast-serializer level looks like hacks on top of hacks. To be more specific,
CppunitTest_sw_ooxmlexport7's testSdtAndShapeOverlapping seems to be very hard
to fix with this design
- instead, give not only the start position but also the length of the run to
DocxAttributeOutput::EndRun(), which has random access to the doc model and can
look up if there is a content control start or end that needs writing at the
current position of the XML output, without any buffering, which also
means less code
- adapt CppunitTest_sw_ooxmlfieldexport's testSdtBeforeField, which didn't like
the empty run at the start of content controls, which seems to be harmless
otherwise
- fix CppunitTest_sw_ooxmlfieldexport CPPUNIT_TEST_NAME=testSdtDateDuplicate by
disabling the "set content control value from data binding" logic for date
pickers because that logic in writerfilter/ sets the value as-is and it has to
consider the requested date format before this can be enabled
As a side effect, this gives PDF export for plain text SDTs, even if they have
data binding set. CppunitTest_sw_ooxmlfieldexport's testTdf104823 is now
updated to ensure that we import such SDTs as Writer content controls.
(cherry picked from commit de90c192cb8f1f03a4028493d8bfe9a127a76b2a)
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx
sw/source/filter/ww8/docxattributeoutput.cxx
sw/source/filter/ww8/wrtw8nds.cxx
writerfilter/source/dmapper/SdtHelper.hxx
Change-Id: I749a845b5a25454c51066b8ded892682f523b6b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140180
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Previously generated name was assigned only if not in doc
reading mode. But there is no guarantee that it will be assigned
later. Better to insert any name in SwDoc::MakeFlySection_() and
later it can be overwritten, but fly will definitely have
any unique name.
* Some test failed because GraphicImport_Impl::applyName() overwrote the
name with a different generated one.
* This breaks chaining of VML shapes, see test testTDF87348.
The code introduced in commit 091fe76b6329b4bb974987554369cbfadd8f2401
in DomainMapper_Impl::ChainTextFrames() breaks if the text frame
already has a name; it's a bit confusing which names there come from
the file and which come from the API, and it also mixes 2 different
cases of VML chaining and DrawingML chaining that look like they
should be using different data.
* This also breaks moving flys anchored at-char in flys into them in
SwXText::convertToTextFrame(), see ooxmlexport13 testFlyInFly.
This kind of worked by accident before: the fly is copied and then the
original deleted, keeping the same name (with help of
SwDoc::mbCopyIsMove); with no name it would compare the SdrObject
pointer, which is different for the new copy, now the name is the
same.
Fix this by only moving flys anchored at the edge of the selection
back inoto the body; it turns out that Word actually supports at-char
anchors in text frames, but only if it's a VML shape or Compatibility
Mode or whatever; i wasn't able to do it in a document created from
scratch.
This is a bit tricky to ignore the nodes added for floating tables as
seen in ooxmlexport10 testFloatingTablesAnchor.
* Another change is required in SwDoc::SetFlyName() because of
testTdf127732, as it would rename a frame named "Frame1" to "Frame2"
when called to rename it to "Frame1".
* Some tests failed because after MakeFlySection_() assigns a name it is
immediately unconditionally overwritten; replace that with asserts
Change-Id: I46752a4413ba3a9e981eccd1e153b3aaf8053781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127556
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 4d6243693c228703394c00164276f8326447beb9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137764
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
- the core of this is the writerfilter/ change to call PopSdt() for
SdtControlType::plainText, which maps inline plain text SDTs to Writer content
controls, not to input fields
- disable the grab-bag in this case, otherwise we would run duplicated <w:sdt>
elements on export
- fix CppunitTest_sw_ooxmlexport7's testSdtAndShapeOverlapping by postponing
the SDT start in DocxAttributeOutput::WriteContentControlStart() in case a
shape is anchored at the same position as the SDT start: if the shape should
start inside the content control, then it should be anchored after the dummy
character
- reduce the debug output in VMLExport::Commit(), which could write control
characters to the terminal on test failure, potentially breaking it (requiring
a 'reset' to recover)
- fix CppunitTest_sw_ooxmlexport5's testSdt2Run: now we merge two runs inside a
plain text content control into a single one, and there is no problem with
that, so adapt the test instead
- fix CppunitTest_sw_ooxmlexport17's testTdf148361: plain text inline SDT is
now a content control, not a field
- fix CppunitTest_sw_ooxmlfieldexport's testfdo82492: explicitly assert that
there is 1 text run inside the SDT and there is a shape after it (outside).
Also extend DocxAttributeOutput::EndContentControl(), so it ends the content
control at the correct, earlier position in case it's followed by an as-char
shape
- fix CppunitTest_sw_ooxmlfieldexport's testfdo82123: again assert that the SDT
has 1 run with text, and there is a drawing after the SDT
- fix CppunitTest_sw_ooxmlfieldexport's testTdf104823: this revealed that some
more complex logic is needed to support data bindings, so exclude
text-with-databinding from the scope of this commit and continue to map those
to input fields for now
- fix CppunitTest_sw_ooxmlfieldexport's testFdo81945: this had a similar
problem as as-char shapes, but this time a new SDT is starting right after a
previous SDT. Adapt DocxAttributeOutput::EndContentControl() accordingly,
though perhaps this should be generalized later, so we always close SDTs in the
previous run, unless this is the last run, or something similar
(cherry picked from commit 9700c1b2170ad04453a361ed5647937833ac3c18)
Conflicts:
oox/source/export/vmlexport.cxx
Change-Id: Ifaf581be884a683de6c8b932008a03ba43734b75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137494
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The document had a block SDT and inside that, a run SDT. The content
that is before the run SDT but already inside the block SDT was lost.
To work incrementally, it was intentional that once commit
5ee8670f18cb8b1913a23d04590d6a31ac9730de (sw content controls, date: add
DOCX import, 2022-05-30) changed most of run SDTs to content controls,
it left block SDTs (and cell/row SDTs, too) unchanged, so they are still
mapped to fields. What was forgotten is that m_pImpl->m_pSdtHelper in
DomainMapper is a shared state: once a run SDT starts, it assumes that
no non-run SDTs are in progress.
Fix the problem by explicitly checking for non-run SDTs before
PushSdt(), that keeps the separation (content control for run SDT,
fields for the rest) but fixes the lost content.
This is for plain text SDTs, but other types can be added if necessary.
(cherry picked from commit bab023ce3b584e815067a207adc7a8aca1f964af)
Change-Id: I46b029a3a945d7416028aa196ac3160e6d96eae8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136664
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
a string that ends in spaces
Change-Id: I808f046be816d0d4a76f801a349e284024a2061c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136465
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
- map
<w:date>
<w:dateFormat w:val="..."/>
<w:lid w:val="..."/>
</w:date>
to the Date, DateFormat and DateLanguage UNO properties of content
controls instead of fieldmarks, which model content controls poorly
- fix CppunitTest_sw_ooxmlexport8's testN820509: date SDT is now a
content control
- add current date DOCX import
- fix CppunitTest_sw_ooxmlexport13's testDateControl: date SDT is now a
content control
- fix CppunitTest_sw_ooxmlexport13's testInvalidDateFormField: date SDT
is now a content control
- fix CppunitTest_sw_ooxmlexport5's testfdo83048: minimal support for
nested SDTs in DomainMapper::lcl_attribute()
- fix CppunitTest_sw_ooxmlfieldexport's testDateFieldAtEndOfParagraph:
date SDT is now a content control
- fix CppunitTest_sw_ooxmlfieldexport's testDateFieldInShape: date SDT
is now a content control
- fix CppunitTest_sw_ooxmlfieldexport's testSdtDateDuplicate: date SDT
is now a content control
- fix CppunitTest_sw_ooxmlfieldexport's testSdtDatePicker:
- retain placeholder
- retain data binding
- retain color
- fix CppunitTest_sw_ooxmlimport2's testTdf121203: date SDT is now a
content control
- fix CppunitTest_sw_globalfilter's
testDateFormFieldCharacterFormatting: date SDT is now a content control
- fix CppunitTest_sw_globalfilter's testDateFormField: date SDT is now a
content control
(cherry picked from commit 5ee8670f18cb8b1913a23d04590d6a31ac9730de)
Conflicts:
sw/qa/extras/globalfilter/globalfilter.cxx
Change-Id: I5a4c34217d23ed6fa0916e4dd6290351456b7232
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135152
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Otherwise formatting may get lost when the result is stored as DOCX.
Change-Id: I62cbeb1fc9f120dd9c424daf5dc0471686715537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134694
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 123d3a9301c90925c23cfb4806d7b0be01b975d6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134762
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Seems original problem is no longer reprodicible with recent builds
but ovewriting of numbering style params with inline values leads
to another problems.
Removing this mechanics do some impact on RTF filter: it tries to
modify numbering styles, so this was also corrected. It is not ideal
yet but looks better in support numbering char properties different
from paragraph ones.
This reverts commit 2123ede032ca64f696ef54af4ad3238974ca2b5d.
Change-Id: If8c79d6191de13b2f09c128b59d17efcfdb1a4ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133877
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134636
|
|
On save LO was just emitting w:lvlOverride to actual level
where override does happen. But MS Word won't accept override
for next level if there are no overrides for previous ones.
For example, if we are overriding level 3 we should also emit
empty lvlOverride for levels 0-2.
Provided fix did cause some problems on DOCX import: overrides
were applied to current level, but in this context current !=
actual level where override did happen.
Change-Id: Ia00dd9a5990f7f122027e8126f411642c32da189
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134411
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
(cherry picked from commit 198381eb32edcc3e82d0f23df65f0804a08b44e6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134452
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Map Picture UNO property on content controls to:
<w:sdt>
<w:sdtPr>
<w:picture/>
...
And do the opposite on import.
(cherry picked from commit 22d7cbc0f0c50c59abca7ab5f7db46e4d0e5f86a)
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport17.cxx
Change-Id: I5b164f796f194f5fc4bb30d7a30e053e577ed92d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134848
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Paragraph of the anchoring point of the floating table
needs zero top and bottom margins, if the table was a
not floating table in the footnote originally, otherwise
docDefault (Standard) margins could result bigger vertical
spaces around the table.
Quasi regression from commit c46950fee11f5207fb8324947280cd565ae483e7
"tdf#143583 DOCX import: fix lost empty paragraphs of footnotes"
(before this commit, empty paragraphs at the end of the footnotes
were removed by accident, which hid the real problem fixed now).
See also commit e11c51eefe8c3210cef2b5850f401ba67a401d01
"tdf#95806 tdf#125877 tdf#141172 DOCX: fix tables in footnotes"
(Note: before this commit, only a single table was shown instead
of the eight tables of the eight footnotes.)
Change-Id: I4180a6f7d7c49faf0842637b23aa1c8c5680a76c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133752
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit d1ac8df139a2a65db45d1970ccc0b80e17d827f6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133728
|
|
- inline drop-down content controls were imported as an SwDropDownField
previously, but that has the drawback of not being able to store both
display texts and values of each list items
- adapt tests under sw/qa/ which asserted that the import result is a
field, and check content control properties instead
- change dmapper so that SdtControlType::dropDown is one more inline
SDT that gets mapped to SwContentControl
- remove the no longer needed grab-bagging in writerfilter/, otherwise
we would write the SDT markup twice on export
- improve DomainMapper_Impl::PopSdt() to actually map the collected
dropdown properties to properties on the to-be-inserted content
control
(cherry picked from commit 24417d8c3c9e1c619936e85fa7a20481a24e3530)
Conflicts:
writerfilter/source/dmapper/DomainMapper.cxx
Change-Id: I7e88ec8cd1d73bc1c6c75154d6ab07352cbcec8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134258
Tested-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|