reproduce by loading ooo59043-1.odt and exporting it to the binary doc
format, which toggles the tracked-change display.
that save-time show and hide joins and splits the text nodes, and can
leave the spell wrong list with an invalid end past the now shorter
text.
the idle autospell then maps that end and asserts, here with nIndex 15
on a 12 char node:
soffice.bin: sw/source/core/text/txtfrm.cxx:1344:
Assertion `nIndex <= pNode->Len()' failed.
#4 sw::MapModelToView (nIndex=15) at txtfrm.cxx:1344
#5 SwTextFrame::MapModelToView (nIndex=15) at txtfrm.cxx:1385
#6 lcl_CalculateRepaintRect (nChgStart=0, nChgEnd=15) at txtedt.cxx
#7 SwTextFrame::AutoSpell_ at txtedt.cxx:1519
#8 SwLayIdle::DoIdleJob_ (ONLINE_SPELLING) at layact.cxx:2171
#9 SwLayIdle::DoIdleJob at layact.cxx:2312
#10 SwLayIdle::SwLayIdle at layact.cxx:2573
#11 SwViewShell::LayoutIdle at viewsh.cxx:927
#12 sw::DocumentTimerManager::DoIdleJobs at DocumentTimerManager.cxx:179
AutoSpell_ already tolerates the over-long end, set with std::max
against the text length a few lines up, and the word scanner stops at
the real end.
so clamp the repaint range the same way before it is mapped.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I5ad086753f8b3fc0f838a45a7291cd62a4d4a343
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6699
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1920f81f2df779c9787256c9ad93903640817419)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210508
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
By now, almost all a11y implementations implement both,
the XAccessible and XAccessibleContext interfaces themselves,
and they do so via the OAccessible base class.
One remaining case that only implements the XAccessible interface
directly is UnoControl. XAccessible::getAccessibleContext
is used from within AccessibleControlShape::Init to get the
accessible context. That accessible context however
is an OAccessible and implements both, the XAccessible
and XAccessibleContext interfaces again.
Stop requiring that UnoControl implements XAccessible
by instead adding a dedicated new method UnoControl::getAccessible
to directly get the OAccessible without relying on
the XAccessible interface being implemented by UnoControl.
In AccessibleControlShape::Init, cast to UnoControl
instead of querying for the XAccessible interface
and call the new method directly.
Stop implementing the XAccessible interface in
UnoControl as it is no longer needed now.
This aligns the UnoControl a11y logic more with how
a11y is implemented elsewhere across the code base.
Sample steps to trigger the modified code
when using the gtk3 vcl plugin on Linux:
* start the Orca screen reader
* start Writer
* insert a few push button controls using
"Form" -> "Push Button" and then clicking into
the document and dragging to insert
* disable design mode using "Form" -> "Design Mode"
* focus one of the controls by clicking on it
* press the Tab key to move focus between the controls
No differences in behavior were observed when
doing this with or without this change in place.
Side note: Announcement of the controls when they
receive focus didn't work (reliably) when opening an
existing document containing form controls instead of
inserting them into a new one, but that is preexisting
and unrelated to this commit.
Also adjust test AccessibleFixedTextTest::testFixedText
of the CppunitTest_toolkit_a11y test suite
accordingly that was assuming that it can
query the XAccessible interface directly
from the UNO control.
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The UndoManager Java UNO test is currently making use of the
XAccessibleAction interface in order to press a button programatically.
In order to retrieve the accessible, it was querying the
UnoControl (via its UNO interfaces) for the XAccessible
interface, then getting the associated XAccessibleContext.
This relies on the implementation detail that UnoControl
implements the XAccessible interface, which will no longer
be the case after upcoming commit
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Sep 3 15:55:32 2026 +0200
a11y: Get UnoControl accessible without implementing XAccessible
Therefore, stop relying on this implementation detail.
Ideally, accessibility implementation details shouldn't be used
at all. But for now, in a first step and in order to not have to rework
more logic now, switch to retrieving the XAccessible for/from the window
peer instead, using the mechanism introduced in
commit d1a25112bb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 18 17:49:48 2025 +0200
java a11y tests: Don't rely on XWindow being XAccessible
Change-Id: I4817bd7efa8a6ed57a514b3e4fecf3d6545fbc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210487
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
ODF has no name for this chart type, so the file says two things at once, the
way a histogram already does: chart:class names the scatter chart, which is the
nearest a reader that knows nothing of correlation circles can make of it, and
coext:class beside it names the type itself. A reader that knows the coext name
gets the chart back as it was saved.
The series need no new shape in the file. The feature column is the range of
the series and the two dimension columns are a domain each, which is where a
bubble chart already keeps its x and y values, so both the reading and the
writing of them follows the bubble path rather than a new logic.
The schema the tests validate against lists the values coext:class may take, so
the new one is added there beside the histogram.
The test document is one block of five columns: three features and then the two
dimensions, the shape the wizard asks for. The test checks after a round trip
that the chart type came back, that the file carries both class names, and that
every series still holds its feature column beside the two dimension columns.
Change-Id: Iac73ff357c7490b4f38a4390c63948cf148d8585
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8106
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 4e59ea1c83e61b8dc2647f9a915884f9d461165d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210498
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
as part of the process of merging the Outliner code into the normal EditEngine paths.
So instead of keeping a bunch of information "on the side" and then having to merge information
from multiple sources, it all lives where it logically belongs.
Also take the chance to rename the depth/getdepth/setdepth
fields and methods to NumberingDepth, which makes the purpose
more obvious.
Change-Id: I314673ee1b9efa14f178ac34a122995a554cd788
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10551
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 284bbe0af12b96844976f30bb35ade3a327ea76d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210503
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
If the parent widget already has a layout, then creating a new
widget and passing the parent in the widget's constructor will
add the widget to the layout. If the widget is later added
to the layout again, it will be removed from the layout and
re-added. This is unecessary.
Change-Id: I64e27080a1546e126dfc8ee57d3e1e558574d6a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206477
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
...at
> engine/sc/source/ui/unoobj/chart2uno.cxx:1622:20: runtime error: downcast of address 0x7c6579dde660 which does not point to an object of type 'ScDoubleRefToken'
> 0x7c6579dde660: note: object is of type 'ScExternalDoubleRefToken'
> 00 00 00 00 b0 11 4e 1b f5 7b 00 00 00 00 13 00 01 00 00 00 00 00 be be be be be be 80 16 8d 79
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'ScExternalDoubleRefToken'
> #0 in (anonymous namespace)::InsertTabNumber::operator()(boost::intrusive_ptr<formula::FormulaToken> const&) const at engine/sc/source/ui/unoobj/chart2uno.cxx:1622:20
> #1 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag> std::__for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber&) at ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/bits/stl_algo.h:159:6
> #2 in (anonymous namespace)::InsertTabNumber std::for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber) at ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/bits/stl_algo.h:3846:7
> #3 in ScChart2DataProvider::detectArguments(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSource> const&) at engine/sc/source/ui/unoobj/chart2uno.cxx:1961:16
> #4 in non-virtual thunk to ScChart2DataProvider::detectArguments(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSource> const&) at engine/sc/source/ui/unoobj/chart2uno.cxx
> #5 in oox::drawingml::ChartExport::getSplitCategoriesList(rtl::OUString const&) at engine/oox/source/export/chartexport.cxx:723:106
> #6 in oox::drawingml::ChartExport::exportSeriesCategory(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSequence> const&, int) at engine/oox/source/export/chartexport.cxx:4498:89
> #7 in oox::drawingml::ChartExport::exportSeries_chart(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&, cpo::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::chart2::XDataSeries>> const&, bool&) at engine/oox/source/export/chartexport.cxx:4048:21
> #8 in oox::drawingml::ChartExport::exportAllSeries(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&, bool&) at engine/oox/source/export/chartexport.cxx:3881:5
> #9 in oox::drawingml::ChartExport::exportPieChart(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&) at engine/oox/source/export/chartexport.cxx:3687:5
> #10 in oox::drawingml::ChartExport::exportPlotArea(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool) at engine/oox/source/export/chartexport.cxx:2932:33
> #11 in oox::drawingml::ChartExport::exportChart(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool) at engine/oox/source/export/chartexport.cxx:2302:5
> #12 in oox::drawingml::ChartExport::exportChartSpace(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool, bool) at engine/oox/source/export/chartexport.cxx:1570:5
> #13 in oox::drawingml::ChartExport::ExportContent_(bool) at engine/oox/source/export/chartexport.cxx:1480:9
> #14 in oox::drawingml::ChartExport::ExportContent() at engine/oox/source/export/chartexport.cxx:1457:5
> #15 in oox::drawingml::ChartExport::WriteChartObj(com::sun::star::uno::Reference<com::sun::star::drawing::XShape> const&, int, int) at engine/oox/source/export/chartexport.cxx:1273:5
> #16 in XclExpChartObj::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/excel/xeescher.cxx:1897:22
> #17 in (anonymous namespace)::SaveDrawingMLObjects(XclExpObjList&, XclExpXmlStream&) at engine/sc/source/filter/xcl97/xcl97rec.cxx:304:16
> #18 in XclExpObjList::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/xcl97/xcl97rec.cxx:414:5
> #19 in XclExpRecordList<XclExpRecordBase>::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/inc/xerecord.hxx:386:21
> #20 in ExcTable::WriteXml(XclExpXmlStream&) at engine/sc/source/filter/excel/excdoc.cxx:717:14
> #21 in ExcDocument::WriteXml(XclExpXmlStream&) at engine/sc/source/filter/excel/excdoc.cxx:918:44
> #22 in XclExpXmlStream::exportDocument() at engine/sc/source/filter/excel/xestream.cxx:1163:18
> #23 in oox::core::FilterBase::filter(cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/oox/source/core/filterbase.cxx:500:83
> #24 in oox::xls::ExcelFilter::filter(cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sc/source/filter/oox/excelfilter.cxx:200:27
> #25 in SfxObjectShell::ExportTo(SfxMedium&) at engine/sfx2/source/doc/objstor.cxx:2743:25
> #26 in SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) at engine/sfx2/source/doc/objstor.cxx:1853:19
> #27 in SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objstor.cxx:3263:39
> #28 in SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objstor.cxx:3051:20
> #29 in SfxObjectShell::APISaveAs_Impl(std::basic_string_view<char16_t, std::char_traits<char16_t>>, SfxItemSet&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objserv.cxx:329:19
> #30 in SfxBaseModel::impl_store(rtl::OUString const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) at engine/sfx2/source/doc/sfxbasemodel.cxx:3247:42
> #31 in SfxBaseModel::storeToURL(rtl::OUString const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/sfxbasemodel.cxx:1830:13
> #32 in UnoApiTest::save(TestFilter, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&, char const*) at engine/test/source/unoapi_test.cxx:386:16
> #33 in testCool14390_ChartExternalRef::TestBody() at engine/sc/qa/unit/subsequent_export_test4.cxx:881:5
apparently caused by 003c0007c13e443fe4e520d1b70586266abf7811 "reduce
Sc*Ref*Token virtual calls". Now using the helper that was introduced there.
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: I3e1c82e8069cb03af29e8dc260017fc3e867f72b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11014
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 3797f2792490a1c114ce0a80db2d544bce08670b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210500
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This means that native Qt widgets are used for this dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
The dialog can e.g. be triggered following the steps
described in tdf#173243:
* open attachment 208203 from tdf#173243
* use "Data" -> "Pivot Table" -> "Insert or Edit..."
and confirm "Current Selection" to trigger the
"Pivot Table Layout" dialog
* drag "Date" to row fields, "Value" to data fields.
* drag another "Value" to data fields and double-click it
Change-Id: If442498741a2f22a8960bdd7acb7314e329f3f8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210486
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The dialog can e.g. be triggered following the steps
described in tdf#173243:
* open attachment 208203 from tdf#173243
* use "Data" -> "Pivot Table" -> "Insert or Edit..."
and confirm "Current Selection" to trigger the
"Pivot Table Layout" dialog
* drag "Date" to row fields, "Value" to data fields.
* drag another "Value" to data fields and double-click it
Change-Id: Id13a2cbca2d407e40bf0885ee82650aa0a366e17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210485
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
commit c54f872f50
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 9 09:00:54 2026 +0200
sc: Use activated row param in ScPivotLayoutTreeListData::DoubleClickHdl
had switched from passing an int by value to
passing a weld::Entry by ref to the lambda
function in ScPivotLayoutTreeListData::DoubleClickHdl.
Since that function is run asynchronously, this can
result in the weld::TreeIter passed to
ScPivotLayoutTreeListData::DoubleClickHdl
already having been deleted by the time it's
accessed in that lambda function.
Create a copy of the iterator held by a std::shared_ptr
and pass that one by value to avoid/fix the issue.
Change-Id: I2387aca5eb5d572d0e6a551589c07a6c683185f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210483
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A correlation circle plot reads the ends of its range differently from every
other chart type: the last two columns are the dimensions its points are placed
against and the columns before them are the features. One range holds the lot,
so nothing about the entry gives that away, and a reader who does not already
know it has no way to work it out.
Display a information label under the range input saying the last two
columns of it are component dimensions and the columns before that are
features.
Change-Id: Ib7d27aad189f12be188f61b1fc317dd1e718b803
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8105
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2cbf62e18df956ed23c77932cd5e38424e7baa1f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210470
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
There are two rules for which node of a merged paragraph provides the
paragraph properties. The classic rule takes the first node that has
visible text.
Under the classic rule, when SwContentNode::DelFrames deletes the
properties node and it is also the last node, no node has visible text
left, so the merge must be empty. An assert checks that, and it always
held until:
commit 0849ddd0b1
Date: Wed Oct 8 19:29:46 2025 +0200
sw: text formatting: implement per-line paragraph properties like Word
which added the second rule: with a hidden paragraph mark the
properties node is the last node, even while earlier nodes still have
visible text. Now the same delete can happen while the merge still has
visible text, and the assert fires falsely.
So allow non-empty extents in hidden paragraph mode too. The existing
relocation loop already picks the correct new properties node under
both rules.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I599b0c09c92e5f9adaa1874a6de5a054eb947d8b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9281
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 29b5b72c31483af4585fe419ce1789b990c55c8e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210477
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The entry sits next to the bubble chart, under the same switch that keeps the
chart types wanting free x values out of the list where they do not belong. It
has one sub type, no three dimensional look and no stacking.
The two images are placeholders: a circle with a cross and a few arrows
out of the middle. They need a designer's hand before this ships.
A test drives the wizard the way a user would: it picks the type, types one
range whose last two columns hold the dimensions, and checks that every column
before them became a series holding that column beside the two dimension
columns. A second test reopens the ranges of that chart and checks the range
comes back as it was given.
Change-Id: If8b5275244a2456a22235a6ce2d3d51fcff6cb94
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8104
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7a7fc603047e065ebbc20f8bc5dc814d6079e082)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210469
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
As a natural extension of the "smart" hyphenation, following
traditional typography, prefer readability of the hyphenated
compound words and better word spacing in the following way:
* when it's possible to hyphenate the same compound word within
the custom word spacing range, choose compound splitting or
hyphenate just before the suffix or inside the suffix, not
inside a compound constituent.
* limit plain, i.e. non-compound-based smart hyphenation, when
it can results in better word spacing without losing readability:
do not disable hyphenation within the custom word spacing range, if
the hyphenation splits the compound word between its constituents;
* if also shrinking results in a non-compound splitting hyphenation
inside the second or third etc. constituent of a compound word,
always shrink the line to show bigger part of that non-first
constituent (within the custom word spacing range).
For these, extend lingucomponent HYPH_COMPOUND_MIN_LEADING and
HYPH_COMPOUND_MIN_TRAILING API to support disabling hyphenation of
non-compound words, also disabling hyphenation inside the first
constituent (but not inside the suffix or just before the suffix).
This allows to recognize compound words during line breaking.
Details: Hyphenator::hyphenate().
The initial development enables compound-based "smart" hyphenation
only for the Hungarian language, yet. The patch contains minor
fixes of the compound-based Hungarian hyphenation, resulting
better compound-based "smart" hyphenation with recognition of
verb prefixes and leg-/legesleg- superlative prefixes. (Note:
this fixed also COMPOUND_MIN_LEADING/TRAILING settings for the
hyphenation of the compound words with dictionary-based hyphenation
(only hy:, without pa: Hunspell dictionary fields, i.e. without
compound splitting heuristics of Hunspell).
Change-Id: I26f31329cdea20f03dbde7742587089eb5df5ae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210423
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Pass the more concrete OAccessible instead of a reference
to the abstract XComponent UNO interface.
Change-Id: Idcbf5c1eb09cc1380a85410b76d8b1e2df022b6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from using a weak reference (css::uno::WeakReferenceHelper)
to the abstract XAccessibleContext UNO interface to a weak
reference (unotools::WeakReference) of the more concrete
OAccessible class in UnoControl.
This makes clear that the accessible is always an OAccessible
subclass and allows dropping some UNO-querying for the
wanted UNO interfaces.
Change-Id: Ib1ea66c83da9bbf76891c492d84aa57c396f2f44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reuse existing OAccessible logic by subclassing it.
This aligns AccessibleTableHeaderShape with other
a11y implementations.
No user-visible change in behavior intended.
Sample steps to make use of the class on Linux with
the qt6 vcl plugin:
* start Impress
* use the "Insert" -> "Table" dialog to insert a table
* type something in some cells
* start Accerciser
* in Accerciser's tree view of LO's a11y hierarchy, navigate
to the a11y object of the table (which uses an a11y name of
"TableShape")
* use Accerciser's IPython console to interact with the table header:
In [6]: table = acc.queryTable()
In [7]: table_header_cell = table.getRowHeader(0)
In [8]: table_header_cell.get_name()
Out[8]: 'A1'
This matches the behavior without this change in place.
(The question of whether all of the semantics/logic implemented in
AccessibleTableHeaderShape makes sense as is is a separate question,
unrelated to this refactor.)
Change-Id: I15c6a19aaa4ae69085dd8cb3a53447e55bf096f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210456
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This reverts 27.2 commit 0a03f797bb.
Microsoft Office was unable to open any of the documents we produced
when the thumbnail was in PNG format.
It complains about corrupt content.
Change-Id: I9975374830459007bcf8cbda37ca9e0115eb74a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210471
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 24.2 regression from Khalid's commit 4b743de97f.
The problem I'm trying to fix is that setting optimal column width
is not necessarily providing enough width to avoid seeing '###'.
The reason is that GetOptimalColumnWidth calls GetTextWidth
with MapMode disabled, so no subpixel calculations were done.
However LayoutString does have MapMode enabled,
so it calculates a different length than what optimal column got.
Surely that must always be wrong. But Khalid's similarly more-correct
commit triggered a lot of 'regressions'. However, this should be
moving in the right direction as tdf#168002 suggests
that mbSubpixelPosition should always be true in the future.
Since it is needed for width, it seems reasonable that it should
also be done for height...
Change-Id: I30590ebba8b3027c5214ee075a1a258d3a61b8c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210438
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Recognize LAMBDA during dynamic array analysis; LAMBDA
never produces an array, but it can be part of a formula
that generates one.
* Fix handling of LET; subexpressions before the last should
not affect the result, unless we are willing to to a more
thorough analysis.
* Update test to check for the new behavior.
* Account for svExternalDoubleRef.
Change-Id: Ia9a4761079de986906ac70252066d8d9b4655f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210461
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Each series gives one arrow, from the origin to the point whose
1. x-coordinate value is the correlation of that series' feature column
with the first dimension column.
2. y-coordinate value is the correlation of that series' feature column
with the second dimension column.
A symbol marks the tip and the feature name sits beside it. The circle
of radius one and the two lines through the origin are drawn behind the
arrows, and both axes are held at minus one to one on a square plot
area, so a length in the picture means the same in both directions and
the circle stays round.
The correlations are worked out while the shapes are made rather than kept
anywhere, so they follow the cells they come from. Working them out needs the
whole of the three columns.
The correlation coefficient code itself is in a small header of its own
with a test beside it. It leaves out the instances where either side is
missing, and it has no answer for a feature that does not vary or for
fewer than two instances. A feature without an answer gets no arrow,
as there is no direction to point in.
Error bars, trend lines and area properties are turned off for this chart
type, since a point stands for a worked out pair rather than for a value in a
cell, and symbols are turned on because the tip of each arrow carries one. The
arrows take the line colour and width of their series, and the template asks
for thin ones, which is what keeps a crowd of them apart. The legend hands out
the same symbol as the arrow tip, so a key can be matched to an arrow.
Grids are turned off by default for this chart as the user is more
interested in the direction/angles and the magnitude of the "rays" from
the origin.
Change-Id: I2d8b3aa6ef7d66bd9deb1f63a647767a1b62ac90
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8103
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit e096bfee9c85a22e8b8155944a63ee9d6f72f75a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210465
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A correlation circle plot shows how each feature of a table relates to the
first two dimensions of a decomposition of that table, which a user can now
work out in a spreadsheet with MSVD. One point per feature sits at the
correlation of that feature with the first dimension across and with the
second dimension up, inside a circle of radius one.
The data arrives as one series per feature. Each series holds its own feature
column under the new role values-feature, together with the two dimension
columns under values-x and values-y, which every series shares the way the
bubble chart shares its x column. Keeping the dimensions on the x and y roles
means the point count, the axis scaling and the label machinery need no
special case, and the series label comes from the feature column header, so
the legend and the point labels read as feature names.
The interpreter reads a flat list of columns as a feature table followed by
two dimension columns: the last two are the dimensions and every column before
them is a feature. One range holds the lot, which is what the wizard hands
over, and it is also the order the list comes in when a chart of another type
is turned into this one. A first column of instance names is kept out of the
features when the range says it has them, as it is for a bubble chart.
Both dimensions are numbers running from minus one to one, so the chart type
joins the scatter and the bubble chart in asking for a numeric axis across.
That answer is also what turns the axis of names back into a numeric one when
a chart of another type becomes this one, since the coordinate system the
other type left behind is kept and reused.
Change-Id: Id17d3a2a235c849c3dab9768159ddf1608da6d05
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8102
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit b30d992bba26428941f47f952baf338df3763065)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209379
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Caolán McNamara