Age | Commit message (Collapse) | Author |
|
Change-Id: I5497c9b1f236bc803529825ba8b423d55fffa93e
Reviewed-on: https://gerrit.libreoffice.org/38049
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
There is a reason this is off by default, make it a bit more easier for
users to not depend this option when they don't actually need it.
Change-Id: I21c5b942c6021fa21840779e1a9f53055fbf279f
Reviewed-on: https://gerrit.libreoffice.org/38081
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
With this finally the bugdoc has no more unexpected white lines around
the fly frame. In the non-SubtractFlys case DrawFillAttributes() already
did an expansion of the clip path, but this was overwritten in case the
layout flag was set.
Fix the problem by taking care of this in lcl_SubtractFlys() itself.
Change-Id: Iac91279f8bc19588e763425aff5cb800e793da83
Reviewed-on: https://gerrit.libreoffice.org/38079
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
In case the intention is that the clip rectangle should include the
page, except a fly frame, we built a list of rectangles that covered
this area. This introduces the problem if adjacent rectangles don't join
perfectly.
Instead allow lcl_SubtractFlys() to work on a clip state directly, this
way the clip polypolygon will only contain two paths (the page rectangle
and the rectangle of the fly), so rounding errors can't happen.
Change-Id: I5b2e9a382aa7d16f3b16509670de754b5e00bd6d
Reviewed-on: https://gerrit.libreoffice.org/38066
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
If in Writer dragging the anchor is already active
it is not allowed to enter global object drag mode.
This check was missing and may lead to various
inconsistencies
Change-Id: I7d8dd2a62737e6d5d72f69747ceb21bcb73c45ed
Reviewed-on: https://gerrit.libreoffice.org/38059
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Change-Id: I697e9c7772792b02257ed1f40666dd70bb70300c
|
|
should this be pShell instead of pSh ?
Change-Id: Ie653dbbdee8cebc402c9ee9e78630353ba977921
|
|
Change-Id: I1430ac41bf11bf3ae5c4cba3406a24148acd728e
|
|
The presence of an annotation anchor was causing number replacement
to fail in Writer's table cells. The formula's value was not
recognized as a replaceable number, so the originally computed
value remained in the cell, regardless of whether the formula's
value changed.
Allowing the value to change needs to avoid losing the comments,
so the majority of this fix is to preserve the comments.
This is not recognized as "fixed" during document loading since
the table/formulas are not refreshed at load time.
Only documents saved with incorrect results will notice this,
and any cursor access inside the table will cause a refresh.
Printing also causes a refresh (but not print preview or PDF export).
So this patch only fixes document creation or modification, which
should be adequate for this bug.
Change-Id: I6f11d62c2d56e6b0f6a37371dd5aaef28d525e25
Reviewed-on: https://gerrit.libreoffice.org/32910
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I152def3c629980aedb705ac511f154cc6e9d1b0f
|
|
Before patch:
Document created in MS Word:
<v:shapetype id="_x0000_t136" o:spt="136" ...>
<v:shape type="#_x0000_t136" ...>
Imported to LO and exported:
<v:shapetype id="shapetype_136" o:spt="136" ...>
<v:shape type="shapetype_136" ...>
Then again imported to MS Word and exported:
<v:shapetype id="shapetype_136" o:spid="_x0000_m1026" o:spt="100" ...>
<v:shape type="#shapetype_136" ...>
In this moment LO after import had shape in the navigator but it wasn't visible.
Patch:
* vmshapecontext.cxx is changed to read ShapeType from id instead of o:spt
when o:spid is present.
* vmlexport.cxx added o:spid for Word to identify inserted watermark
* edfxol.cxx changed name of shape to "PowerPlusWaterMarkObject" for Word
* tests
Change-Id: I25322628838a98c45cbeed64144d04977b2ea9ba
Reviewed-on: https://gerrit.libreoffice.org/37969
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ie7182fa30155a8090421cf9a669525be99f0e0a7
Reviewed-on: https://gerrit.libreoffice.org/38042
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
See commit c5cf8824a619401627f18abc7b3049551c71ac2a (tdf#86578: sw: fix
rendering of legacy documents with fly anchored at fly, 2015-04-10) for
the context, this fixes the vertical unexpected thin white lines of the
bugdoc.
Change-Id: I5bb0536e84a8486440748ac9ebb24b22344cc03f
Reviewed-on: https://gerrit.libreoffice.org/38015
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I8af4753cc654ec475d40223a64afa50a9de332ab
Reviewed-on: https://gerrit.libreoffice.org/38007
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|
|
This fix reverts commit 304d3856c138fb54ff536f41be3eff26ab4d6315
Date: Wed Oct 16 07:55:09 2002 +0000
#103124# possible unremoved SwFmt object fixed
and commit fab98924e01f211c1d1fc5823c0867019b590c60
Date: Wed Oct 16 10:18:26 2002 +0000
#103152# possible unremoved SwFmt object fixed
as they are causing crashes:
http://crashreport.libreoffice.org/stats/signature
/SfxItemPool::Put(SfxPoolItem%20const%20&,unsigned%20short)
The comments suggest there was/is a use-after-free when
SwFormatCharFormat is changed with API. This happens in unoobj.cxx
and unostyle.cxx by SwFormatDrop::SetCharFormat().
With following changes:
commit bf2ae97a223df987d6b9bc649afe311b5421f61e
INTEGRATION: CWS os7 (1.64.4.3.34); FILE MERGED
2003/03/25 14:23:43 os 1.64.4.3.34.1: #104245# table mode added
to the SwXTextCursor::SetPropertyValue attribute list; 'Standard'
character format not allowed as drop cap char style
and commit 9625366d0b2fd36a57c6283a4a80c47b80d57707
INTEGRATION: CWS os8 (1.64.4.3.48); FILE MERGED
2003/04/09 09:11:53 os 1.64.4.3.48.3: #104245# Default not
allowed as DropCapCharStyleName, too
in unoobj.cxx, setting the documents' default SwFormatCharFormat is
rejected by throwing an exception. Likely to fix the same issue as
the first 2 commits.
So we do the same in unostyle.cxx now too.
Add an assert in SwFormatCharFormat::SetCharFormat and
SwFormatDrop::SetCharFormat, to uncover other changes to the default
SwFormatCharFormat or SwFormatDrop.
Such an case could happen in SwXTextDefaults::setPropertyValue
where we bail out now.
Change-Id: Iac59dffbd6285dd28d1000a8eacda8ffd3bdc962
Reviewed-on: https://gerrit.libreoffice.org/37499
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ieaf42384248deb283f71743f68c059b384abaa1a
|
|
regression from commit 890d6790715c4c3f3565b476d538643f04dc6936
"convert TableChgWidthHeightType to o3tl::typed_flags"
Change-Id: Ia1c3ec09d23ffe502dd8cb0ab673e45935bd4909
Reviewed-on: https://gerrit.libreoffice.org/37956
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I26db31b8f9db968aa33b92a4abe917ac20cd5844
Reviewed-on: https://gerrit.libreoffice.org/37963
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Ib6b98c58b1251c27476cbbbd03a2f7ed97e68c45
Reviewed-on: https://gerrit.libreoffice.org/37947
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I6058236434de00cddec1340613e83c10acc4df2a
|
|
Change-Id: Ic18b85070bf6c5c3e9678859a87cb9f44411533b
|
|
teach it to look for the following sequence in a destructor:
delete m_pfoo;
m_pfoo = nullptr;
Change-Id: Icd6271a63a024e32b53cc9e599f8f59952160380
Reviewed-on: https://gerrit.libreoffice.org/37900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idb8241c3b55d0dfaf8338abd9ab601632ac16147
Reviewed-on: https://gerrit.libreoffice.org/37727
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>
|
|
Change-Id: Ief6faa2d31e33964fdc78cb83f215861e4337eac
Reviewed-on: https://gerrit.libreoffice.org/37565
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Fifth set of translations.
Change-Id: If78542839ffeef3d48d01cf64727db2ada206e14
Reviewed-on: https://gerrit.libreoffice.org/37606
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
The unit test should only be ensuring that the footnote is actually
written in the footnote section. The fix had nothing to do with the
style of the footnote.
Change-Id: I209f1f0a8cf896916eaf7e8002c92085926b508b
Reviewed-on: https://gerrit.libreoffice.org/37907
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
The unit test should only be ensuring that the drawing is in
the footnote, not that it is located in the 5th character portion.
Change-Id: I58040dc3498b2e78000891a26b7188dfac6c72f7
Reviewed-on: https://gerrit.libreoffice.org/37906
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
MSO uses half-pt values in this field as the
minimum font pt size to start kerning at.
Although kern=1 enables pair kerning in MSO, it seems to be an
invalid number, and so is interpretted to enable kerning at
the default value of pt 11. So kern=1 is the same as kern=22.
Setting kern=2 seems to be the minimun allowed value,
enabling kerning for fonts size 1 and above.
Likely, kerning small fonts doesn't look good, so the current value
of 1 enables it for the default font size. However, if someone
intentionally wants to kern a smaller font, then we will be
incompatible, and also any documents with smaller fonts authored in LO
will not be identical. As always, when the two applications have a design
incompatibility, a decision will need to be made one way over another.
Switching to enabling kerning at ALL font sizes, thus matching native LO
handling, and so that any documents that are edited in LO look the same
in MSO.
This change will ONLY affect MSO's rendering of documents
round-tripped by LO. It will not be noticed in LibreOffice itself.
Change-Id: I73c46f3f120221b7b194480145b9150929d3d9a3
Reviewed-on: https://gerrit.libreoffice.org/37800
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I975ffa6834d1f39fa9e005aec247d350139e2208
Reviewed-on: https://gerrit.libreoffice.org/37897
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I56228b3f120df5cad53d721715b977f8131efdc8
Reviewed-on: https://gerrit.libreoffice.org/37885
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I50fd6be6a5f1473a34c1d7f930143705c2003fd1
Reviewed-on: https://gerrit.libreoffice.org/37736
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com>
|
|
Change-Id: Id31273b2a203414f8ad4f827c334ae17689560af
|
|
Change-Id: I08c7981ecce45e343ff9e98277dd3aea4ed68ab9
Reviewed-on: https://gerrit.libreoffice.org/37860
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1557af6563f9dfab03cca5696b4622ae18b805d4
Reviewed-on: https://gerrit.libreoffice.org/37856
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Double quote to prevent globbing and word splitting.
Change-Id: I09faac27ca5c63a85b9b8cbd4f09821587bf4759
Reviewed-on: https://gerrit.libreoffice.org/37545
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
but keep exception includes in headers for now
Change-Id: I826828675a2d14b906e57068cbced2e790e12bce
Reviewed-on: https://gerrit.libreoffice.org/37846
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I92f99f46c1e2940a67b34f772e668827e803619e
|
|
Change-Id: If3dc2082e24760f68598dc718c32d3008fdf6eba
|
|
* it is possible to set font family,
color, angle and transparency
Change-Id: Idea2fb9ee748394bb3d706fa790e109238584cdb
Reviewed-on: https://gerrit.libreoffice.org/37793
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Commit e75057a4d79d96464ff7ddd1511641b23757a502 caused the
Style Presets category to become empty in the Design sidebar
of Writer.
Change-Id: I96353ddd7619b8b845286f0ec5a27aed5fac99fb
Reviewed-on: https://gerrit.libreoffice.org/37732
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Otherwise the UNO API user can only see this image has a replacement,
but not possible to say if it's an SVG or a PDF image.
Change-Id: Ibde7915e02620acecbbb237dc3b333382d9c784a
Reviewed-on: https://gerrit.libreoffice.org/37827
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I0a794e1d2a4b7e97133df0f7243817da7caaee1d
|
|
change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
MS documentation for splitPgBreakAndParaMark
only mentions page breaks, not column breaks.
(Always Move Paragraph Mark to Page after a Page Break)
This element specifies whether a page break shall automatically
complete the line on which it appears, moving
the end of the paragraph to a new line on the next page,
or if it shall behave as true run-level content within its
current paragraph.
Typically, a page break defined using the br element
is treated as run-level content, which means that
although it delimits the end of the page, if there is no content
after it within the current paragraph, that the
paragraph shall also end on that page. This element, when
present with a val attribute value of true (or
equivalent), specifies that a page break shall always
immediately end the current page, moving the paragraph
mark which delimits the end of its parent paragraph to
a new line on the next page.
Note that this setting only affects the case where there
is no run-level content after the page break within the
paragraph - if any further run content appears in the
paragraph it shall appear on subsequent lines on the next
page
I borrowed the !footnote code from the if newline ELSE
section. It seemed appropriate to take the same
precautions here.
|| bSingleParagraph was added specifically for
COLUMN_BREAK. That is obsolete now, so removing.
There is a lot of old code here that I have questions
about. I tried to change as little as possible, but
likely lots of the existing logic is just wrong.
Change-Id: Ib988c6623acb2b6152118098b706314bfbfb99e3
Reviewed-on: https://gerrit.libreoffice.org/36421
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
make it a little smarter in dealing with fields that are smart pointers
Change-Id: I44072105170882dc29fb19558f1065cffc7e5f11
Reviewed-on: https://gerrit.libreoffice.org/37751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The simple presence of a FontKern SPRM was assumed to mean
that kerning was enabled instead of reading the value
passed by the parameter. However, if the style's default
is to enable kerning, then SPRMs must indicate zero
in order to disable it in non-default formatting.
This commit will be food for reporting false regressions.
Just because text no longer fits in the space that it used
to doesn’t make this a regression. Don’t blame this commit
UNLESS the character or style’s “Position” “Pair Kerning”
setting is incorrect. In MSWord this is a “Font” “Advanced”
Kerning setting. This kern bug will have hidden lots of other
spacing related problems that are unrelated to this commit.
Related to tdf#105454 which did something similar for .docx.
Change-Id: Ie27b5a342ffc1431e1c5ee0a7b057fdb11e4e4e3
Reviewed-on: https://gerrit.libreoffice.org/37781
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ie32c69d0ec66006807adfc58ea956a8a0906d238
Reviewed-on: https://gerrit.libreoffice.org/37798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
This reverts commit 26a67002fcb9381b54de6cae1aaa37120d49066a. "Iff" is not a
typo, see 2a65bf32ec270484dcea4d22d3c93552dc0c24dd "Revert 'Typo: iff->if'".
|
|
Change-Id: Ib08cba9074eb6d8149eac518794178c4f72998f0
Reviewed-on: https://gerrit.libreoffice.org/37784
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Only replaced "iff" with "if"
Change-Id: Ib9dfa5c12b05500043147fe3b65f923b1b12a581
Reviewed-on: https://gerrit.libreoffice.org/37782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|