replace the home grown 16.16 fixed math with an alternative
Change-Id: If6fa4205aed62ff15157a8ab4dbf9b7c96e30216
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131236
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
and merge the contents of the old set_accessible_relation_labeled_by
into that so there's only the need to have one call.
Change-Id: I1c109fddd59219c4364103bf00d4d5b140bbdeab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131253
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Use `AccessibleGridControlTable::getAccessibleCellAt` and
cast to `AccessibleGridControlTableCell*` instead of
directly accessing the cell vector in
`AccessibleGridControl::commitCellEvent`.
`AccessibleGridControlTable::getAccessibleCellAt`
just needs row and column index as parameters,
and already takes care of everything else that's
needed.
This includes creating an accessible object for
the given indices on demand.
Therefore, limiting this to only already existing
a11y objects, which was done to avoid crashes in
commit 4fc7deb7b0
Date: Thu Oct 3 23:16:34 2013 +0200
fix STL assert in accessibility::AccessibleGridControl::commitTableEvent
is no longer needed.
With this change in place, details of how cells are
organized in the vector only need to be known inside
of the `AccessibleGridControlTable` class itself, so
drop the now unused method
`AccessibleGridControlTable::getCellVector`.
(This code path is e.g. used when using
the macro from tdf#147742.)
Change-Id: I21027f0edc2904475ad6cc5fb136316f387499dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131248
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When disposing `AccessibleGridControlTable` (which
is done in `AccessibleGridControl::disposing`),
also dispose its cells and clear the references.
Without this in place, a crash sometimes occured
when running the macro in the sample doc from
tdf#147742 several times and clicking around in the
table, with the Orca screen reader active.
This was because a reference to one of
the `AccessibleGridControlTableCell`s was still
around after the `AccessibleGridControlTable`
had already been disposed, and when trying
to get its accessible name, the call to
`IAccessibleTable::GetAccessibleObjectName` in
`AccessibleGridControlCell::getAccessibleName`
would fail because the object that the
`m_aTable` reference was referring to had already
been deleted.
With the cell being disposed as well, the
`ensureIsAlive()` check at the beginning of
`AccessibleGridControlCell::getAccessibleName`
will throw a `DisposedException`, that is then
handled properly in the calling code.
Backtrace (with master as of commit
2598c35dba):
#0 0x00007fffd9152ed3 in accessibility::AccessibleGridControlCell::getAccessibleName() (this=0x55555bbcdb70) at /home/michi/development/git/libreoffice/accessibility/source/extended/AccessibleGridControlTableCell.cxx:79
#1 0x00007fffe45e864a in wrapper_get_name(AtkObject*) (atk_obj=0x55555bbcef60) at /home/michi/development/git/libreoffice/vcl/unx/gtk3/a11y/atkwrapper.cxx:369
#2 0x00007fffe3a87e5c in () at /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
#3 0x00007fffe3a947de in () at /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
#4 0x00007fffe3a94caf in () at /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
#5 0x00007ffff75feff0 in () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#6 0x00007ffff75eea1c in dbus_connection_dispatch () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#7 0x00007fffe36d74a5 in () at /lib/x86_64-linux-gnu/libatspi.so.0
#8 0x00007fffe9ab8cdb in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007fffe9ab8f88 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007fffe9ab903f in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007fffe460f546 in GtkSalData::Yield(bool, bool) (this=0x55555567c750, bWait=true, bHandleAllCurrentEvents=false) at /home/michi/development/git/libreoffice/vcl/unx/gtk3/gtkdata.cxx:405
#12 0x00007fffe461402a in GtkInstance::DoYield(bool, bool) (this=0x55555567c5d0, bWait=true, bHandleAllCurrentEvents=false) at /home/michi/development/git/libreoffice/vcl/unx/gtk3/gtkinst.cxx:427
#13 0x00007fffef7ab4be in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /home/michi/development/git/libreoffice/vcl/source/app/svapp.cxx:474
#14 0x00007fffef7ac0b0 in Application::Yield() () at /home/michi/development/git/libreoffice/vcl/source/app/svapp.cxx:558
#15 0x00007fffef7ab18e in Application::Execute() () at /home/michi/development/git/libreoffice/vcl/source/app/svapp.cxx:452
#16 0x00007ffff7c309af in desktop::Desktop::Main() (this=0x7fffffffd780) at /home/michi/development/git/libreoffice/desktop/source/app/app.cxx:1604
#17 0x00007fffef7c9d75 in ImplSVMain() () at /home/michi/development/git/libreoffice/vcl/source/app/svmain.cxx:202
#18 0x00007fffef7c9e96 in SVMain() () at /home/michi/development/git/libreoffice/vcl/source/app/svmain.cxx:234
#19 0x00007ffff7c947c9 in soffice_main() () at /home/michi/development/git/libreoffice/desktop/source/app/sofficemain.cxx:98
#20 0x00005555555549f4 in sal_main () at /home/michi/development/git/libreoffice/desktop/source/app/main.c:51
#21 0x00005555555549da in main (argc=4, argv=0x7fffffffdaf8) at /home/michi/development/git/libreoffice/desktop/source/app/main.c:49
Change-Id: Idffa76809cbfad746f27d18191fdfc905b64ee0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131247
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's only used in one place and I see no need to keep
a Reference in this class, so use a local variable
instead of a class member.
Instead of disposing this single cell in
`AccessibleGridControl::disposing`,
`AccessibleGridControlTable` should take care
of disposing all of its cells, which will be
added in a following commit
(Change-Id Idffa76809cbfad746f27d18191fdfc905b64ee0e,
"Related: tdf#147742 a11y: Dispose table cells as well").
Change-Id: Ia7c84c65b45dde28850f48b12ab9558f2dc7d47c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131246
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Just call `AccessibleGridControlTable::getAccessibleCellAt`,
which already takes care of calculating the proper child index from
row and column index.
Change-Id: Id463c14108158c5833231f95cf16847764f5b646
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131245
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the handling for the
`AccessibleEventId::TABLE_MODEL_CHANGED` event of
type `AccessibleTableModelChangeType::DELETE`
from `AccessibleGridControl` into
`AccessibleGridControlTable`.
To do so, make `AccessibleGridControlBase::commitEvent`
virtual and override it in `AccessibleGridControlTable`.
The method already gets called from `AccessibleGridControl::commitTableEvent`
where the event was handled previously.
Handling the details of how cells are internally
organized in a vector only in the class itself
rather than in different places seems to make sense.
There are currently more cases where `AccessibleGridControl`
deals with the cell vector directly that will be
addressed in following commits.
Change-Id: I26a7737432ecb198eac00279a8242d22e3c661d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131244
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Regression from 33c9bc0225 (PDF export of
PDF images: preserve hyperlinks, 2022-01-07), the problem was that we
want to preserve hyperlinks, but annotations are added by the PDF export
explicitly, so it isn't a good idea to "preserve" them as well.
Fix the problem by going back to the old behavior, except when the
annotation sub-type is /Link.
This keeps hyperlinks working but doesn't lead to duplicated comments
when re-exporting an image + adding comments explicitly.
Change-Id: I910990da59bdc1150cc346f1a5471cb6da55dd2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131243
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
via gtk_test_accessible_check_property which seems to work for my needs
though maybe not what its intended for
Change-Id: I9fc0296edd7ad2459cab7d6bafae66e220b422dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131241
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The problem (which only reproduces here on copy/paste with
SAL_USE_VCLPLUGIN=kf5, not with gtk3) is that on SwTextFrame 2638 in a
footnote on page 19 containing "Saeed, 100–101." there should be a top
margin of 0 but it's actually 144.
The footnote was initially created on a previous page with another
footnote with SwTextFrame 2635 before it, that's how it got this top
margin.
Invalidate the print area in SwFootnoteFrame::Paste(), which is called
when the footnote is moved to a different container.
(somehow regression from commit 723728cd35)
Change-Id: I7346fd03fccad3eddccbbcd56c4b50127a337b24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131217
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Currently the PDF writer treats URIs that are rejected by INetURIObject,
as local files, and prepends a path to them. For URIs that are valid
according to the basic URI syntax, but unhandled by INetURIObject
(such as http://user:password@domain) this produces a confusing result
with a ./uri in the PDF.
Avoid the prefixing where the URI follows the basic URI syntax, even
if INetURIObject didn't like it.
Change-Id: I87c599885a40fd7101c678ae79f83f594d0f23ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125202
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
Set relativeFsys on a per-test basis and add a test with
relativeFsys off.
Change-Id: I43b1d82200aca37b2cf8ac71d77a4aa61df543ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130197
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The documented precondition is that index must not be greater than
the length of string. Just assert that, and fix the found misuse.
The added test is for in-place replacement, just in case.
Change-Id: I3c545a6f0bf913fe93e2bef83ce733359c193065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131232
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Commit 1be170d062 tweaked the checked
background rectangle to be 1 pixel shorter, to address the asymmetric
vertical position of the rectangle on Windows, where toolbox button
draw (used for the checked image state on menu) has 1 pixel smaller
height than requested; but that seems incorrect. The native checkmark
is drawn on e.g. 22 pixel high rectangle, while image background was
20 pixel high after the abovementioned change.
So instead of making top a bit lower, keep it as it was (aligned with
the top of the menu item), and move its bottom 1 pixel down, to align
with menu item's bottom.
Change-Id: Ie1846061bf16fb8bb3ccf2ae1651c8b83b5b1283
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131174
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It's a field but unlike other fields uses CH_TXTATR_INWORD so it
probably shouldn't break words.
Change-Id: If14ac24ec3e7eee15d67f91a0e2b17ab2c2637cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131216
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem is that SwEditShell::GetCorrection() uses the SwTextNode
text without filtering redlines.
Using ExpandMode::ReplaceMode should work as it will replace
CH_TXTATR_INWORD with nothing and CH_TXTATR_BREAKWORD with ZWSP.
Unfortunately there isn't yet a mode that can handle fieldmarks as they
are displayed in the layout.
Change-Id: Ia243d90309fdd7b6ca159c5df2f4d98725400c5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131210
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This can cause:
soffice.bin: sw/source/core/undo/undobj.cxx:1486: static void SwUndo::SetSaveData(SwDoc&, SwRedlineSaveDatas&): Assertion `rSData.empty() || rSData[0].m_bRedlineMoved || (rSData[0].m_nRedlineCount == rDoc.getIDocumentRedlineAccess().GetRedlineTable().size())' failed.
When one character in middle of Format redline is deleted, then Undo.
The condition is quite odd and apparently from initial CVS import; try
to copy condition for merging Insert redlines instead.
Change-Id: Ib56e12914269b878c16813b9e95b2f0df3330bbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131208
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Need to do this in two passes, because a clearing line break is a text
attribute, but the DOCX markup is not a run property, so can only write
it once the run properties are finished.
Change-Id: I74e94dbd02ca4e6ceee0439c5eafd3c3bbe2264b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131231
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Can use CPPUNIT_TEST_FIXTURE() instead.
See commit a226cec52e
(CppunitTest_sw_rtfimport: convert one testcase to use
CPPUNIT_TEST_FIXTURE(), 2019-11-05) for motivation.
Change-Id: Idcd5b5a2171d9e261f614bbdc1ca69b7feb9fa01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131223
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
All tests pass now, and I've also handled all significant bugreports
from tdf#133764. This commit is mainly meant to test this more
in practice and collect feedback. Depending on how this turns out,
there may be a backwards compatibility option or something similar,
but so far I see no significant need for it.
Change-Id: I1a946f4e0b51be5acf4e25dc773e7694c2b17b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131180
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It should not attempt to dereference pointers when nIndex is negative.
Properly handle too large nIndex.
Also it is not necessary to parse the string when nToken is negative.
Related to commit be281db569
Author Rüdiger Timm <rt@openoffice.org>
Date Mon Sep 20 07:43:20 2004 +0000
INTEGRATION: CWS ause011 (1.18.22); FILE MERGED
2004/08/18 11:47:54 sb 1.18.22.1: #i33153# Made getToken more robust.
Change-Id: I6fc77a5b70308ccca08cb2132bd78d024bd7e3e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131221
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
when a text selection is present.
Change-Id: Icef331334a8ad7a499477860c6d883f26e909577
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131158
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
This extends 582fc887f1, first
check if there is any named range that could possibly conflict (which
generally should be rare).
Change-Id: Ia5e9e56cab29b459bcb489e871b4960ba215b665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131219
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
seen in: make UITest_sort UITEST_TEST_NAME="tdf105301.tdf105301.test_tdf105301"
with the fix for tdf#147722 which resulted in the first few rows
scrolled out of view and GetDisplayText() then returning nothing
Change-Id: Id833a6b5029a490b08e730c641bf9dcdea627b5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131220
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The user interface is loaded in the user's language
at the first use of Scriptforge during the LO session.
So far the labels were always loaded from the relevant
.po file.
Now they are loaded in memory by code when the user's
language = "en".
Objective = gain in performance.
Additionally the default language is set to
SF_Platform.OfficeLocale
i.o.
SF_Platform.SystemLocale
Internal change, no impact on documentation
Change-Id: Ia0d1235f8ca6a42141a5481fe80b5bec1d53a7e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131214
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
In some cases the widgets are in frames now so that hierarchical
relationship is captured already. In others labelled-by is a better
match and/or is already labelled by the widget.
Change-Id: Ifecd0eb96afecadbd66fcfdf843ce1590f5c5ff4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131185
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
With dynamic columns it is possible for it to be called
for unallocated columns, and those can't be merged.
Change-Id: If4a365ba175b9ea7e68704bb4db85a30e5f8a0db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131211
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
