| Age | Commit message (Collapse) | Author |
|---|
|
need to move it, because modules "below" vcl want
to use the debug output method
Change-Id: Ibcaf4089a1e0b3fcc0b5189c7ebf1aae90f50b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Commit 7e23cbdbb6ec0247a29ed8a8f744c01e10963ea0 changed the code so,
that TextPreRotateAngle is used to track ooxml vert attribute. This
patch changes it so, that the style attribute WritingMode is used.
Now text direction can be written in 'writing-mode' attribute in the
graphic properties in ODF, same for shapes as for frames.
The needed conversion from WritingMode BT-LR and TB_LR90 to
TextPreRotateAngle for rendering of text in custom shapes is now in
one place in class SdrObjectCustomshape. The shape edit engine
cannot yet render it itself.
Some unit tests are adapted to use WritingMode property instead of
TextPreRotateAngle.
The value text::WritingMode2::TB_RL90 is introduced, corresponding to
vert='vert' and textDirection='tbRl' or ='rl' in OOXML. It is used
for frames too, so that the original text direction is preserved and
vert='eaVert' can be distinguished from vert='vert'.
TextPreRotateAngle is currently still used in SmartArt import for
'upr' and 'grav' and in emulating 'upright' but no longer to
emulate text direction.
Change-Id: Idc4339bbfc3592fe90b154d75e2c404a1fa30856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138813
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I7eb974a4adab74a93a10ff08c8853fbb5ae88885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139372
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If31e5046dcdf02c842a6f2c2b4dc281f1f5573b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139263
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
With 16k column support in Calc enabled by default in
commit 4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58
Date: Tue Mar 8 12:44:49 2022 +0100
change default Calc number of columns to 16384 (tdf#50916)
, the number of Calc cells in a spreadsheet is larger than
SAL_MAX_INT32, meaning that a 32-bit a11y child index is no more
enough and using it resulted in integer overflows in
methods handling corresponding Calc cells in the a11y layer.
This e.g. had the effect of the Orca and NVDA screen readers
not announcing focused or selected cells properly when their
a11y child index was out of the 32-bit integer range.
Switch the internal a11y child indices to 64 bit to
be able to handle this properly internally.
Since the platform APIs (at least AT-SPI on Linux and
IAccessible2 on Windows; from what I can see LO's macOS
a11y bridge doesn't directly expose the child index)
are still restricted to 32 bit, larger child indices
still cannot be exposed via the platform APIs.
As a consequence, use of the the IAccessible2 and
AT-SPI methods that use the child index remains
problematic in those cases where the child index
is larger. However, as an alternative to using the
AT-SPI Table interface and the IAccessibleTable/
IAccessibleTable2 interfaces with the child index
to retrieve information about a specific cell,
both AT-SPI and IAccessible2 also provide interfaces
to retrieve that information directly
from the cell object (TableCell interface for AT-SPI,
IAccessibleTableCell for IAccessible2).
Those interfaces are already implemented/exposed
for winaccessibility (s. `CAccTable`) and the
qt5/qt6/kf5 VCL plugins (s. the `QAccessibleTableCellInterface`
methods implemented in `QtAccessibleInterface`).
With the switch to 64-bit internal a11y child indices,
these now behave correctly for cells with a child
index that doesn't fit into 32 bit as well.
NVDA on Windows already uses the IAccessibleTableCell
interface and thus announcing focused cells works fine
with this change in place.
Orca on Linux currently doesn't make use of the AT-SPI
TableCell interface yet, but with a suggested change to
do so [1], announcement of selected cells works
with the qt6 VCL plugin with a current qtbase dev branch
as well - when combined with the suggested changes
to implement support for the AT-SPI TableCell interface
in Qt [2] [3] and the LO change based on that [4] and
a fix for a nullptr dereference [5].
The gtk3 VCL plugin doesn't expose the AT-SPI
TableCell interface yet, but once it does so
(via `AtkTableCell`), it also works with the
suggested Orca change [1] in place.
(Adding that is planned for an upcoming change,
works with a local WIP patch.)
For handling return values that are larger than what
platform APIs support, the following approach has
been chosen for now:
1) When the return value is for the count of
(selected) children, the maximum value N
supported by the platform API is returned.
(This is what `ScAccessibleTableBase::getAccessibleChildCount`
did previously.)
The first N elements can be accessed by their
actual (selection) indices.
2) When the return value is the child/cell index,
-2 is returned for objects whose index is greater
than the maximum value supported by the platform
API.
Using a non-negative value would mean that the
index would refer to *another* actually existing
child. A child index of -1 on the other hand
tends to be interpreted as "child is invalid" or
"object isn't actually a child of its (previous)
parent any more)". For the Orca case, this would
result in objects with a child index of -1
not being announced, as they are considered
"zombies" [6].
What's still somewhat problematic is the case where
more than 2^31 children are *selected*, since access
to those children still happens by the index into
the selection in the platform APIs, and not all
selected items are accessible this way.
(Screen readers usually just retrieve
the first and last element from the selection and
announce those.)
Orca already seems to apply different handling for the
case for fully selected rows and columns, so
"All cells selected" or "Columns ... to ... selected"
is announced just fine even if more than 2^31
cells are selected.
(Side note: While Microsoft User Interface
Automation - UIA - also uses 32-bit indices, it also
has specific methods in the ISelectionProvider2
interface that allow to explicitly retrieve the
first and last selected item,
`ISelectionProvider2::get_FirstSelectedItem` and
`ISelectionProvider2::get_LastSelectedItem`, but
we currently don't support UIA on Windows.)
Bound checks at the beginning of the methods from the
`XAccessibleContext`, `XAccessibleSelection` and
`XAccessibleTable` interfaces that take a child index
(or in helper methods called by those) should generally
already prevent too large indices from being passed to
the methods in the lower layer code that take smaller
integer types. Such bound checking has been
been added in various places where it wasn't present yet.
If there any remaining issues of this
kind that show after this commit, they can probably be
solved in a similar way (s.e.g. the change to
`AccessibleBrowseBox::getAccessibleChild` in this
commit).
A few asserts were also added at
places where my understanding is that values shouldn't
be larger than what is supported by a called method
anyway.
A test case will be added in a following change.
[1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/131
[2] https://codereview.qt-project.org/c/qt/qtbase/+/428566
[3] https://codereview.qt-project.org/c/qt/qtbase/+/428567
[4] https://gerrit.libreoffice.org/c/core/+/138750
[5] https://codereview.qt-project.org/c/qt/qtbase/+/430157
[6] https://gitlab.gnome.org/GNOME/orca/-/blob/82c8542002e36e0d3d918088d583162d25136143/src/orca/script_utilities.py#L5155
Change-Id: I3af590c988b0e6754fc72545918412f39e8fea07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139258
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
map is already a node based data structure, so the values will stay
in the same place in memory
Change-Id: I26ac04787a3b36feebd574687710b3a2b6864c0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139234
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... to prepare for more finegrained private-use control.
Change-Id: I118c3f5ee6e437435c07ed2cf699c4597e9cdf88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139112
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Previously, when measuring caret position, Writer would measure the
width of the substring before the caret (i.e. layout it independent of
the text after the caret and measure its width).
This is incorrect, though. It assumes cutting the string laying it out
would result in the same width as when laid out as part of a bigger
string, which is invalid assumption when e.g. cutting inside a ligature
or between letters that have different shapes when next to each other,
etc.
This appears to work when the width of the substring laid out alone is
close enough to its width when laid out with the full text. But in cases
where is widths are largely different, like the extreme case in the bug
report, the caret will be jumping around as it is positioned based on
the unligated glyphs not the ligated, rendered glyphs.
This change introduces a special mode of measuring text width for caret
positioning, that will layout the whole string that return the width of
the requested substring.
Fields and small caps text are trickier to handle, so old behaviour is
retained for them. Now one will probably notice but if they do, it can
be dealt with then.
This also tries to be conservative and keep other pleases using the
existing behaviour which might be desirable (e.g. when measuring text
width for line breaking, we want the unligated width), but there might
be other places that should use the new behaviour.
To handle caret inside ligatures, the grapheme clusters in the ligature
are counted and the width of the whole ligature is distributed on them
evenly. A further improvement would be using HarfBuzz API to get
ligature caret positions for fonts that provide them, which helps when
the ligature components have different widths.
Change-Id: I02062e2e2e1b1a35c8f84307c0a8f5d743059ab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138889
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Just convert some loops to range based.
Change-Id: Id80d9366f77bb08a130004db800b19e967496541
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138221
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I5ab44c6aca318a56e63b8bba7dda51b4ec534a59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138861
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Such that dropping an acor_art-x-mylang.dat file or with any other
valid language tag creates a language list entry if none exists
yet, so it can be chosen in character attribution and the
autocorrection data be used.
Change-Id: Idea200fd07dd821559db65c669a8c8e10af064f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138844
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Jusify() normalizes the rectangle so both the Width and Height are
positive, without changing the location of the rectangle. It ensures
that the x and y coordinates will be moved to the top left of the
rectangle.
The name is strange, so renaming Justify() to Normalize().
Change-Id: Idbf163e65e52a798e38f785b8961b8042cf0cf2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137379
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
When character spacing is not zero, optional ligatures should be
disabled (e.g. this what CSS requires and what browsers implement:
https://drafts.csswg.org/css-text/#letter-spacing-property).
This disables both “liga” and “clig” OpenType features because they are
optional features and are enabled by default, it does not disable “rlig”
because it is for orthographically-required ligatures, nor “dlig” or
“hlig” because they are disabled by default.
The character spacing values (confusingly called kerning in the source
code) are moved from SvxFont to vcl::Font so it can’t be accessed in
OutputDevice and pass the relevant flag to SalLayout.
Change-Id: Ieacc875df3896ad7a63ae8d116f4c6ff7265b9a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138711
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
check like SvxUnoTextRangeEnumeration ctor does
Change-Id: I4dd4e08c72e9ad0f29afa2f88670f771dcb25b37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138576
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This partially reverts the still relevant parts of commit
commit 41007842ed9bb5d6165792a197769f72dae55a2c
Author: Martin Hosken <martin_hosken@sil.org>
Date: Thu Sep 10 10:14:18 2015 +0700
Refactor graphite integration and update graphite
Change-Id: I09db7262c2a6180a078620ba086dd7a4c132bd82
Reviewed-on: https://gerrit.libreoffice.org/18459
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
No mention of the commit about this change or its relevance to Graphite
integration. But the separate Graphite layout engine is long gone and
Graphite handling goes through HarfBuzz now, so whatever the change was
for is probably no longer relevant.
I reverted only one the two changes in impedit3.cxx, as the other one
does not seem to make any difference for this issue.
Change-Id: Id70a711d6231cce52c9a32dbc3604860b1da9f4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138217
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
We were skipping the marks when checking for previous char, but not when
setting the index to previous char.
Fixes also the second part of tdf#106653.
Change-Id: I73436ba9df6ccf104ea6d4dfbd76a59c86040a44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138154
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It seems that editeng is using an old copy of the code in sw and it was
never updated.
With this change, the text in the test document from tdf#137528 looks
essentially identical in both cases.
Fixes also tdf#146199.
Change-Id: I38541bfb35eae36681af84e73a7965d36152448f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138145
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
GetListFormat DEPENDS on having managed prefix/suffix itself,
since it uses their getLength to modify the sListFormat.
So any modification via SetPrefix/Suffix
(potentially) invalidates the ListFormat.
I added some code to ensure this doesn't get out of sync.
One place that still uses PREFIX/SUFFIX is old ODT files.
After import they are updated, but during import they use
the old UNO properties, so I didn't add any assert here.
Change-Id: I3bab780fb8e8e985c3573075bc7aac9216d116d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138073
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
... and export of border on paragraph that clears the border from the
paragraph style.
The import problem is that a lone \brdrcf17 without any preceding
keyword about which border it belongs to (as required by the EBNF in the
RTF spec) is apparently handled by Word as overriding/clearing all
paragraph borders that may be inherited from the paragraph style.
The export problem is that a null SvxBorderLine isn't exported at all,
but there needs to be a \brdrnone to override the definition from the
style.
There was also an API problem that the null SvxBorderLine is wrongly
converted to a table::BorderLine2 with LineStyle SOLID.
Change-Id: I5fa3857de2ef843f5194e12dd0c3e57bcf1ca52b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138089
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
It isn't enough to do Paragraph->SetDepth().
It must match the property EE_PARA_OUTLLEVEL.
So I was hoping that the only thing I needed was the
"set property" helper. But unit tests showed that I also needed
"get property" to return an empty aAny instead of a -1.
My confidence level on this one is fairly low.
This code is way too tangled and weird.
I'm sure the concept is right (that the property is the
most important thing) but all of the wonkiness around
the level means any changes to the implementation
will be fragile.
make UITest_impress_tests \
UITEST_TEST_NAME=tdf148810.Tdf148810.test_Tdf148810
Change-Id: I4aa62fe28ecbc483d5df0d1532fecd172afc54b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137569
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Although a pre=existing prefix/suffix was cleared,
a non-existing oListFormat should replace an earlier one
if it is being reset.
The hasValue only applies to setting backward compatiblity stuff.
No real-world impact noticed - just cleaning up after a code read.
I ALMOST needed this in my prior patch, but then I changed
to use the other SetListFormat function call.
Change-Id: I39eed26b7720f0f9a0d982a1cd1703a55c5ab986
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137675
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
when we only need the height
Change-Id: I16d74cb6f68e3391b9857cc9702cc6f93b9fb9ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137678
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The clause to get into this function already tells us that
HOLDDEPTH is offf. The functions called in here do not
turn it on, so there is no need to clear it at the end.
This looks unchanged since initial import.
I tested with an assert that the flags saved at the
beginning of the clause were identical to the
flags at the end, and ran a make check. No asserts.
Change-Id: I28bc8725062895d94f387fa0780a16e40b4efe5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137541
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Already unused in initial import.
Change-Id: I423442a2b036c64727af608fa667f1f8a427391f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137542
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
which means we can reserve precisely the right number of entries when
building maps
Change-Id: I580414699289369de4730caae09829bbd8759e82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137292
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since ImpEditEngine::StartOfWord is only used when a selection is deleted at the left, change the search preference of the word boundary from forward to backward. For further details of a deletion of a selection check ImpEditEngine::DeleteLeftOrRight.
Change-Id: Ic68901cc04e5057e058ff03304f68eef1dca7a1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137108
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: Ifd8de0042b843de0766a370fb19b9f7791974612
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137284
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3235d82db4eb7f2770ed888ec431eeac1e6a231c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137163
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is internal API, unused (as far as I can tell) by external
users.
This state is purely a bitset
(as implemented by utl::AccessibleStateSetHelper)
so we can just return it as a 64-bit value.
This shaves significant time off the performance profiles
of code that loads very complex shapes, because this state
is frequently used, and we no longer need to allocate a return
value on the heap for every call.
Change-Id: Icf1b3bd367c256646ae9015f9127025f59459c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136786
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4db4d12261920c94bf632f07fc129e3d324dd22e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136805
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Store foreground color for color filtering, because in OOXML
the foreground color is used for color filtering and we overwrote
it with the background color which is used for conditional formatted cells too.
Regression from commit: 6f908b48373b71d45c8119b296b0504fb586f6f8
(tdf#143104 Fix xlsx import/export of color filter colors)
Change-Id: I737e6f1170851822a2689fa477db59e62f0d47fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136055
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
still too slow, halve limit
Change-Id: I4a3f1ae7e6d86c8fb1b6d67f1e382a436df45bc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136089
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Currently this silently succeeds. Turns out oox already contains some
too-short initializers, let's guess the missing properties are all
invalid.
One downside of the templated parameter pack approach in the enumarray ctor, as
witnessed in vcl/win/window/salframe.cxx, is that argument types can no longer
be implicitly deduced and thus need to be spelled explicitly now in certain
cases.
There were also three uses of enumarry with V being unsigned short (aka
sal_uInt16) that started to cause narrowing conversion errors now and needed to
be adapted: In editeng/source/uno/unonrule.cxx the obvious fix was to use the
proper type for V. In sw/source/core/unocore/unosett.cxx with its odd mix of
saL_Int16 and USHRT_MAX, lets keep things that way for now (probably awaiting
later clean up) and use casts to avoid the implicit narrowing. And in
sw/source/filter/ww8/wrtw8esh.cxx the ESCHER_Prop_* values, while presumably
conceptionally of type sal_uInt16, are plain #defines (thus of type int), so
rather than changing V to int it looked more consistent to explicitly cast the
ESCHER_Prop_* vlaues to sal_uInt16.
(And in tools/source/fsys/urlobj.cxx the poor loplugin:redundantfcast started to
unhelpfully kick in for (only) the first argument now.)
Change-Id: If06c29e673ec7e565e283c6f447889cf1f777cb7
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135970
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and
cid#1504665 Big parameter passed by value
cid#1505368 Big parameter passed by value
revert the clang-tidy modernize-pass-by-value changes that coverity
warns about
Change-Id: Id92fdc8d1caeed9eaf7ff1e9e745938e5a971a34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135803
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This code sets sufficient size for the virtual device that saves
the content, so it's not some optional debug code. Without this
selecting text in Calc formula bar and dragging it around leaves
artifacts, because the saved content is not large enough to restore
the original widget content. This dates back to
d51fe1189dcbe0fe06805c8d99687c125cd254eb, which supposedly made
the code warning-free (and also correct-free).
Change-Id: I52dab8c8d3a083fff9da8aed27facdf21076622e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135555
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ibf912c597896a2ac0bf3ba8108f55c5018115bb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135501
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In case the margin (distance between body frame and page frame) is
smaller than the border spacing (distance between border and page
frame), then we can map that to a negative border distance during the
import of DOCX files since commit
1f127a2b9e1c1daab0972f98fc8708ecb7afa299 (sw layout: allow negative page
border distances, 2022-06-07), but DOC import had the same problem.
The above commit intentionally kept the default behavior of
BorderDistanceFromWord() unchanged to avoid side effects in other
clients of that function (not DOCX import), but means that DOC import
was still broken.
Given that it turns out there are only 2 callers of
BorderDistanceFromWord(), fix the problem by allowing negative border
distances unconditionally: this simplifies code & SetBorderDistance() in
the DOC import will now get the correct border distance out of the box.
DOC export works out of the box without any additional work.
Change-Id: I6bf15b3c73823c9265218b7b3a7b869e131818db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135484
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5c1bda5419752288e494e2116bef8d258a1de4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133869
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Writer follows the CSS box model when it comes to page borders: there
can be a positive distance between the edge of the page and the border,
and again a positive distance between the border and the body frame.
This ensures that the page border never intersect with the body frame,
which is usually what users expect. Word, however, can work with 2
distances for border and text, both measured from the edge of the page,
leading to a page border, which is inside the body text. This is
described at great detail at
<https://wiki.openoffice.org/wiki/Writer/MSInteroperability/PageBorder#Importing_case_3:>.
Fix the problem by allowing negative border distances: this doesn't
influence the position or the size of the body frame, but it gives us a
way to position the border more towards the center of the page, leading
the matching layout between Writer and Word.
The doc model (to allow negative border distances), UNO API and DOCX
filter is updated in this commit. The ODT filter works without explicit
effort. Other filters are not yet updated in this commit.
Change-Id: I723e1bdb8dc6391129f1686f88826cc089f6fd67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135462
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
blind fix
Change-Id: I79405cf36ce664024626ca7f348885a3dc91a593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135304
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
assert was introduced in
commit e1972743d692c8d8611912c31aae2cb08ae7636d
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Sun Sep 5 15:01:44 2021 +0200
be more disciplined with SetUpdateLayout on editengine
We want to restore UpdateLayout when we're done doing layout, we should
not just leave it FALSE
Change-Id: Ic0431ffc3c66d0d02bfd10c323b18383f52dbc95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Revert "tdf#132740 bypass work if selection has not changed"
This reverts commit 865641047be4a693f7a51635ce06eab15675126d.
Change-Id: I69244a1e57ce979bf21946e31df7165f8791423c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Revert
commit 60d35f767781de4b8f1e7b264b12015f655c647d
tdf#132740 don't broadcast if modified status has not changed
Change-Id: I5a0292499522e21708a2d5607966e4c2b3a18ba0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135301
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found with the help of a temporary loplugin (which i have put into the
store/ folder)
Change-Id: Ide40d09bef6993ace50039a8fd0439b7e29c09a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135288
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add hyphenation zone support, i.e. allow the specified
amount of extra space in lines instead of forcing hyphenation.
It's for limiting hyphenation, used especially with
not justified paragraph alignment.
Note: this is an OOXML interoperability feature,
used also in DTP software and CSS.
* Add checkbox to Text Flow in paragraph dialog
* Store property in paragraph model (com::sun::star::style::ParagraphProperties::ParaHyphenationZone)
* Add ODF import/export
* Add ODF unit test
* Add layout test
Note: extend SvxHyphenZoneItem::GetPresentation() with
missing No CAPS and No last word hyphenation options.
Note: fix OSL_ENSURE condition in SwTextFormatInfo::GetHyphValues().
Follow-up to commit 29359fc15c435cec17987fd6221ab6833d38746e
"tdf#149324 sw offapi xmloff: add option to not hyphenate short words".
Change-Id: Ib8eff6ea98a9aa5ca6cb9d17faa0bbb789687ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135247
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
to speed up operations when iterating over SfxItemSets
Change-Id: Ie40327ffaf7faa801ccc12d2b05c546a7fe49802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135079
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
