Age | Commit message (Collapse) | Author |
|
Replace the old trick with character-level rotation with the usage of
the new writing direction.
This means that finally table cells with btlr text direction and
multiple paragraphs show all content, not only the first paragraph, as
before (seen as data loss by users).
Change-Id: I094f36fa6ba0701579e487e8e0212707987b1b2f
Reviewed-on: https://gerrit.libreoffice.org/67870
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
aVerticalLeftToRightBottomToTop was wrong, it mapped from physical to
logical, and it should be the other way around.
In practice this means that when SwTextFrame::AdjustFrame() is invoked
for a second lower, then nAdd will be a small positive (and not a large
negative) number, so the
warn:legacy.osl:20827:20827:sw/source/core/text/frmform.cxx:479: Ey
warning goes away and the second lower becomes visible.
Change-Id: I894fef4a89b1feeb333537ff7d76793130007ed8
Reviewed-on: https://gerrit.libreoffice.org/67862
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I08fcbe2569c07f5f97269ad861fa6d38f23a7cc7
Reviewed-on: https://gerrit.libreoffice.org/67816
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9d85f6a86d96353312bb00aeb1c173fa9fdfefda
|
|
In particular, the value 2 means "do not save".
Change-Id: I9788d201f8ecfcc016a12aa2088552ee994e1c17
|
|
Till it's clear why it has unexpected values.
Report from mailing list:
> Test name: SwLayoutWriter::testBtlrCell
> equality assertion failed
> - Expected: 2707
> - Actual : 2710
> - In <>, attribute 'y' of '//textarray[1]' incorrect value.
Change-Id: Ic914f513df544dcf472b0870a3936f87d876c76b
Reviewed-on: https://gerrit.libreoffice.org/67856
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The problem was that the x position of the btlr text had a 159 twips
difference (it was too close to the cell border), since the text portion
height -> baseline offset calculation worked with the descent, not with
the ascent.
The position of the text now matches exactly what Word does.
As a side-effect this means that multiple portions in a line and also
multiple lines in a text frame now work correctly.
Change-Id: Ic139db328e2a913e5cae4026886c3410cdab357d
Reviewed-on: https://gerrit.libreoffice.org/67823
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ibf8a644c1d61516caa67e0ce22b33a41380d9911
Reviewed-on: https://gerrit.libreoffice.org/67621
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
There was only horizontal and vertical previously, so keep things simple
and talk about the BT and TB version of vertical, not mentioning the
LR/RL aspect.
Also rename the textdirection widget, so it's unique not only within the
tab page, but inside the dialog, so we can have uitest coverage for
this.
Change-Id: Ie396898fde03aca6cd37a29f049099fa4b2c5fc0
Reviewed-on: https://gerrit.libreoffice.org/67789
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Fails with commit e8b9572bf89f55463f2c879a401ed62efc165d95 (sw btlr
writing mode: implement initial layout, 2019-02-12) reverted.
Change-Id: Ic68ef53a8b5bf86678d7e67c9960501f23341268
Reviewed-on: https://gerrit.libreoffice.org/67776
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I1980cfd444e4ccee6574878fb6d6dd507bc972d5
Reviewed-on: https://gerrit.libreoffice.org/67673
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
An easy way would be to just extend aXML_WritingDirection_Enum, but then
we would write the new attribute value to a non-extension namespace.
So special case the new attribute value during both import and export
(and only for table cells as a start).
Change-Id: I431bf99693c4a3452e91f241bd2f0fcfc72c68fd
Reviewed-on: https://gerrit.libreoffice.org/67770
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
We should restrict this to this case since the anchor of objects in the
body may appear on another page when the object is moved around.
In constrast, objects in header and footer should not appear on other pages,
so we still disable the "off-page positioning" for them.
Horizontal off-page positioning should be disabled in any case.
See also
tdf#112443 and tdf#120839
Change-Id: I056c74526f38c302ba49297f9f84ec0e958d2cec
Reviewed-on: https://gerrit.libreoffice.org/67088
Tested-by: Jenkins
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Just remove this update fields call, they are updated anyway.
Change-Id: Iaed1b6e7e1be8138ecb48e7557cc09ec0eeebda3
Reviewed-on: https://gerrit.libreoffice.org/67754
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
since it is just a wrapper around PointerStyle
Change-Id: I51f065e0d4ad8bd91f5c84c5819048c720a19267
Reviewed-on: https://gerrit.libreoffice.org/67711
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie5c5f6296e54b1118f1182766473f3f70eb37385
Reviewed-on: https://gerrit.libreoffice.org/67722
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Mostly just clean up with pylint, and changing variable
names to comply with the style guide.
Change-Id: I7298fbbcf394de19acf66d10447676d7d822d6f0
Reviewed-on: https://gerrit.libreoffice.org/66198
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Fix various cases which trigger this warning:
warn:legacy.osl:10975:10975:sw/source/core/txtnode/swfont.cxx:427: Unsupported direction
Which means that we tried to work with a VCL direction of 900, without
passing around the btlr flag accordingly.
Change-Id: I96374fc949f60e8324c5a84de48b710b6461bafb
Reviewed-on: https://gerrit.libreoffice.org/67746
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The bulk of this commit is reasonably straightforward, the interesting parts
are:
- SwFrame::CheckDir() is where the layout reads the doc model, i.e. sets the
new SwFrame::mbVertLRBT.
- We had 3 text directions previously: horizontal, vertical (implicitly RL) and
vertical LR (implicitly TB). This adds a 4th text direction for the LRBT case.
- SwTextFrame::SwitchHorizontalToVertical() is responsible for re-locating the
origo of a string to be painted from the top left to the bottom left corner (in
addition to the height/width swap that's done for all vertical directions).
- Finally MapDirection() is the place where we map Writer's new btlr mode (with
no character rotation) to VCL's 900 (90 degrees) rotated direction.
No functional changes intended for existing text directions. Lots of places are
still not yet adapted, but this is good enough to paint a single word in a
table cell at the correct position with the correct direction.
Change-Id: I465c62db6562d8a2be140c3d37473e590830139e
Reviewed-on: https://gerrit.libreoffice.org/67740
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is not and has never been a unit test; let's remove it to avoid
confusion.
Change-Id: I42a5e8f9d2f9757bcc9e0c6051e5d86ffc6e023f
Reviewed-on: https://gerrit.libreoffice.org/67732
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins
|
|
(visible sheet) of an embedded spreadsheet,
instead of exporting always the first sheet.
Change-Id: I5c6f982b1b814a5f3830f08d247f4db3fdc3c384
Reviewed-on: https://gerrit.libreoffice.org/67733
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The custom code in SwXCell::setPropertyValue() was added in commit
5a5597655a4bf12e4ca07c9c2b6f6221e217f080 (tentative fix for fdo#30474#,
2010-11-26), which suggests that not handling all constants from
text::WritingMode2 was not intentional.
Later the writerfilter side (which is the only client of this hidden
property) was adapted to use text::WritingMode2, so do the same here.
This implicitly adds support for the new text::WritingMode2::BT_LR as
well.
Change-Id: I37d8eaa844847cb19e7503b2d973069f9895e6bc
Reviewed-on: https://gerrit.libreoffice.org/67730
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I183d2d94ab60c128b136674ef40eeb30057b281c
Reviewed-on: https://gerrit.libreoffice.org/67714
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I962d3d9f5fcb95c7f2b19169ca87b262ed320279
Reviewed-on: https://gerrit.libreoffice.org/66203
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
It was originally short for “facsimile”.
Change-Id: Icaadde5c1beaf8bbbc72144a7ce60f96794f8a33
|
|
Layout was not invalidated correctly since the visible area is 0
in headless mode.
So just reformat the whole doc when doing the pdf conversion headless.
An attempt to fix this was already made with commit 1ecca673b40fedc53db125e332b087d1c120a254
but that didn't cover all cases.
Change-Id: I3f620b2f2db2c4a6e5bf279b33e5c93697e4e2d4
Reviewed-on: https://gerrit.libreoffice.org/67417
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Pointed out by lcov for the RTF import, but all of RTF/DOCX
import/export was missing.
DOC export is still missing.
Change-Id: I9c48a08c3e951409f59dc1631a6ab39aa95f905d
Reviewed-on: https://gerrit.libreoffice.org/67700
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Use pylint to make xtextcontent.py more pythonic. Mostly,
changing variable and method names to comply with the
python style guide. Also, remove unneeded imports.
Change-Id: I80e6fa53e67a86520a85284f3dad76a614450047
Reviewed-on: https://gerrit.libreoffice.org/66199
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I40afcb99ae0e8fd27387077aea688906f037d6f4
Reviewed-on: https://gerrit.libreoffice.org/67676
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I416e3fcffe7da549ffd3b82cb912d78d1ca02339
Reviewed-on: https://gerrit.libreoffice.org/67682
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
largely based on the relevant portion of the unusedfields loplugin, but
adapted for local vars
Change-Id: Ic522a941573940e8f75c88f90ba5f37508ca49b1
Reviewed-on: https://gerrit.libreoffice.org/66835
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I36c02de94bd7fcbf06e53ce930b6b0e850f2ae31
Reviewed-on: https://gerrit.libreoffice.org/67667
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I2a2a189ee727a51aeef5601b39bb288d813fc8f3
Reviewed-on: https://gerrit.libreoffice.org/52610
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4449fead67459bdcbdc0e9320129e7a5b36aecd9
Reviewed-on: https://gerrit.libreoffice.org/67545
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I62cb3b8927d664b3d5359ee6ac7db30d354f4821
Reviewed-on: https://gerrit.libreoffice.org/67496
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I67462369d93e9d9ff3c056800947c4b75f71ba5f
Reviewed-on: https://gerrit.libreoffice.org/67486
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Which doesn't actually make much of a difference in this case because
this is a welded dialog, which currently does not preserve a VclPtr
owner of such dialogs.
Perhaps we should rather fix the
SfxTabDialogController::runAsync
infrastructure to temporarily
(a) preserve an owner for such dialogs
(b) disposeAndClear such dialogs
at least until we are done with welding?
Otherwise this is very confusing.
Change-Id: I568eb6813925299663ac3f90749b64076d404d19
Reviewed-on: https://gerrit.libreoffice.org/65708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4936284bff568b6bb47e5df3821f4ddd78260e92
Reviewed-on: https://gerrit.libreoffice.org/67568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2f5676e9973d476aa709f9dfb4a903b09edaafeb
Reviewed-on: https://gerrit.libreoffice.org/67336
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
indexOf is always lower than string length since "not found" is
encoded as -1. Original code works correctly anyway since the
"not found" case lead to copying the whole string, although this
copy is completely unnecessary.
Change-Id: Ic5dd995dd0c3f974c77b5bf209ad5e994b044385
Reviewed-on: https://gerrit.libreoffice.org/67320
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: I3c1df346c56bfbd6e885b5ddb78ac3162a8bc32e
Reviewed-on: https://gerrit.libreoffice.org/67327
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: I1fa06283b3c1857c81ec320b98db857a42e91bca
Reviewed-on: https://gerrit.libreoffice.org/67333
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: I7ba78cc8ecf7d2ecface0e69dcacc9bae869c7e6
Reviewed-on: https://gerrit.libreoffice.org/67335
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: I8ab1c2956739c9b63de807176ca0e3a640d3961f
Reviewed-on: https://gerrit.libreoffice.org/67325
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Regression from commit 50223ea6e212b60b7d33839c2753c5601fb50f95
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
the problem was that vertical position of the shape was wrong after
mouse move, even if we attempted to take fly frames of the paragraph
into account. (Similar situation is when saving and loading the file;
which is much easier to test.)
Fly frames are created as the
text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can
calculate the vertical offset correctly. But in the "move with mouse"
case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by
the time the old flys of the text frame were already removed, but the
new ones were not yet added.
Solve the problem by formatting the text frame from
SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity
flags are set to false) -- this is expected to be safe, as the object
formatter is invoked by SwLayAction::FormatContent(), i.e. there is no
recursive SwFrame::Calc() call here.
Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b
Reviewed-on: https://gerrit.libreoffice.org/67490
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I52d75427fe30945293f347e3f49d21bc2016edae
|
|
Change-Id: I134101d1be5922051e34352331a49f5706030ff2
|
|
On the one hand, SvxZoomSliderItem/SvxZoomSliderControl as used by SwView's
SID_ATTR_ZOOMSLIDER support a range from MINZOOM (20) to MAXZOOM (600) (defined
in sw/inc/view.hxx). Setting a zoom value outside that range for one causes the
DBG_ASSERT "Looks like the zoom slider item is corrupted" in
SvxZoomSliderControl::StateChanged (svx/source/stbctrls/zoomsliderctrl.cxx) to
fire, and for another (when setting a too small value) tries to assign a
negative value (which wraps around, and gets flagged by Clang's
-fsanitize=implicit-signed-integer-truncation) to sal_uInt16 nCurrentZoom at
nCurrentZoom = nCurrentZoom - mxImpl->mnMinZoom;
in SvxZoomSliderControl::Zoom2Offset (svx/source/stbctrls/zoomsliderctrl.cxx).
On the other hand, SwXViewSettings' support of css.text.ViewSettings' ZoomValue
property allowed values in the range from 5 to 1000 (cf.
SwXViewSettings::_setSingleValue in sw/source/uibase/uno/unomod.cxx), and some
JunitTests actually set such values (10, 15) below the MINZOOM value of 20.
The incompatible 5--1000 range was there ever since
7b0b5cdfeed656b279bc32cd929630d5fc25878b "initial import", but looks rather
random, so change it to match the 20--600 range instead. (And lets flag this as
an [API CHANGE], to be on the safe side.)
One of the JunitTests files that needed to be adapted,
qadevOOo/tests/java/mod/_sw/SwAccessibleEndnoteView.java, oddly mentioned a
zoom value of 130% in a comment while using the value 15 in the actual code.
(And did so ever since the test code's introduction in
26ebdfc472be16f0eb4110aab0335666d2ba5e62 "NEW: initial version".) Changing the
code to 130 would cause JunitTest_sw_unoapi_1 to fail in strange ways, with
disposed UNO objects, while changing the code (and comment) to 21 appears to
work. Go figure.
Change-Id: Id944ffdce501448312e008436e7038bf2aec63ac
Reviewed-on: https://gerrit.libreoffice.org/67427
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I871312c1077439377c67b76112f38b7019fa6fb1
Reviewed-on: https://gerrit.libreoffice.org/67376
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
it now looks old-fashioned hyphenated
Change-Id: I5b2b905277356c1b986f97de29f82ac1c21b1709
Reviewed-on: https://gerrit.libreoffice.org/66796
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|