Age | Commit message (Collapse) | Author |
|
With this, images are exported as PBrush OLE objects, to please some
consumers (e.g. IBM Doors).
Change-Id: I89805cd66709d96cbe71853d65671f76a3fc871f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116348
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
If the paragraph is longer than one line,
then do not IgnoreBlanksAndTabsForLineHeightCalculation,
which was introduced in LO 4.0.
This is a preliminary step for fixing bug 142404.
I found a few pre-existing unit tests that triggered this,
but none were good examples to use as proofs.
ooxmlexport7: 77219 - not sure where - no visual difference.
ooxmlexport10: 92157 compatibilityMode15, but visual too little.
ooxmlexport11: 88496 - not sure where.
ooxmlexport13: 121374_sectionHF2.doc -tabOverMargin in header
NOTE: This patch could be seen as a BAD THING in the case where
tabOverMargin normally hides EVERYTHING. We don't handle
that situation yet, so a very long series of tabs could
take up several lines of space (which isn't done in Word).
Now with this change it could take even more space.
Well, the proper fix would be to not show any of those.
Perhaps we could just set the width of the portion to
zero if it sails past the end of the page?
Anyway, the point is that this it-isn't-right-anyway
situation should not block pushing this patch through.
Change-Id: Iaea8e0edf78c8fbe319aadbc6d62fc0bdd180814
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116317
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Ide709668ce88345ff01c2945f28ceca164faf17d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116325
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Since internally LO is able right now to use list level format strings
and prefixes/suffixes only for backward compatibility, there is a need
for conversion from format string (like "%1.") to prefix ("") and suffix
(".") still used by ODT.
Change-Id: If4b459e1b25b7f0ce511e6ac2de0824bb2c43d05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116288
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
The native data is BMP, presentation data is not yet done.
Change-Id: I30ef9f0c3b4dc7801e600ac751c32179372d5e4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116266
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I5b87f52ec4f905df1ae2e9175ac3807171614bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116244
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
to OpenDocument format using
<style:table-row-properties loext:text-changes-only="false"/>
Rename also com::sun::star::text::TextTableRow::IsNotTracked
to com::sun::star::text::TextTableRow::HasTextChangesOnly.
Follow-up to commit 05366b8e6683363688de8708a3d88cf144c7a2bf
"tdf#60382 sw offapi: add change tracking of table/row deletion".
Change-Id: Iefb0d4095af0983fdd15697d5b80073d18d21bd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116212
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I37fe18528dbe821eb60c7b1d6c65039e2ae91b7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116236
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I2e52a042b514e6724dbd282a41a4ca7f66981f2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116233
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
See commit a226cec52e536c46e03f57a5f1f7931abbeb0cdd
(CppunitTest_sw_rtfimport: convert one testcase to use
CPPUNIT_TEST_FIXTURE(), 2019-11-05) for motivation.
Change-Id: I7a6de527c28c543d7b622398dab406e2bfb80805
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116216
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Some consumers (e.g. IBM Doors) can only consume the RTF snippet if it's
an OLE object and can't deal with plain images.
Wrap \pict inside \object and unconditionally use WMF as the RTF-level
preview format. The actual \objdata is not yet written.
Change-Id: I203fcd8709b25a4dd543047bd804af8181df9940
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116207
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
So that when it fails, it's easier to debug because it's in-process.
Change-Id: Ia7d12291b25304967a22e546b12803864a713541
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116127
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Textboxes are implemented as loosely connected
shape-text frame pairs. Missing synchronization
of their z-orders resulted e.g invisible or
only partially visible textbox content using
Arrange options with textboxes (see in local menu
or on Drawing Object Properties toolbar).
Note: because it's not possible to send frames
to the background, Arrange->To Background hasn't
supported, so likely it's worth to remove that
option later from local menu of textboxes.
Change-Id: I1aa50903ba55dd5b9e72ef203c4e30218bee68fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115227
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
As far as I see, Word is using lists with id=0 and no list definitions
to reset list numbering used in this paragraph. At the same time Word
is still using some of default list properties. For example in this
scenario parent style has defined first line indent, but in paragrath
it is overwritten by "not existing" list=0 without definitions.
To this moment I know about only first line indent behavior, but
probably some other properties are also affected.
Change-Id: I344c907bb7a7b83a91f5727e13ad184fb44137b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115795
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
using the new com::sun::star::rdf::URIs::LO_EXT_SHADING
URI (modelled after odf:prefix and odf:suffix).
Custom color field shading of text:meta annotated text
ranges and text:meta-field metadata fields allows
quick visual check of metadata categories.
For example, RDF triple
content.xml#id1753384014 urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0odf#shading FF0000
sets red (FF0000) shading color for the text span
with xml:id="id1753384014".
Pressing Ctrl-F8 or View->Field Shadings can disable
custom color metadata field shading on the UI.
Note: neither LO_EXT_SHADING, nor odf:prefix and
odf:suffix changes invalidate the View (MetaPortion),
but run-time update of shading color can be triggered
without save and reload of the document e.g. by using
(temporary) bookmarks on the annotated text spans.
To run unit test with enabled visibility, use
(cd sw && make UITest_sw_styleInspector UITEST_TEST_NAME="styleInspector.styleNavigator.test_metadata_shading_color" SAL_USE_VCLPLUGIN=gen)
in Linux command line.
Change-Id: I5de93cfa32ac6793d7dbdc7b64e6f4beacb2e8d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116015
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
TextTableRow property. Remove also maybevoid from
com::sun::star::text::TextTableRow::IsNotTracked.
(It's possible to add it later, if needed.)
Follow-up to commit 05366b8e6683363688de8708a3d88cf144c7a2bf
"itdf#60382 sw offapi: add change tracking of table/row deletion".
Change-Id: I4854dcda827cc8d5b1d0ec8bba381458b3ab17b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115988
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
o3tl::narrowing() is a better way to handle this, as that way the
integer conversion is still implicit, which allows detecting integer
truncation at runtime (with suitable compiler flags).
Change-Id: I499abda3be6943e8c111c56df390e72939586221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115948
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I488c722fcba553f8784a1b14d841128cbda77934
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115924
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A new function was defined, XdataInterpreter::getChartTypeSpecificData.
Being 100% chart-type-agnostic when retrieving chart data is impossible;
candlestick charts can have different numbers of sequences per series,
and this information is not present in any other chart type.
Change-Id: I0f54b09202c42667331b083d54d90e4ceee81083
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Text wrapping around shapes and images used to be
turned off in header and footer frames. This commit
simply reenables that feature for headers/footers
(to avoid also regressions related to the fix i13832).
Change-Id: I46ca112f36e0c0c86342fa34fdb7cb7502745731
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113098
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I2dbc2f09d61220100fb616c28a8f2557c84f460f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115871
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
The line height can be quite large if the line contains an as-char
image.
Found by temporarily changing static_cast<sal_uInt16>() in sw/ to a
template function to make these conversions implicit (excluding cases
where the input and output types can't convert implicitly), then asking
-fsanitize=implicit-unsigned-integer-truncation
-fsanitize=implicit-signed-integer-truncation to flag the problematic
conversions.
The first hit was in SwFlyCntPortion::SetBase() (that's where 67408
turns into 1872), then the same pattern at many other places.
Change-Id: Ie12f490ed8dd5c531f11506c97598ce4f7610e2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115873
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is a minimal extension of the text range based change
tracking to record and apply table row and table deletions
with full Undo/Redo support.
Add property IsNotTracked to com::sun::star::text::TextTableRow.
During recording of track changes, deletion of table rows wasn't
recorded: the rows removed completely with their text content.
Now the deletion deletes the cell content with change tracking,
setting also IsNotTracked property of table rows to FALSE. If
all tracked deletions were accepted in a row, and the result is
an empty row, the row will be removed, if its IsNotTracked
property is FALSE.
Note: Deletion of empty lines isn't recorded (they are simply
deleted). Hiding deleted rows hasn't been supported yet in
the Hide Changes mode.
OpenDocument supports only track changes of text ranges, but
not changes of the table structure, e.g. deletion of table
rows. For the native export it needs to extend ODF, and
depending on this future extension, can be based also on
SwExtraRedlineTable (which lacks of recording and Undo/Redo,
but supports OOXML round-trip of tracked table changes).
See also commit d688069023959ab97d14eb1dbfd5bf6ad3c1b160
"Add support for 'Table Row Redlines' in SW core" and its
follow-up commits.
Change-Id: I2e3807cf8ae8212bd51c210ef1c20c85878d0da8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115804
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I800e966cee8343099fb79f08959ba246a831aee0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115826
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I110404a73ccdbffed788009730967b0efbbaf51f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115785
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
And do the same for modification fields (e.g. modification date) and
subject fields as well. In all cases the layout already reacts to the
doc model change via normal notifications, no need to force anything.
(Confirmed with manual testing.)
This builds on top of commit 0a32630d11ebdb8b8218faa066c72582ef2f300d
(sw: fix not needed invalidation of title field on each keypress,
2021-05-18).
Change-Id: I8015b33a6680d75cd5b6446eb9275bb018ea7613
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115784
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I38e7c1a0accf569a70d1d3bc5e04042538afadff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115756
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Type a character, SwDocShell::DoFlushDocInfo() is called because the
number of characters changed, and that rapaints all title fields.
This happens as SwFormatField::UpdateTextNode() calls
SwTextField::ExpandTextField() with bForceNotify=true, because that was
needed for conditional text in commit
cd94a84b89c476760ad74bf088a5d6f8ba4ce209 (125044: - use field's content
cache on <SwTxtFld> construction only, 2014-06-13).
Fix the problem by not forcing notifications for title fields in
SwFormatField::UpdateTextNode(): SwTextField::ExpandTextField() will
send a notification if the expend result differs without forcing as
well.
Change-Id: I5e46ab6aef33ff5e348d40b8644bcc9cf353c326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115743
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
It already has 2 cxx files
Change-Id: I74aeea953568b82aff3130b20547a7c207783431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115628
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is building on top of commit
f2eae41e9a85cd1df4190160b7453d3e12b8ccbd (sw XHTML export: <blockquote>
can't have character children, 2019-11-07), which handled this in
general, but only worked in case the Quotation style had a non-zero
bottom margin.
Change-Id: I4008ee964d9a87a6cf409a63affce8e44d63b602
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115580
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is building on top of commit
119b6876c92e4cdae44583c4b1b1419d3533e3ee (sw XHTML export: properly
write <li>...</li> around multiple paragraphs, 2020-05-21), but the
use-case here is a numbering with list labels only.
The first problem was that the list label had its <li> suppressed, but
not its </li>.
The other problem is that <ul> can only have <li> child elements, so at
least fix the case where the list only has list labels, in which case
even <ul> and </ul> should be omitted.
Change-Id: Id38978a40d8618f483e3e9d499f75838d5b2adb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115543
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
During ODF import, due to removal of the pDocShell parameter, this hits
else
rCharStyleName = sCharFormatName;
while setting the "CharStyleName" property and later
GetNumberingRuleByIndex() prefers m_sNewCharStyleNames over the
format set in the SwCharFormat??
Also, "BulletFontName" has a similar problem; otoh "HeadingStyleName"
only makes sense on chapter numbering.
The m_pDoc and m_pDocShell members are such a WTF.
(regression from ae0e4a6ba9be2fa99ac2be8e20157806e36209b2)
Change-Id: I9d4d4cd7aeb7e6e29221d53facaff213fd4e35a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115495
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Follow-up to commit d845b91bcc6eb885c55494d4d4fab4ec09577e1d
(tdf#78864 sw track changes: cross out deleted images).
Change-Id: I3daa772ac80f777e1badc58a424f98b1d655acba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115442
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Normal images got crossing out from the next deleted images.
Fix it by using only the start position of the image in CheckLine()
instead of the 1-character length range of the anchor point.
Note: add unit test also for tdf#78864.
Follow-up to commit d845b91bcc6eb885c55494d4d4fab4ec09577e1d
(tdf#78864 sw track changes: cross out deleted images).
Change-Id: I8894e625d479adea4b1003f55f24f292064ed7ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115255
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Follow-up to commit e463d239555d3a4dc61797eeb8c638b6442112a3
"tdf#140731: sw transliteration: avoid too many redlines"
Change-Id: I49d80d6fa5744797b7bb56d470ebc6f3b5f898d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113402
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ia8fef7dea598cd2ea1513908f69e0176c057900b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115309
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Id236fa585ae02cb0282a7d6179b9cb2d779dfdf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115182
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Deleted images were imported as not deleted part of
the document. Both deleted and inserted images lost
their change tracking.
Change-Id: Ia273d307d01c5ea535889bc9951084e96cd7fc50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115178
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The column break was moved into the neighboring shape during
the first import, and eliminated during the second import,
losing the 2-column text layout. As a workaround, split the
paragraph moving the column break into a new paragraph.
Based on the patch written by Justin Luth.
Co-authored-by: Justin Luth and Tibor Nagy (NISZ)
Change-Id: Id4042a92b09aa55952bc0ea02319d5e588f77d3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114904
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ibc86f8a76080b55dd7c5a458e2b8fa7ce534a4b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115164
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
On page 9, SwSectionFrame::Format() calls CalcContent() and that formats
all its content frames, then on SwTextFrame 91
SwObjectFormatter::FormatObj() fails becuase it moved forward.
With commit c799de145f7e289f31e3669646e5bd12814e6c5e this now sets the
o_rbPageHasFlysAnchoredBelowThis to true, which prevents a call to
SwLayouter::InsertMovedFwdFrame(), and the flys anchored in next frames
aren't moved off the page at this time.
Then the loop starts over at the beginning of the SwSectionFrame, and
frame 91 will be formatted again because the loop tries to format the
first frame on the next page to see if it will move back; now the
MoveBwd() isn't prevented any more so the result is the same failure
in SwObjectFormatter::FormatObj().
Fix this by ignoring the bRestartLayoutProcess in case the current frame
was originally on the next page and didn't move back (or, as is the case
here, moved back and then forward again); it should just be formatted
again on the next page. Once that happens, it will eventually be
entered into SwLayouter::InsertMovedFwdFrame() too.
This happens to fix another problem with this bugdoc too: the first
column of the section on page 9 is empty. This also happens in LO 6.4
but not LO 6.1.
An alternative would be to move the flys anchored below off the page as
is done in SwLayAction::FormatContent() now but sections can be in flys
or footnotes or headers so perhaps it should be done only at the
top-level.
(regression from c799de145f7e289f31e3669646e5bd12814e6c5e)
Change-Id: I0965aebb4e3cec687f4e70f8d5e3aa8a55da3393
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115144
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Only line dash pattern of the selected line style
was applied on the selected line or shape using the
1) Line Style popup menu of Drawing toolbar and
sidebar pane Properties and 2) Style popup menu
of Line pane of Line setting dialog window.
Now both line dash and line cap settings are applied,
supporting the usage of the new "rounded" preset
styles and the old not "rounded" versions.
Follow-up to commit b9b2c6a98fec798fc0ec76ec3cd407724f19dcac
"tdf#141933 add preset dash styles with round cap".
Change-Id: Ib3f64afcdcb50545166d40476a03a4b45f7d0b8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114461
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
New OOXML-compatible preset styles weren't recognized
on the UI, including the Drawing Object Properties
toolbar and Line Style settings, if the preset styles
use round cap, e.g. line styles with dot-like dots (i.e.
not tiny squares as dots).
As a workaround for interoperability and access to
the line styles with dot-like dots, add "Rounded"
version for every OOXML-compatible preset styles with
round cap. This allows to apply dot-like dotted lines
to new shapes, too.
Background: round cap modifies the DotLen and DashLen
values of the LineDash struct during the OOXML import,
using ~zero values to get dot-like dots. For the details,
see commit 3f3b50015e4fd9efc3459612a70409fca49cf390
"tdf#134053 tweak dash and space length for ooxml" and
commit 24d770799660d3ec94ee7add435645794426042b
"tdf#134128 Use Gdiplus::DashCapRound for round dash or dot".
Follow of commit 183c06fc02a50fb117bb6162e4d6e56cdd34fad1
"tdf#139301 fix OOXML-compatible preset dash styles".
Change-Id: I4f3173579964b2c00618ada475b012c85320f758
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114459
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
by limiting AddFrameOffsets compatibility option
for docs created by MSO 2010 or older.
Likely regression from commit 355d25eac764713f4d52eac801ade6e2ff1deab0
(n#779627: added quite some compat options from the ww8
filter on writerfilter).
This patch fixes several bugs, which were
collected as duplicates by Gábor Kelemen.
Change-Id: I106e90c4bf00bb0b6a8986615cb3ad9c4828d5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114476
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Exporting to .docx used to lose all header and footer
content that was not visible in the document at the
moment of saving. This commit forces the DocxExport
class to output all headers and footers even when
the "Same content on left and right pages" option
is turned on.
Change-Id: I6a52f216f1e1b386d887ec614198766670b5bce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113158
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The original test added in sw/qa/uitest/writer_tests7/tdf46561.py
doesn't fail without the fix in place.
While at it, move the UItest to CppUnittest
Change-Id: I254c4ed042b14adee8c702d4c047572e69040887
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115103
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Undoing the creation of a header/footer used to leave their
corresponding document nodes intact, causing the node index
of a previous undo entry to point to the wrong node.
We now force the destruction of the header/footer nodes manually.
We also cut the redo chain which loses the redo history, but solves
another crash for now (when redoing the creation of the header).
The proper solution would be to create a new SwUndo* derived class
from scratch to represent the creation of a new header/footer section
in the document.
Regression from commit 8d8486f43c1a8a51157bfc3e0b87090b05a9229e
(tdf#46561 sw: fix lost undo stack setting header/footer)
Change-Id: I97188aa8ded802bc6b6fa88ddd83a95c40de8bc3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114667
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
InsertOLE1Header() can either take its OLE1 presentation data (preview)
from OLE2 or from RTF (SwOLENode). The presentation data size we wrote
was incorrect in the OLE2 case case: nPresentationData is the RTF size,
nBytes is the actual buffer size.
In practice this made the embedded object non-editable in Word (when
trying to edit the RTF fragment).
This went wrong in commit 0d027abbc5609b096d2a954e77aa7354a55928ab (sw
reqif-xhtml export, embedded objects: take OLE1 pres data from rtf if
needed, 2020-09-02).
Change-Id: I89019202c9a8b40c1b9a21f611f1190fd50073a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114889
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3da5f4416f1833389691787d205a89f3005f746e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114773
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|