Age | Commit message (Collapse) | Author |
|
The check for existing bookmark positions is using the wrong position.
It must use the Start of the pam, because the constructor of
CrossRefBookmark only uses the Start of the pam.
Change-Id: I343f1c0e3571847a965a27571f01136810e83485
|
|
... which was apparently written by LO >= 4.1 on a frame with image
background, under unknown circumstances.
Change-Id: Ie86643ab67f58bfe5c19d6a1f80a7af8f793edf2
|
|
This reverts commit 480ca7434a330b2678f9ef287cffd6d9cf27bed5.
Change-Id: I69a16425fc36979d49f409bbd7921495a22a35dc
Reviewed-on: https://gerrit.libreoffice.org/15737
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Joren De Cuyper <jorendc@libreoffice.org>
|
|
Change-Id: I3df326eadc2f137c75e87835caf12266dbd011b5
|
|
Change-Id: I62645c02c556cb52d53e76c93ae17b41dfd43820
|
|
The Android LOK client always creates a text selection by double
clicking on a word, and then the start/end of the selection can be
adjusted using handles. In the GTK LOK client, it makes sense to allow
the desktop-style selection, where you click somewhere, move the mouse
and finally release the mouse to create a selection. That can be mapped
to settextselect-reset on mouse-down, and settextselect-end on
mouse-move easily.
The only problem was that SetCursorTwipPosition() assumed that there is
a selection already -- fix that by adding the missing Stt/EndSelect()
calls and limiting the lifetime of the SwMvContext instance.
Change-Id: Iaeeadd8e4d9030614ee069b9fcfa269ce74ed58a
|
|
Change-Id: Ia2e946b272c587cbbdfdbc0935204c5854aa2a41
|
|
Change-Id: Iacc9b85851ed3a8ad1bada5331dc850dc564ba5b
|
|
Change-Id: I5f3c3c7826c867eaca8af0e2aa35c9919d8b1319
|
|
Change-Id: I6a68d22f9b7ded9d58a69057bf0f4197a67fd2e8
|
|
Change-Id: Iebbcd09dcca109539ef32d44816b621b90624fb8
|
|
Change-Id: I3cf9be2e84904f88ab820d97ee56c39e990c8737
|
|
Change-Id: I25e93ffd474d821a6b92f99327fe99e06bb89a62
|
|
Change-Id: I4c15bb0428005031ea3b4766eb4221ff48d91514
|
|
Change-Id: I16e1888900478c000c4437299357276e20c197c0
|
|
Change-Id: I969d99fa8881cc89601696a2d8621905a82b147b
|
|
Change-Id: I4cdaf36581d1e1daa39929e621070d18a9996852
|
|
Change-Id: Id83d8a1c26afba5a19cdab555fa40b5ed73e46d1
|
|
When the textboxes extend beyond the page bottom, the fix for
tdf#91260 keeps the original vertical position of the text frame
by changing its height.
Change-Id: I691b46640876bd082bd83da1bbd43f1e33ec807d
|
|
Change-Id: I5b99e42a3e85527b27d515c468d2ed66386fc9df
|
|
Change-Id: Ie7302c909feb2e83b8b5e62a5e6a1f901783fb49
|
|
Change-Id: I58031485aaa9ebdeb986a3ee0376f36a9f667947
|
|
The old internal RTF filter used to call SwTxtNode::SetAttr() without
setting SetAttrMode::NOFORMATATTR, so character attributes which cover
the whole node got converted to paragraph attributes. The new UNO
filter goes through SwXText::insertTextPortion(), which sets
SetAttrMode::NOFORMATATTR, so this doesn't happen. The result of this is
that when the UI sets a new paragraph style on the text node, then such
character attributes are no longer removed.
Given that in RTF you can't really have character properties on a
paragraph, going back to the document model produced by the old internal
filter doesn't sound like the good direction -- not to mention that
changing SwXText::insertTextPortion() this way would be an implicit API
change.
Fix the problem by tweaking SwEditShell::SetTxtFmtColl() instead, so
that it removes these full-text-node character attributes, too. The
logic in SwTxtNode::RstTxtAttr() can be extended later if necessary to
delete more attributes, but to be on the safe side, just handle the bare
minimum necessary to fix the problem for now.
Change-Id: I5faa3226fc0f9c18e005da185fe0830d8c393256
|
|
Change-Id: If24a9d79ed26d059c18150201d89f72c515fb89d
|
|
Change-Id: I74bdd36e01ea7a8ca8ab2041c38a5169cbca9827
Reviewed-on: https://gerrit.libreoffice.org/15537
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icf833ca052f925075447bbf6845ad61da267cc8b
|
|
Change-Id: I104d6db7834b4235248736a9498a0e2a20cc7a43
Reviewed-on: https://gerrit.libreoffice.org/15722
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
With the missing documentation filled in from the rtf spec we can remove the
crack and replace with to-char anchoring and set equivalent relative
positioning attributes. Which stops us having the odd page anchoring
which triggers an assert on exporting ooo59101-1.doc to odt and gives
ooo59101-1.doc the same object positioning as seen in MSWord
Change-Id: I7574f32c9df0aac4a15efdb8ebf5d7835f5c6103
|
|
Change-Id: I09a4abd8fb34470c4c365aa1f604accd80631ab3
|
|
Remove pointless duplicate temporary PaM.
Change-Id: I28a1937928b6c3c21442bbfcb77377372c1cf40b
|
|
Change-Id: Ic89bfcb13515ba3e9ce4410e84813d4e953ee603
|
|
There's a SwTxtFrame inside a table, and OptCalc() is called on it which
calls pUpper->Calc(), which reformats rows the table and ends up calling
SwTxtFrm::_AdjustFollow() on some SwTxtFrame that has the first one as
follow. Use the new ForbidDelete() hack to prevent immediate disaster.
Change-Id: I091704ce6cde15e322986b8f2ecefb5a518f0d8c
|
|
... that have page anchor type without text:anchor-page-number, so the
import stores a temporary anchor position that MakeFrms() cleans up.
Change-Id: I440d3a138659933e54f671d87bc418d5ba1059fb
|
|
This commit fixes layout problems of DOCX import, but also
now it's possible to move a textbox beyond the page bottom
using the arrow keys (this worked only for page-anchored
shapes in Writer).
Change-Id: Ie83d3202a2248d948348656aa26df20982f9675b
|
|
Change-Id: I2df0929d1b34b9ebf2d5d4c27321abdea072007a
|
|
|
|
Change-Id: I36fea4608c744c941bdff401b649fa46302b4dbd
|
|
Change-Id: I744d430ef6a506977eb10b892582c8969ec27524
|
|
Change-Id: I26e03159fa6115025c6cf376e6ce71443bc98cec
|
|
Change-Id: If9ca3234f9f3ea1ed176d3fc020d4b6d7a554937
|
|
Change-Id: Ic6f4d1238c0a4c8f4632cf26099ef406caf5dbda
|
|
... with a CopyLinePortion function; how can you even...
Change-Id: Ie7d459ee317522e35fdbbd3974afabe7a136fe62
|
|
It looks like it can be easily avoided.
Change-Id: Ied8a047871c431b809569e1bbf232ce769d498ec
|
|
Not sure what it should do, but given the parameter is SwLineLayout
it will set POR_LAY on a SwTxtPortion which is wrong.
Change-Id: I4296bcdf9e788338eb007ad09eae675a9fdc6a75
|
|
Crash in sw.SwXTextRange because the SwTxtPortion copy ctor is
invoked, which copies the portion type POR_LAY, but SwTxtPortion
must have POR_TXT.
(hilarious regression from 2db379e22a7854dc16cc0066af70f16d5662d7e8)
Change-Id: I781191a60dafeba2257edf01699fafae78b45783
|
|
Change-Id: I2ba426168f861e69ef81850bb23576036b30fc76
|
|
Change-Id: I6abcce4f526834648409ebce17c8b9f13bf956e2
|
|
Change-Id: I85eb5e9ca018afa25a06947eed5af1ab529dd65d
|
|
Change-Id: I06a5ff604e6782863c4a2d6e002c9d67d42912fb
|
|
Change-Id: I3d7bf8a5db4dcae4b5653fe5e033bc9e626b7bbf
|