Age | Commit message (Collapse) | Author |
|
Change-Id: Ifc7e36aa1df56cf532b698c8671cabbb35061bac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119076
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Iae3eec214849676be51ded133c1ffd9cf2e56ef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119074
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
With CWS impress64 a partial fix for this was implemented to drop
unreferenced named items including all non-color fills after ODF import,
but this is only done in sd so move the code that does that to svx and
call it from sc and sw as well.
Implement some UNO interface for this, it's at least better than a magic
string, and not obvious how a better solution would look like since it's
known only at the end of the import if a bitmap is used or not.
Another problem: when the Area tab is used to change to a different kind
of fill, the items with the details for the previous fill aren't
cleared, and so they are written to ODF files. Hence bitmaps in the
file can be referenced even if they aren't actually used, and bloat up
the files.
Fix this by dropping all unused draw:fill-image-name attributes in ODF
import.
Also do the same for Gradient and Hatch fills; Transparency gradients
can be combined with anything so leave them as they are.
Change-Id: I0b591fd9f963d974d0c3e7208b99621ad61dd93c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118950
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Id8ca0d277f485347e21bd8d6d68de2a7de13de48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119060
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
no logic change intended
Change-Id: Ib0174f8040faa3efde7b9c5ba9b062bac5a35da3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118983
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Using plain lang::Locale.Language is always wrong, it may even be
'qlt' for a more complex language tag. As the InfoBar message is
"Please install the hyphenation package for locale “%1”."
actually use the BCP 47 language tag of that character/paragraph
attribution.
Spotted in
https://ask.libreoffice.org/en/question/280102/install-the-hyphenation-package-for-locale-ka/
https://ask.libreoffice.org/en/question/238764/error-message-reads-install-the-hyphenation-package-for-locale-zh/
Change-Id: I5805d4d711989a9d0260940666d3eb33eae830af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119020
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
In other places, there were caveats for applying a CR
when inserting instead of importing, or when in a header,
but none of those seem to apply in this case.
A section cannot occur in a table, and anytime a
section occurs, it ought to finish off the paragraph.
So a simple clause seems good enough here.
There were basically two different existing unit tests
that match this condition, and neither of them
were currently mis-handled. I safely adapted one of them
to imitate the error condition I was addressing.
Change-Id: Ie8ccd3978276bf10321e0bf80141572f40102874
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118819
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is off by default and it may be in for Word documents.
Change-Id: I5f694bb505c2b43bea67712a2076dc5f370d03b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118994
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This uncovered lots of pre-existing invalid ranges, e.g. introduced
in commit 6dbfbebad37fd84208e4c336f0864d26019db153, or in much older
commit 46952138c938730afcc3607e1a524bb590b0e30e.
Also this makes the static in svl::Items to be array of WhichPair,
to avoid questionable reinterpret_cast in WhichRangesContainer ctor.
Change-Id: I86030b2a2ac0a6d98870f8f7f5cc83e071c6597c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119003
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
just so we have one fewer odd constructors here
Change-Id: I81278e9436747a4eb46a33da9bfec7a8b30079b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118982
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
After setting the break and pagedesc property of a table, applying a table style (autoformat) caused the loss of these settings.
This was because, when applying a table style, the SwTableAutoFormat::RestoreTableProperties() overrid these settings with its own default settings.
As the autoformats can never be modified, and they don't really use these two props, the easiest way to prevent any problem was to completely remove these properties and its uses.
Unfortunately, m_aBreak couldn't be removed entirely, as the autoformats are stored in a binary file, and to be able to read and write these files the offset of the subsequent items must not be changed.
Change-Id: Ieba439d3ba5da892b39f00f8b61c5c8467306635
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118662
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
SfxItemSet shows up in perf profiles frequently,
and the hottest part is the malloc of the two arrays we need.
But most of the time, one of those arrays is a compile-time
constant.
So this change introduces
(*) WhichRangesContainer, which manages whether the SfxItemSet
owns the array it points at or not.
(*) a static const member in svl::Items (idea from mkaganski)
to store the data.
Change-Id: Icb8cdbc4d54fd76739565c575e16a744515e5355
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118703
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so that incomplete words are not added as autocomplete candidates even
if they form a legal word. This is similar to what we do for marking
words is misspelt
Change-Id: Ib6b209b68bbcf51fa24ea5c4d995579acf682e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118974
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Now it's used in RTF, DOC and DOCX import consistently.
Change-Id: I062a5fbbdf6ee0ef4d3c86a09ce50ac3d588fae5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118960
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See commit 0025e80ba6d882f6f885499efaf37ab0e2ed699d (sw: use
SfxPoolItem::StaticWhichCast() in SwTextBoxHelper, 2021-07-07) for
motivation.
Change-Id: Ifb3e2466dd25ad554b81cdac63742230072e64a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118952
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iac67ca026fd0463da67cef7838f9a36da04f3378
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118937
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
For DOCX, numId means turn off numbering.
RTF probably doesn't have numbering as part of paragraph styles,
so it doesn't need a numId 0 to cancel existing numbering.
This numbering is applied directly to the paragraph during import.
So, for RTF, numId 0 needs to be treated just like any other numId
(except for -1 through -5 although currently
we only import positive numbers).
The statement "if pList and numId > 0" is basically redundant.
pList will not be exist for an invalid numId.
Since numId can be zero for RTF, just get rid of the clause
to avoid any misleading conclusions.
And that is all that this patch is doing. It doesn't really fix
anything, it just changes code that gives out the wrong impression.
AFAICT, RTF never uses styles, and therefore it is always
isNumberingViaRule and so is almost untouched by finishParagraph.
Change-Id: Ibc89d00ce69ad09208254ed85710f1f1aed18074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118910
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I1985a377c9b299dce7d3e01d4e67099562008d22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118888
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
revert
commit 790135003b03b38a14efb7e0d345188607020a99
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed May 19 20:03:07 2021 +0200
fix leak when removing PageDesc
Change-Id: Ia6a03dec2db8f68c5c0c34d6ee9fb1889151f29d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118885
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we avoid having two copies of OWeakObject in it
Change-Id: I1c3de4873a25e9cfb1a4bf67c369d9ecce0129d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118854
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The current solution has some problems:
(1)
Currently effectExtent is used on import to increase the wrap margins
for fat stroke and effects like shadow and glow in case of contour
wrap.
Problems:
Word writes these values, but actually the wrap polygon is authorative
and third party applications might not write these values at all.
The wrap margins were increased on import, but not decreased on export.
The effectExtent values by Word contain in addition the amount for
rotation as needed in wrapSquare. That part was not removed.
(2)
To avoid negative values in dist* values they were compensated with
effectExtent. For that, the complete effectExtent was shifted to dist*
and effectExtent was set to zero.
Problems:
Contour wrap does not use effectExtent but a wrap polygon. This is set
by Word in a way, that it includes the effect extents. LO uses the
original wrap polygon if available. So moving the effectExtent values
to dist* gives too large 'distance to text' in case of contour wrap,
because effects were considered twice.
The solution here replaces the way, how the margins are calculated in
case of contour wrap. Now the range used by the wrap polygon is
compared with the range used by the shape geometry. The difference is
added to 'distance to text'. To be able to remove these values on
export, they are put into the InteropGrabBag.
LO and Word use different concepts for contour wrap. Any solution gives
only an approximation. But adapting 'distance to text' brings
rendering in LO nearer to the way Word renders contour wrap.
Change-Id: Ic3c1c075fedfa7f79e4fe1f3c095da12cf274e36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118538
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This really surprised me. On outline numbering, only one style
can use the level of a numbering rule. Any other style that
has it defined is ignored. First come first served.
[All based on experimentation, no documentation found.]
There are two ways the style can be attached.
The highest priority is if the numbering style itself has
a paragraph style defined (which obviously is exclusive).
The second way is just to assign a list level along
with a numbering rule in the para style.
Surprisingly, this too creates an exclusive lock on the level.
These are some existing unit tests that triggered.
I forget which ones are important or valuable,
but none of the contents were affected,
only the UI use of the style didn't apply numbering in Word:
Example1 -ooxmlexport6 fdo74605.docx RT
pStyle not written out for numbering.
List-number-2 gets ilvl0 before List-number-1,
and loses pStyle for absLevel 1
[NOT REALLY A PROBLEM.
That is also how Word sees it. These aren't chapter numbering,
so the pStyle settings just get dropped.]
Example 2 - ooxmlexport7 fdo76979.docx RT:
Bullet gets the numbering, but not Bullet2
Example 3 - ooxmlexport11 tdf101122_noFillForCustomShape.odt RT:
Heading 9 gets the numbering, but not Heading 10
[Typical LO-originating document.]
Example 4 - ooxmlexport13 tdf95848.docx RT:
Heading 1, so not Heading 2
Example 5 - ooxmlexport14 tdf136929_framesOfParagraph.odt RT:
OOoNum123Start, so not the others (who inherit from start anyway)
Change-Id: Ia27131ae6d31b6cff240477f3546ccf92ea69160
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118707
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
so we avoid having two copies of OWeakObject in it
Change-Id: Ia592f1d67a730da35c5d73c81c689d9da02fce1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118853
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Rejecting tracked empty row insertion, or accepting tracked
empty row deletion didn't remove the line from the table.
Regression from commit c4cf85766453982f1aa94a7f2cb22af19ed100be
"sw: fix crash due to redlines on tables on ooo121112-2.docx".
Note: as a workaround for the empty rows, i.e. rows without
text content, add a redline with invisible text ZWJ in the
first cell of the empty row.
Follow-up to commit 03b29d4ddb99337c4d54b241020c95e8b2a66991
"tdf#143278 DOCX: support tracked table (row) insertion",
commit 05366b8e6683363688de8708a3d88cf144c7a2bf
"tdf#60382 sw offapi: add change tracking of table/row deletion"
and commit 896c2199d9f0a28bd405dd2d1068f5e2973cdf06
"tdf#79069 DOCX: support tracked table (row) deletion".
Change-Id: I8616a9d6f4a8d21e88c55d935f14a8c6a73c28ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118839
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
It was failing for me on Linux and another person on Windows, going
1 twip over the tolerance. 30 twips translates to 2 pixels in 96 DPI.
Change-Id: Ide9a29fdf3f2b4929408eb6d0d7a0792e927bb95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118778
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Rejection of tracked table insertion didn't remove
the table from the text, leaving an empty table at the
place of the insertion.
Regression from commit c4cf85766453982f1aa94a7f2cb22af19ed100be
"sw: fix crash due to redlines on tables on ooo121112-2.docx".
Follow-up to commit 05366b8e6683363688de8708a3d88cf144c7a2bf
"tdf#60382 sw offapi: add change tracking of table/row deletion"
and commit 896c2199d9f0a28bd405dd2d1068f5e2973cdf06
"tdf#79069 DOCX: support tracked table (row) deletion".
Change-Id: I4c7242c432d1ad329a56a9a5423aa68fd7f94420
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118773
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Commit d6322bcedc197a654abc7d64bfea8cf570f123bf
(tdf#59463 track changes: record deletion of images) converted
image anchors to AS_CHAR, which resulted loss of the original
layout during rejecting the tracked image deletion.
Now keep the original AT_CHAR (also AS_CHAR) anchorings, also convert
the AT_PARA and other anchoring types to AT_CHAR using the following
workaround: add an invisible text-based anchoring point with ZWJs.
Follow-up to commit 8726cf692299ea262a7455adcf6ec25451c7869d
(tdf#142700 DOCX: fix lost track changes of images).
Change-Id: I29d1e161b5f24c0fed51d40c9a8db82085918d0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118747
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I2ec92c229fcb6d38fd78c520a48d0bd3b739a82e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118542
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...in export to docx.
Rotated child elements need a correction to the position values,
because LO uses left/top of snap rectangle as position, but Word uses
left/top of unrotated shape. For the group itself it is done in
DocxSdrExport::startDMLAnchorInline. But child elements' position
is exported in DrawingML::WriteShapeTransformation. And there this
correction was missing.
Position is relative to anchor in Writer and relative to group in
Word. The adaption is contained in WriteShapeTransformation. But
PolyPolygon and Connector have no explicit rotation and therefore they
do not use DrawingML::WriteShapeTransformation but call directly
DrawingML::WriteTransformation. So they missed this adaption. I have
added the adapation directly to these shapes.
Unittest testDmlTextshapeB in sw-ooxmlexport6: I have adapted the
values. The position of the connectors relative to the group is better
now. You see this, if you compare it with a screenshot of the original
file in Word. The handles of the connectors are still wrong and the
whole group is still shifted.
The patch does not fix the wrong position of rotated legacy ovals,
because that error exists independent of groups.
Change-Id: Iaf843dcf04bac596427dd35ccfa6cd20e3a4cdc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118748
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
like Writer for DOC import and MSO do to avoid to start
endnotes on a new page.
Change-Id: I37d54f189e7aa1f4d0ac829b6af0c03aec64b9f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118541
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
don't create when a drawing is selected, wait until its actually dropped
into something (I experimented with dropping into gimp)
Change-Id: I3edaf79537d5723565adf8c45d6f7408026a93e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118770
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7cd54cbbea55b7a7fd64597c48407629f10cddd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118790
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
in:
sw/source/core/text/itrform2.cxx:2643 SwTextFormatter::NewFlyCntPortion
at: pFly = static_cast<SwTextFlyCnt*>(pHint)->GetFlyFrame(pFrame)
(gdb) print m_pCurr
$2 = (SwLineLayout *) 0x55ea220a0020
after calling GetFlyFrame m_pCurr is unchanged and we will call
m_pCurr->MaxAscentDescent
on it.
But m_pCurr is deleted during GetFlyFrame by...
#18 0x00007f98c5cd337f in SwLineLayout::~SwLineLayout() (this=this@entry=0x55ea220a0020, __in_chrg=<optimized out>)
at source/libo-core/sw/source/core/text/portxt.hxx:26
#19 0x00007f98c5cd347a in SwParaPortion::~SwParaPortion() (this=0x55ea220a0020, __in_chrg=<optimized out>)
at source/libo-core/sw/source/core/text/porlay.cxx:2491
#20 0x00007f98c5cd3485 in SwParaPortion::~SwParaPortion() (this=0x55ea220a0020, __in_chrg=<optimized out>)
at source/libo-core/sw/source/core/text/porlay.cxx:2491
#21 0x00007f98c5d05e70 in std::default_delete<SwParaPortion>::operator()(SwParaPortion*) const (__ptr=<optimized out>, this=<optimized out>)
at /usr/include/c++/8/bits/unique_ptr.h:75
#22 0x00007f98c5d05e70 in std::unique_ptr<SwParaPortion, std::default_delete<SwParaPortion> >::reset(SwParaPortion*)
(__p=<optimized out>, this=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:382
#23 0x00007f98c5d05e70 in SwTextLine::SetPara(SwParaPortion*, bool) (bDelete=true, pNew=0x0, this=<optimized out>)
at source/libo-core/sw/source/core/text/txtcache.hxx:45
#24 0x00007f98c5d05e70 in SwTextFrame::ClearPara() (this=this@entry=0x55ea21302b60) at source/libo-core/sw/source/core/text/txtcache.cxx:113
#25 0x00007f98c5d1be89 in SwTextFrame::Init() (this=this@entry=0x55ea21302b60) at source/libo-core/sw/source/core/text/txtfrm.cxx:757
#26 0x00007f98c5d2630c in SwTextFrame::Prepare(PrepareHint, void const*, bool)
(this=0x55ea21302b60, ePrep=PrepareHint::FlyFrameArrive, pVoid=<optimized out>, bNotify=<optimized out>)
at source/libo-core/sw/source/core/text/txtfrm.cxx:3086
#27 0x00007f98c5b1edb8 in SwFlyInContentFrame::NotifyBackground(SwPageFrame*, SwRect const&, PrepareHint)
(this=<optimized out>, rRect=..., eHint=<optimized out>) at source/libo-core/sw/inc/anchoredobject.hxx:205
#28 0x00007f98c5b261a6 in Notify(SwFlyFrame*, SwPageFrame*, SwRect const&, SwRect const*)
(pFly=pFly@entry=0x55ea21a18d60, pOld=0x0, rOld=SwRect = {...}, pOldPrt=pOldPrt@entry=0x7ffeb50390f8)
at source/libo-core/sw/source/core/inc/frame.hxx:1177
#29 0x00007f98c5b2ceca in SwFlyNotify::~SwFlyNotify() (this=0x7ffeb50390d0, __in_chrg=<optimized out>)
at source/libo-core/sw/source/core/layout/frmtool.cxx:648
#30 0x00007f98c5b1fa25 in SwFlyInContentFrame::MakeAll(OutputDevice*) (this=0x55ea21a18d60)
at source/libo-core/sw/source/core/inc/frmtool.hxx:419
#31 0x00007f98c5aec3a9 in SwFrame::PrepareMake(OutputDevice*) (this=0x55ea21a18d60, pRenderContext=0x55ea212bc4c0)
at source/libo-core/sw/source/core/layout/calcmove.cxx:375
#32 0x00007f98c5b17ad2 in SwFlyFrame::Calc(OutputDevice*) const (this=<optimized out>, pRenderContext=<optimized out>)
at source/libo-core/sw/source/core/layout/fly.cxx:2890
#33 0x00007f98c5b636c5 in SwObjectFormatter::FormatLayout_(SwLayoutFrame&) (this=this@entry=0x55ea2244d150, _rLayoutFrame=...)
at source/libo-core/include/rtl/ref.hxx:206
#34 0x00007f98c5b6413e in SwObjectFormatter::FormatObj_(SwAnchoredObject&) (this=this@entry=0x55ea2244d150, _rAnchoredObj=...)
at source/libo-core/sw/source/core/layout/objectformatter.cxx:296
#35 0x00007f98c5b6705b in SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool)
(this=0x55ea2244d150, _rAnchoredObj=..., _bCheckForMovedFwd=<optimized out>)
at source/libo-core/sw/source/core/layout/objectformattertxtfrm.cxx:136
#36 0x00007f98c5b6359f in SwObjectFormatter::FormatObj(SwAnchoredObject&, SwFrame*, SwPageFrame const*)
(_rAnchoredObj=..., _pAnchorFrame=<optimized out>, _pPageFrame=<optimized out>)
at source/libo-core/sw/source/core/layout/objectformatter.cxx:190
#37 0x00007f98c5d717aa in SwTextFlyCnt::GetFlyFrame_(SwFrame const*) (this=this@entry=0x55ea214d8810, pCurrFrame=pCurrFrame@entry=0x55ea21302b60)
at source/libo-core/sw/source/core/inc/frame.hxx:1177
#38 0x00007f98c5cb511b in SwTextFlyCnt::GetFlyFrame(SwFrame const*) (pCurrFrame=0x55ea21302b60, this=0x55ea214d8810)
at source/libo-core/sw/inc/txtflcnt.hxx:48
#39 0x00007f98c5cb511b in SwTextFormatter::NewFlyCntPortion(SwTextFormatInfo&, SwTextAttr*) const
(this=this@entry=0x7ffeb503a6b0, rInf=..., pHint=0x55ea214d8810) at source/libo-core/sw/source/core/text/itrform2.cxx:2643
(gdb) print this
(SwLinePortion * const) 0x55ea220a0020
The SwTextFrame of SwTextFrame::ClearPara is the same pFrame/m_pFrame at SwTextFormatter::NewFlyCntPortion
ClearPara is not called if the SwTextFrame is "Locked", so try using that to protect GetFlyFrame
Change-Id: Ia9dcb1f345f6953d995f2acf1ec23492d1680364
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118784
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1e17e43bfe4a18034e9c0ff483097fe6ca0e777a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118782
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
seems
commit 4a93efcf6e7982146fb71e4d32760a07a0f984c2
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Jul 8 15:16:29 2021 +0200
try to restore SwpHints::MergePortions...
was not good enough
Change-Id: Ic5b9d9d7081ab3bc814388332672ff950fb84802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118772
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
... SwXMLItemSetContext and XTextRangeOrNodeIndexPosition
See tdf#94879 for motivation.
Change-Id: Ied25f44dd03fa7760613d89e11003028ce60982a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118764
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This introduces internal tracking of last used directories.
Each caller of the file picker can pass a "context". The selected
directory will then be saved & restored when opening the file picker
with the same context again.
After ffa636ba74b04b3258ec9a696bc4eac33581fa24 , the Windows file picker
no longer tracks the last used directory itself.
This is a replacement and an improvement at the same time, since there is not
one global last used directory, but one per context.
Change-Id: I10650cfb9359922690954fa65c89b4e47477e2c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118597
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
... logic to how it was trying to work before I started messing with it in
commit 568b820bc2d52c007ee08ad7a3849c94a458115d
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Tue Dec 17 15:11:34 2019 +0200
tdf#119227 fix freeze when copying a large bulleted list
freeze goes from 5 seconds to about 1 second for me
(1) used unordered_map instead of map
(2) don't create temporary SfxItemSet's just to check equality
and then I tried to fix that in
commit 18e4367c33f327cf09985105bde583cdcc7b2a46
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 3 14:40:32 2020 +0200
tdf#132688 diacritics broken in lines with punctuation
regression from
commit 4b2d4f3c4a68361a6bc03c9ab110ce9376b14b20
tdf#119227 fix freeze when copying a large bulleted list
and then Andreas tried some more in
commit 003d65ef1305eefb43315f93bdf10cee787f90f0
Author: Andreas Heinisch <andreas.heinisch@yahoo.de>
Date: Mon Jul 5 22:32:52 2021 +0200
tdf#140197 - Letter cut off at certain zoom-level
regression from
commit 4b2d4f3c4a68361a6bc03c9ab110ce9376b14b20
tdf#119227 fix freeze when copying a large bulleted list
Change-Id: Id9d04f96ccbe496ed809cf08e7aab25d6464913f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
by extracting the attribute to a separate function, where
we can use early return to exit the loops more naturally.
Change-Id: Ibd189065f0e435be398db232b317f025192b3ee9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9279a1729e1715ac44c600c930f50c6e8704e676
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118393
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
Change-Id: Ic95562ebb57106c733d919059ff9d042fef28f3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118392
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
Wrapping this in a scope based helper is mostly lipstick on a pig, but
at least one cant forget toggling back this way. Apparently, this flag
was already toggled in recursive calls without checking previous state,
which is likely buggy.
In the long run, this should a/ never be used recursively or better b/
not be a global flag at all.
Change-Id: Id3554d2acb94d565611701c046ca4d8669594cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118371
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
these old ww7- font names are supposed to be limited to maxStrSize
Change-Id: Ide316a09d97d535b6cbc2911466df12f37e703cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118689
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9e7abcbc15ecd485df510aab7fdf93cd83b2f5ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118688
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
If direct formatting specifies a numId, but does not provide
a listLevel, the listLevel can be inherited from styles.
Since this is a NOT-OVERWRITE, it is fine to try to
insert again even if direct formatting has already
inserted a level.
Change-Id: Id6e492c8f686949de862cb052866b824ef90d8ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115259
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
...by assuming that all const member functions are side-effect free. (This
presumably means that some of the special cases in
StringAdd::isSideEffectFree are obsoleted by this more general case, but any
such removal is postponed to later clean-up.)
(Came across this when idly wondering why
8b7f948d9d79393bc6c1b11d239706666fd5d7de "sc, VmlFormControlExporter: avoid
OStringBuffer style" had not been found by the plugin before.)
Change-Id: I6bca10df53885b14a590543aabd61f23b3748572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118675
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This was added in commit 50223ea6e212b60b7d33839c2753c5601fb50f95
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
it's off by default and is in for Word documents.
Change-Id: Ie3fdd0328e285de189d32edd73ea08e0938f6887
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118655
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and so does numId 0.
Wow - this is REALLY FUNDAMENTAL stuff, and we weren't
handling it? Did anyone look at any of the specs
when they were implementing import of numbering?
Change-Id: I3ea20baccfae34751328558a873ccdcfda0de0a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115258
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Just like numId, listLevel is inherited from parent styles.
This was totally missing. Even the direct formatting of
a listLevel value was ignored (although that case would
be rare, because usually both numId and listLevel are defined
together).
It seems like the most fundamental basics of our numbering
import are wrong. EXTREMELY DANGEROUS TERRITORY,
although this particular change ought to be quite safe.
Change-Id: Ia3cbd941a0a90a932938597e0797ee8e2b0aca6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115257
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
anchored to characters or paragraphs.
Tracked deletions and insertions weren't imported,
if they contain only images anchored to character,
resulting loss of the document content: i.e. deleted
images were reappeared, as not deleted images.
Note: because change tracking of the OpenDocument
and Writer supports only text range based changes,
the fix is a workaround using zero width spaces
to create an invisible text around the anchoring point
of the images. This workaround is not used, if it's not
necessary, i.e. if the image is part of a bigger
deletion or insertion, which contains also text, not
only an image.
Change-Id: Iaae6aae2c01191512c71117a0c788a4147c4cae0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118557
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|