Age | Commit message (Collapse) | Author |
|
Change-Id: I72a5b6418812c74ac47e4ccc4e82ff2238ad7eb6
|
|
Adds initial support for style:overflow-behavior
According to OpenDocument-v1.3-part3 style:overflow-behavior can take
values of:
- "clip"
- "auto-create-new-frame"
This patch doesn't properly implement support "auto-create-new-frame",
only "clip".
If "clip" is set, TextClipVerticalOverflow is set to true, causing the
vertical overflowing text to be clipped.
"auto-create-new-frame" is treated the same as omitting the
style:overflow-behavior attribute, setting TextClipVerticalOverflow to
false.
Change-Id: Iea298f41fbf0cf18dc07f41788ba0b665515db8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150122
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150305
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Also adds a unit test that tests TextClipVerticalOverflow on
4 different scenarios.
Change-Id: I6232935765641c796046d90fe2207d67ae4b3eb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150107
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150237
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit d3daa7ed0361785d8667f726340538ada1607937.
It was added for T38690 and removed for T41585
There was no urgency to get T38690 out,
so these regression-prone patches
should not have been backported into to a stable product.
All of these patches are in master
and LO 7.4, so they will be part of 23.05 already.
So T38690 is solved still in 23.05.
Change-Id: I113fb13ea9ca62f63d6e74a0da77108ba32cc440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150296
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit d4b87c11b451cb08aa950e09efed3cc6fa1422f3.
It was added for T38690 and removed for T41585
Change-Id: Ifc3fed831dc321f4b27cff295037b525768e3e55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150295
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-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>
|
|
This reverts commit 341e397d970d10281fbc9691874b4441a841837d.
It was added for T38690 and removed for T41585
Change-Id: I39cd0711047a131a3d60106b8682097411318781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150293
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 044c63c631f0af832aa8452bc4a8b0b38dc91c23.
It was added for T38690 and removed for T41585
Change-Id: I0010c40e486843e942fb958982e60ea92fddbb3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150292
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 d981737bcebf825949cd8b13c2c609a109abc984.
It was added for T38690 and removed for T41585
Change-Id: Iae7f0f273f81f050a2fbfa589451e6039a1a2193
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150291
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 0cb370d02bebf6a9d65b5852815e2c617b33a89a.
It was added for T38690 and removed for T41585
Change-Id: I2a019d739f91d9aef2765ee5142825da7ca09a32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150290
Reviewed-by: Justin Luth <jluth@mail.com>
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>
|
|
This reverts commit d506ca99d9ecbedadc7d6a83669313eca78768c0.
It was added for T38690 and removed for T41585
There was no urgency to get T38690 out,
so these regression-prone patches
should not have been backported into a stable product.
All of these patches are in master
and LO 7.4, so they will be part of 23.05 already.
So T38690 is solved still in 23.05.
Change-Id: I0deb4ba8ee09645957e51c930e1052f47050f0da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150286
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Otherwise, the condition color scale the priority order will be lost.
<conditionalFormatting sqref="G1:G5">
<cfRule type="colorScale" priority="5">
<colorScale>
<cfvo type="min" val=""""/>
<cfvo type="max" val=""""/>
<color theme="5" tint="-0.249977111117893"/>
<color rgb="FF92D050"/>
</colorScale>
</cfRule>
</conditionalFormatting>
<conditionalFormatting sqref="G1:G5">
<cfRule type="colorScale" priority="1">
<colorScale>
<cfvo type="min" val=""""/>
<cfvo type="max" val=""""/>
<color theme="0" tint="0"/>
<color theme="0" tint="0"/>
</colorScale>
</cfRule>
</conditionalFormatting>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I33fa73bfe8f0bada1cf79bc07be2e43495a4290c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149721
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Otherwise, the empty conditional format will exists.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I99d83bd50ce4c12ef9be6924cba31b8847c0ad07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149720
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
The </cfRule> tag is a good place to do a post check
the conditional format sanity.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Id6e99c81011040ec47034e993490fae5c71d7e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149719
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I115c3731db85267d115efd24739470bffaeace40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149718
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Introduces editeng text property TextClipVerticalOverflow.
Which when set causes vertical text that is overflown out of a
frame/shape truncated. (Only when text isn't being edited)
This is implemented as two steps:
(if text overflows)
1 - Vertical adjust is forced to top.
(Forcing vert adjust to top isn't the desired behavior normally,
but good enough for a first cut I'd say.)
-> The desired behavior would be after the overflown text is
truncated, doing a vertical adjust (of center/bottom/top) on
that piece of text.
2 - ClipRange is set to the height of the frame/shape.
This appears to work with different text directions too (vertical
etc.).
Change-Id: I697715a7d28bde94a6650609b16505ffab92173f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150106
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150236
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
this is followup for 6f56317
Change-Id: I87227b3e665a6d15378ee294556bcd2f95801e6b
|
|
and share similar code
Change-Id: I7729a46d40845893f577c273c1ab340f69ebb51b
|
|
This reverts commit 67fcd647341118747a4e7cd404d907d29613778c.
Signed-off-by: Gökay Şatır <gokaysatir@collabora.com>
Change-Id: I9d0652df63ab7ce9b220aff37008b18d8d511a03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149138
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
The auto-fit algorithm has been tweaked to be more in-line with
the expectations of OOXML. This means a couple of changes to what
properties are scaled by the algorithm have been made:
- most properties that influence the X axis position or size (for
example indent) are not scaled down or changed by scaling.
- properties that influence y axis position and size are scaled
by a separate parameter (like in the OOXML). This is used in the
auto-fit algorithm in a different way.
- if line spacing is proportional, it is now scaled with the
spacing parameter. Fixed line spacing doesn't get scaled.
- the main scaling X,Y parameter only scales the fonts.
- trying hard to scale the fonts to the nearest pt (point) value
With this change the scaling is much more stable than it was
before - for example it doesn't matter what the unscaled font
size is, when it is scaled down to the text box size, it (should)
always look the same (for example scaling from 32pt -> 10pt or
64pt -> 10pt or even 999pt -> 10pt).
The algorithm is also rewritten to be better at finding a fit and
is also better at find a good fit, but it can take more iterations
by doing so (there are ways to improve it however). Previous
algorithm used a linear search to converge to the best fit in less
iterations, but the issue with that was that it could in some cases
miss a solution (especially since change to floating point scaling
parameter). The new algorithm now uses a binary search - always
trying the middle of the search space.
OOXML export and import was also changed to take advantage of the
font scaling and spacing scaling parameters. The additional
scaling at export that was needed to have consistent OOXML support
was removed.
Change-Id: I8f3bb8d43a01931f18bd7ffdf8e0ba40caa73d8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149207
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149934
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: If304f12e1f1fbe3afea4885975302b77b428567f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142187
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149933
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
As we converted the chart stretching variable from int to double
this can cause the text fitting algorithm to calculate the fit
wrong. This commit changes the text fitting algorithm a bit so
that it produces similar result as before the change.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142186
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Change-Id: Idac1da3624799b6950ed356e9c76fc4f037f900e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149932
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This changes the nStretchX and nStretchY from sal_uInt16 to double
so the text in text boxes is rendered correctly (text should be
resized to the same size as the textbox).
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142064
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Change-Id: Ifdf2481ddbaac0e9cf62a6ddf8a83984be134855
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149931
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
In the RTL case, the positive X axis is changed from
right to left, otherwise the auto fill rectangle overlay
will get negative coordinates.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: If4918f02d185fc19e5ab4e8a273c443c69dc7206
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150034
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: I24df1a42b1d3e991a430cf0ca25e9dc53b4bbff2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150048
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
The problem was that a reference to the bookmark name
was failing - since the move was adding a "Copy 1" at the end.
That rename line is very deceptive because AFAICS it fails every time.
I'm going to look at removing it in a followup commit.
Two other unit tests also found with make sw.check
-tdf149089.docx
-tdf149507.docx
but they also didn't have references to the bookmark to visually notice.
make CppunitTest_sw_ooxmlexport10 CPPUNIT_TEST_NAME=testTdf92157
Change-Id: Idd695ec4a89057b28a68bc051b73f17fd4c3de56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149574
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/+/149641
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149766
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.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>
|
|
Change-Id: I75efe25ce6562677d5078666d28846423619c727
|
|
<x14:dataBar maxLength="100" minLength="0" border="1" axisPosition="automatic" direction="context" negativeBarBorderColorSameAsPositive="0">
<x14:cfvo type="num">
<xm:f>0</xm:f>
</x14:cfvo>
<x14:cfvo type="num">
<xm:f>1</xm:f>
</x14:cfvo>
<x14:fillColor rgb="FF63C384"/>
<x14:borderColor rgb="FF63C384"/>
<x14:negativeFillColor indexed="2"/>
<x14:negativeBorderColor indexed="2"/>
<x14:axisColor indexed="64"/>
</x14:dataBar>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Ib57dac07027e2c3c01ee556a3df791f49637be54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149346
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
does not exist:
<x14:cfRule type="dataBar" priority="1" id="{006000A4-0067-40D4-A5EF-00D900B80077}">
<x14:dataBar maxLength="100" minLength="0" border="1" axisPosition="automatic" direction="context" negativeBarBorderColorSameAsPositive="0">
<x14:cfvo type="num">
<xm:f>0</xm:f>
</x14:cfvo>
<x14:cfvo type="num">
<xm:f>1</xm:f>
</x14:cfvo>
<x14:fillColor rgb="FF63C384"/>
<x14:borderColor rgb="FF63C384"/>
<x14:negativeFillColor indexed="2"/>
<x14:negativeBorderColor indexed="2"/>
<x14:axisColor indexed="64"/>
</x14:dataBar>
</x14:cfRule>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Ie2c1ba2c85d9eead963f4d9b1684d72b64fe815d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149345
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
The ScDataBarFormatData should update from import (finalizeImport)
before cloning, otherwise it loose data.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I4af8b79e93eed8091bf01244bacac1d12e591c45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149344
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
conditional format:
<x14:cfRule type="containsText" priority="3" text="Done" id="{00730073-0059-47BC-840A-00E100CE00F2}">
<xm:f>NOT(ISERROR(SEARCH("Done",C1)))</xm:f>
<x14:dxf>
<font>
<color rgb="FF006100"/>
</font>
<fill>
<patternFill patternType="solid">
<fgColor rgb="FFC6EFCE"/>
<bgColor rgb="FFC6EFCE"/>
</patternFill>
</fill>
</x14:dxf>
</x14:cfRule>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I4da117a1a122b3895788645dcd5de3e36cdcad0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149343
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
<x14:dataBar maxLength="100" minLength="0" border="1" axisPosition="automatic" direction="context" negativeBarBorderColorSameAsPositive="0">
<x14:cfvo type="num">
<xm:f>0</xm:f>
</x14:cfvo>
<x14:cfvo type="num">
<xm:f>1</xm:f>
</x14:cfvo>
<x14:fillColor rgb="FF63C384"/>
<x14:borderColor rgb="FF63C384"/>
<x14:negativeFillColor indexed="2"/>
<x14:negativeBorderColor indexed="2"/>
<x14:axisColor indexed="64"/>
</x14:dataBar>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Ie98507e11a5cdeb0d1adc77a44fd79edb2f26d6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149342
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
<x14:dataBar maxLength="100" minLength="0" axisPosition="automatic" direction="context" gradient="0" negativeBarBorderColorSameAsPositive="0">
<x14:cfvo type="autoMin"/>
<x14:cfvo type="autoMax"/>
<x14:fillColor rgb="FF638EC6"/>
<x14:negativeFillColor indexed="2"/>
<x14:axisColor indexed="64"/>
</x14:dataBar>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: If7f6c8c902e4cd0d775f1014acad3dcd19f13f28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149341
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
To fill the positive color of the conditional format data bar:
<x14:dataBar maxLength="100" minLength="0" axisPosition="automatic" direction="context" gradient="0" negativeBarBorderColorSameAsPositive="0">
<x14:cfvo type="autoMin"/>
<x14:cfvo type="autoMax"/>
<x14:fillColor rgb="FF638EC6"/>
<x14:negativeFillColor indexed="2"/>
<x14:axisColor indexed="64"/>
</x14:dataBar>
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I17e83a01affff292ff941d92f6ae59954aa246ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149340
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
In some cases the text box wasn't properly moved afeter it's position
had been calculated. Also now when the shape and text element are
brought together in the Z ordering, the one with higher Z moves down.
Change-Id: I0512db4b6466532b5af4e3c091fd65bd0a416381
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149221
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 826b20b049449c9c335ce00c781cdb52e4ee0512)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149305
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
If bottom and top insets set so that the bottom edge of the resulting
text area is above the top edge, then LO and MS Office behave different
in how this is rendered. With commit e2169886 insets are converted on
import to make rendering in LO similar to MS Office, but the
implemented export has some problems, see analysis in bug report.
LibreOffice normalizes the resulting text area in case bottom edge is
above top edge. So this patch exports the insets so, that MS Office
gets a normalized resulting text area and will not apply its special
rules.
A roundtrip starting with pptx will not regenerate the old values but
will produce inset values, which give same rendering in MS Office than
in LO. Because the method is different now, the inset values have
changed and test testTextDistancesOOXML_Export is adapted. When you
compare the result with the screenshot on slide 2, you see that the
new method works as well.
The old method did not work for exporting an odp file. That is covered
by the new unit test. The docx unit test file covers the case, that
the export tweak was erroneously triggered.
Change-Id: I0091f284d9bdd635dd87ddb9e9b0e415cc0cc51e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142185
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
(cherry picked from commit 933768ffcd8617942f45481de77e656ded9dcfe2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142265
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 59b44e72f46021c070095a75a0d7e0ae12c43399)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149187
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.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>
|
|
Apparently 8.0.0 had a serious regression.
Change-Id: Icc761f5e5e01b5d9bebecc13f7cba608f5834f54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149212
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Fixes CVE-2023-27535.
Also hopefully fixes excessive storage consumption during build:
o build: drop the use of XC_AMEND_DISTCLEAN [62]
Change-Id: I8792e95bc7634ee496488e80fec5a1310b24a31c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149153
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149211
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Add the static libraries that are required by the LibreOffice's
CTL and CJK text layout features to the iOS app add link list.
Reference-to: https://github.com/CollaboraOnline/online/issues/6050
Change-Id: I21fddbfd29a1d326b509840127bd136c327cd3d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149210
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit 8b1e20c164e11689894ca605735541fad9aea3b1.
Reason for revert: This is for 23.05 branch.
Change-Id: I6fc584ba063d9013e7cb5b05438b51a9169149df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148956
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
E.g. a checkbox content control was turned into a rich text one on
copy&paste, so toggling didn't work on the copied content control.
(cherry picked from commit c804c5354855188b5a37219cfe11dc079dc235f4)
Change-Id: Ia7262e0b88dff12a2f87acd7b0e6cc3fbde3c3a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148836
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When another app owns the current clipboard contents, pasting
will display a "allow or disallow" dialog. If the disallow
option is selected, the data from the UIPasteboard will be
garbage and GetLOKNotifier() will return a nullptr. Since calling
SetLOKNotifier() with a nullptr aborts in an assert(), fix the
crash by failing gracefully.
Also, throw an exception if the -[UIPasteboard dataForPasteboardType:]
returns nil. By throwing an exception, the "allow or disallow"
dialog will display again the next time the user tries to paste.
Change-Id: I05d689b679a7643a8478e3ce0f416205fdf8ec23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148655
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Trying to save a document within the lifetime of the
cached connection, e.g. re-save within a few seconds after
the first and successful save failed with an error message
in the case of Vibe 4.0.6 WebDAV server. Waiting 5-10 seconds
after the last try was the only workaround to re-save the
document.
Details: aDAVOptionsException in Content::getPropertyValues()
removed the isClass1 bit of the cached DAVOptions of the
same TargetURL (note: of the folder of the WebDAV document).
This disabled the DAV detection part of Content::getResourceType(),
and later the correct HTTP redirect for the DAV connection.
Fix this by keeping the cached bit in that case, too, when the
added connection has a different lifetime, than the cached one.
Follow-up to commit 30ca48f4dc0e65a3798e6b21574bc80f6d4953fa
"tdf#152493 ucb WebDAV: fix upload using HTTP 1.0 fallback".
Change-Id: I5d4578232581a4df654f76198fdddf096cba5267
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147570
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit d6182cb6704c06f33d284874b9fe96c85cce5bf5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147606
Tested-by: Jenkins
|
|
adding upstream patch that uses __umulh as a fallback
Change-Id: Ib95de30d3f7208c38421df0c63eb1ceafccd9354
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146839
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
(cherry picked from commit 821f4d6f0987450233e4f63e01f89484ec737258)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147228
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit b22446cc1788c1861ea5a8cc5b227f983ea71f8f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147361
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Fixes CVE-2023-0286 CVE-2023-0215 CVE-2022-4450 CVE-2022-4304
Change-Id: I93ce0362b17bd07b0644564a0676daaa56bc8b50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146653
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: Ic0f1fca7ef73b3a443c24d2bcc7f234be331a05b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142184
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|