Several parts of SvxLRSpaceItem appear to maintain an invariant of the
3 members nTxtLeft/nLeftMargin/nFirstLineOffset: nLeftMargin is either
equal to nTxtLeft if nFirstLineOffset is positive, otherwise equal to
nTxtLeft + nFirstLineOffset.
But not every part maintains it: there are functions SetLeftValue() and
SetLeft() which simply write into nLeftMargin regardless, and a
constructor that takes 3 separate numbers without any checks.
The constructor calls violate the invariant in 2 ways: nTxtLeft is
simply set to 0 (many cases), and one case in OutlineView::OutlineView()
that sets nTxtLeft to 2000 but the other 2 at 0.
Another odd thing is that the UNO services that expose SvxLRSpaceItem
either expose a property for MID_L_MARGIN or for MID_TXT_LMARGIN but
never both.
It looks like there are 2 distinct usages of SvxLRSpaceItem:
for anything that's applied to paragraphs, all 3 members are used;
for anything else, nTxtLeft is unused.
Try to simplify this by removing the nTxtLeft member, instead
GetTextLeft() simply calculates it.
Also assert in SetLeftValue()/SetLeft() that nFirstLineOffset is 0.
Change-Id: Ida900c6ff04ef78e92e8914beda1cc731a695b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146643
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Adds a unified UNO property for theme colors *ColorTheme
(CharColorTheme and FillColorTheme) which uses XThemeColor, that
replaces the properties *Theme, *TintOrShade, *LumOff, *LumMod.
The properties are still present for backwards compatibility and
to keep ODF support working in tests as that needs a bigger change.
Reactor the code and tests to accomodate for this change.
Change-Id: If7983decb4ba528b49fe7b5968aa9efc696a9efc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144783
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Added a new component docmodel, that has the document model types,
which only depend on other basic components. This is needed so the
types can be used in every relevant component - xmloff, oox, svx,
editeng,...
Introduces model::ThemeColor, which is a class used to store the
theme color data, including transformations (svx::Transformation).
For UNO use XThemeColor is added, and the implementation UnoThemeColor
which wraps svx::ThemeColor, so it can be tranported around.
Reactor all the code and tests to accomodate for this change.
Change-Id: I7ce6752cdfaf5e4d3b8e4d90314afa469dd65cfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144847
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Cursor invalidation message shouldn't carry a hyperlink info to online
side if there is no hyperlink under the cursor
Change-Id: Ibdb6e32d029e101212d03bc117a5a14a712822ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143986
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
The nodes in mpIMEInfos may be deleted in ImpEditEngine::Clear() which causes a crash in the CommandEventId::ExtTextInput and CommandEventId::EndExtTextInput event handlers.
This crash occurs on Windows or macOS using the following steps:
- Enter uncommitted text (enter "aaa" with a Japanese Hiragana input method) in a comment in a Writer document
- Switch to another empty Writer document without committing the text in the first Writer document
- Switch back to the first Writer document
The above steps may need to be repeated a few times but it will eventually crash with the following stack trace:
(lldb) bt 25
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #0: 0x00000001b928ad98 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001b92bfee0 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x00000001b91fa340 libsystem_c.dylib`abort + 168
* frame #3: 0x00000001b91f9754 libsystem_c.dylib`__assert_rtn + 272
frame #4: 0x000000010374a09c libeditenglo.dylib`ImpEditEngine::ImpRemoveParagraph(this=0x000000011a684e00, nPara=-2147483648) at impedit2.cxx:2512:5
frame #5: 0x0000000103739658 libeditenglo.dylib`ImpEditEngine::ImpDeleteSelection(this=0x000000011a684e00, rCurSel=0x000000016fdf7250) at impedit2.cxx:2473:9
frame #6: 0x0000000103739328 libeditenglo.dylib`ImpEditEngine::DeleteSelected(this=0x000000011a684e00, rSel=0x000000016fdf7250) at impedit2.cxx:259:19
frame #7: 0x000000010373aac4 libeditenglo.dylib`ImpEditEngine::Command(this=0x000000011a684e00, rCEvt=0x000000016fdf7698, pView=0x0000600000169e10) at impedit2.cxx:408:24
frame #8: 0x0000000103721744 libeditenglo.dylib`ImpEditView::Command(this=0x00000002e3f8b7b0, rCEvt=0x000000016fdf7698) at impedit.cxx:1757:41
frame #9: 0x00000001036d7df4 libeditenglo.dylib`EditView::Command(this=0x0000600000169e10, rCEvt=0x000000016fdf7698) at editview.cxx:495:26
frame #10: 0x000000010b1d2420 libsvxlo.dylib`WeldEditView::Command(this=0x0000600002b11e30, rCEvt=0x000000016fdf7698) at weldeditview.cxx:312:23
frame #11: 0x00000002ea78dd50 libswlo.dylib`sw::sidebarwindows::SidebarTextControl::Command(this=0x0000600002b11e30, rCEvt=0x000000016fdf7698) at SidebarTxtControl.cxx:461:26
frame #12: 0x000000011656f3d4 libvcllo.dylib`weld::CustomWeld::DoCommand(this=0x000060000016a740, rPos=0x000000016fdf7698) at customweld.cxx:93:32
frame #13: 0x000000011656ee7c libvcllo.dylib`weld::CustomWeld::LinkStubDoCommand(instance=0x000060000016a740, data=0x000000016fdf7698) at customweld.cxx:91:1
frame #14: 0x0000000115ca1dd4 libvcllo.dylib`Link<CommandEvent const&, bool>::Call(this=0x00000002e3f8bc48, data=0x000000016fdf7698) const at link.hxx:111:45
frame #15: 0x00000001165b1658 libvcllo.dylib`SalInstanceDrawingArea::CommandHdl(this=0x00000002e3f8bb50, rEvent=0x000000016fdf7698) at salvtables.cxx:6473:26
frame #16: 0x00000001165af588 libvcllo.dylib`SalInstanceDrawingArea::LinkStubCommandHdl(instance=0x00000002e3f8bb50, data=0x000000016fdf7698) at salvtables.cxx:6471:1
frame #17: 0x0000000115ca1dd4 libvcllo.dylib`Link<CommandEvent const&, bool>::Call(this=0x00000002e3f90208, data=0x000000016fdf7698) const at link.hxx:111:45
frame #18: 0x0000000115d047d0 libvcllo.dylib`VclDrawingArea::Command(this=0x00000002e3f90080, rEvent=0x000000016fdf7698) at layout.hxx:685:27
frame #19: 0x0000000115e2e2bc libvcllo.dylib`ImplCallCommand(pChild=0x000000016fdf77c8, nEvt=ExtTextInput, pData=0x000000016fdf77d8, bMouse=false, pPos=0x0000000000000000) at winproc.cxx:229:17
frame #20: 0x0000000115e34458 libvcllo.dylib`ImplHandleExtTextInput(pWindow=0x0000600002aa8930, rText=0x000000016fdf8290, pTextAttr=0x0000600000018710, nCursorPos=4, nCursorFlags=1) at winproc.cxx:1424:13
frame #21: 0x0000000115e30dc8 libvcllo.dylib`ImplWindowFrameProc(_pWindow=0x0000600002aa8930, nEvent=ExtTextInput, pEvent=0x000000016fdf8290) at winproc.cxx:2863:20
frame #22: 0x000000011b0424e0 libvclplug_osxlo.dylib`SalFrame::CallCallback(this=0x00000001378ffb40, nEvent=ExtTextInput, pEvent=0x000000016fdf8290) const at salframe.hxx:306:29
frame #23: 0x000000011b0ef8f4 libvclplug_osxlo.dylib`-[SalFrameView setMarkedText:selectedRange:replacementRange:](self=0x00000002c4b0d980, _cmd="setMarkedText:selectedRange:replacementRange:", aString="嗚呼嗚呼", selRange=location=4, length=0, replacementRange=location=9223372036854775807, length=0) at salframeview.mm:1595:18
frame #24: 0x00000001bc8d6a2c AppKit`-[NSTextInputContext(NSInputContext_WithCompletion) setMarkedText:selectedRange:replacementRange:completionHandler:] + 168
Change-Id: I500824967d56232272041f8a2b972cdb2c9fe05c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143806
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Regards German and some other languages. A bug in the mechanism to distingish between apostroph and single end quote is solved.
Now, it works also for user defined quotes, like a single angle quote ('French' quote).
Change-Id: Ib4beca7a4304d57d7fdf977c20cf62410be3d2c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142662
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
we don't convert to the charsets we claim the fonts are in when
we write our text so rtf imports mangle this dubious output.
cheapest thing is to just write default fcharset0 for OpenSymbol
Change-Id: Iea0e0d3a9bda5b5c7bcffba8499195f50e214aa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142935
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d2249cd9adf5ae638577139177a50f7e62d8abd9>
"c++: Implement -Wdangling-reference [PR106393]" grew a new warning, included in
-Wall, and based on some more-or-less shaky heuristics, that warns about
"possibly dangling reference to a temporary". It produces quite a number of
false positives, but for these uses of SfxItemSet::Get it does look plausible
that the returned item references could, at least in theory, point at data that
is destroyed along with the temporary SfxItemSet.
Change-Id: I11afc4512db488f73170c6cfa706e9e094209550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142217
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This changes the nStretchX and nStretchY from sal_uInt16 to double
so the text in text boxes is rendered correctly (text should be
resized to the same size as the textbox).
Change-Id: Ic92d03043af0abe86f1b67ae15522d0176ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142064
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Params are swapped since
commit 190cd40e01 (HEAD, master)
Date: Tue Oct 18 21:14:41 2022 +0200
editeng: don't use GetSize to set the size
Change-Id: I0a3fce0c8325fa59c385fa2e45a53215853e351a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142077
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
* Specification: ISO 14289-1:2014, Clause: 7.18.5, Test number: 2
Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3.
These links are created all over the code, in some cases it's a bit
dubious what the content/alt-text should be, but let's try to use the
most suitable looking bit of text in whatever the context is.
* Specification: ISO 14289-1:2014, Clause: 7.18.3, Test number: 1
Every page on which there is an annotation shall contain in its page dictionary the key Tabs, and its value shall be S.
Change-Id: I7b63feb759f0c75047f854ed9997918f829a537e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141826
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
A tag with script could be added for which we don't have locale
data but for the same language in another script. Do not fall back
to that.
With that the share/autocorr/acor_zh-{CN,TW}.dat files created
additional Asian language listbox entries
"Chinese (Simplified, China) {zh-Hans-CN}"
"Chinese (Traditional, Taiwan) {zh-Hant-TW}"
because those are the canonicalized language tags.
Prefer the known legacy zh-CN and zh-TW tags instead.
Could also had happened with any document import.
Which again revealed a flaw in the handling of mapping overrides
where converting from a LanguageType LCID to Locale could yield a
different mapping than from BCP47 to LCID, which in the case of
a fallback for locale data lead to odd side effects.
Change-Id: I1e2aaa8e9f99b6b3bc2c9a661215cb00bddd33d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140939
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
There was a typo in the check, and we also want to fallback to using
blanks if no Kashidas were found, so check for Kashida positions first.
Change-Id: I64cc3bf5c76ecc01764073bb5a2302520157fad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140896
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
This uses the same caret positioning array introduced in:
commit 8cb4db941f
Author: Khaled Hosny <khaled@aliftype.com>
Date: Fri Aug 26 22:20:55 2022 +0200
tdf#30731: Improve caret travelling in Writer
But unlike the Writer change, this is used unconditionally not only when
calculating caret (cursor) position. This might break something, so lets
find out.
Change-Id: Ia285197b7ee41f01ccd37101436be86b476c0272
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140557
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
Commit 7e23cbdbb6 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>
With 16k column support in Calc enabled by default in
commit 4c5f8ccf0a
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>
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>
Michael Stahl