[Libreoffice-bugs] [Bug 147278] Strings without Spanish translation in Context Menu - Spelling correction.
https://bugs.documentfoundation.org/show_bug.cgi?id=147278 --- Comment #2 from Albert Acer --- 1.042 / 5.000 Resultados de traducción This occurs when a user, whose native language is Spanish, types a word with a misspelling, for example "targeta", and then that same user tries to correct that word using LO Writer's spell correction utility. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: chart2/source
chart2/source/controller/chartapiwrapper/DataSeriesPointWrapper.cxx |2
chart2/source/controller/chartapiwrapper/MinMaxLineWrapper.cxx | 27 +-
chart2/source/controller/dialogs/DataBrowser.cxx| 20 --
chart2/source/controller/dialogs/DataBrowserModel.cxx | 92
--
chart2/source/controller/dialogs/DataBrowserModel.hxx |7
chart2/source/controller/dialogs/DialogModel.cxx| 19 +-
chart2/source/controller/dialogs/DialogModel.hxx|2
chart2/source/controller/dialogs/ObjectNameProvider.cxx | 11 -
chart2/source/controller/dialogs/tp_DataSource.cxx | 56
++
chart2/source/controller/dialogs/tp_DataSource.hxx |3
chart2/source/controller/inc/DataPointItemConverter.hxx |5
chart2/source/controller/inc/TextLabelItemConverter.hxx |5
chart2/source/controller/itemsetwrapper/DataPointItemConverter.cxx | 19 --
chart2/source/controller/itemsetwrapper/TextLabelItemConverter.cxx | 11 -
chart2/source/controller/main/ChartController_Insert.cxx| 16 -
chart2/source/controller/main/ChartController_Tools.cxx |2
chart2/source/controller/main/ChartController_Window.cxx|4
chart2/source/controller/sidebar/ChartSeriesPanel.cxx | 12 -
chart2/source/inc/ExplicitCategoriesProvider.hxx| 10 -
chart2/source/model/template/ChartTypeTemplate.cxx | 18 -
chart2/source/model/template/ColumnLineChartTypeTemplate.cxx|8
chart2/source/tools/AxisHelper.cxx | 22 --
chart2/source/tools/DataSeriesHelper.cxx| 23 +-
chart2/source/tools/DataSourceHelper.cxx|9
chart2/source/tools/DiagramHelper.cxx | 77
chart2/source/tools/ExplicitCategoriesProvider.cxx | 34 ++-
chart2/source/tools/InternalDataProvider.cxx|6
chart2/source/tools/ObjectIdentifier.cxx| 30 +--
chart2/source/view/charttypes/VSeriesPlotter.cxx|2
29 files changed, 269 insertions(+), 283 deletions(-)
New commits:
commit b314b5a0612c9dc7279039dae44a250d4d3ec6b1
Author: Noel Grandin
AuthorDate: Mon Feb 7 18:41:30 2022 +0200
Commit: Noel Grandin
CommitDate: Tue Feb 8 08:52:11 2022 +0100
use more concrete types in chart2, DataSeries
Change-Id: I80bc8961832a20c29b31f7618b9d2609f15ab3c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129642
Tested-by: Jenkins
Reviewed-by: Noel Grandin
diff --git
a/chart2/source/controller/chartapiwrapper/DataSeriesPointWrapper.cxx
b/chart2/source/controller/chartapiwrapper/DataSeriesPointWrapper.cxx
index c9ef38c82460..51c917751fbd 100644
--- a/chart2/source/controller/chartapiwrapper/DataSeriesPointWrapper.cxx
+++ b/chart2/source/controller/chartapiwrapper/DataSeriesPointWrapper.cxx
@@ -571,7 +571,7 @@ Reference< beans::XPropertySet >
DataSeriesPointWrapper::getDataPointProperties(
{
Reference< beans::XPropertySet > xPointProp;
-Reference< chart2::XDataSeries > xSeries( getDataSeries() );
+rtl::Reference< DataSeries > xSeries( getDataSeries() );
// may throw an IllegalArgumentException
if( xSeries.is() )
diff --git a/chart2/source/controller/chartapiwrapper/MinMaxLineWrapper.cxx
b/chart2/source/controller/chartapiwrapper/MinMaxLineWrapper.cxx
index e14993312dbb..8678d743957d 100644
--- a/chart2/source/controller/chartapiwrapper/MinMaxLineWrapper.cxx
+++ b/chart2/source/controller/chartapiwrapper/MinMaxLineWrapper.cxx
@@ -28,7 +28,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -155,8 +155,6 @@ uno::Reference< beans::XPropertySetInfo > SAL_CALL
MinMaxLineWrapper::getPropert
void SAL_CALL MinMaxLineWrapper::setPropertyValue( const OUString&
rPropertyName, const uno::Any& rValue )
{
-Reference< beans::XPropertySet > xPropSet;
-
rtl::Reference< ::chart::Diagram > xDiagram(
m_spChart2ModelContact->getDiagram() );
const std::vector< rtl::Reference< ChartType > > & aTypes(
::chart::DiagramHelper::getChartTypesFromDiagram( xDiagram ) );
@@ -164,20 +162,19 @@ void SAL_CALL MinMaxLineWrapper::setPropertyValue( const
OUString& rPropertyName
{
if( xType->getChartType() == CHART2_SERVICE_NAME_CHARTTYPE_CANDLESTICK
)
{
-Sequence< Reference< chart2::XDataSeries > > aSeriesSeq(
xType->getDataSeries() );
-if(aSeriesSeq.hasElements())
+const std::vector< rtl::Reference< DataSeries > > & aSeriesSeq(
xType->getDataSeries2() );
+if(!aSeriesSeq.empty())
{
-xPropSet.set(aSeriesSeq[0],uno::UNO_QUERY);
-if(xPropSet.is())
+
[Libreoffice-bugs] [Bug 147278] Strings without Spanish translation in Context Menu - Spelling correction.
https://bugs.documentfoundation.org/show_bug.cgi?id=147278 --- Comment #1 from Albert Acer --- Created attachment 178134 --> https://bugs.documentfoundation.org/attachment.cgi?id=178134=edit Screenshot 01 Screenshot 01 -- You are receiving this mail because: You are the assignee for the bug.
Re: Material preset "Metal" for extruded custom shapes
On 08.02.2022 10:30, Miklos Vajna wrote: On Mon, Feb 07, 2022 at 08:55:10PM +0100, Regina Henschel wrote: The attribute itself will be with prefix 'loext' till it is integrated in ODF. But what namespace prefix (and associated namespace) should I use for the value? I think, a meaningful prefix would be "loext" or "drawooo". My understanding is that we try to standardize on "loext" for all new ODF extensions, so that looks like a better option. Do we really use prefixes on attribute *values*? They are text, and I would expect their values to not be prefixed; the namespace is defined only on element and attribute level in XML, not on value. But maybe I misunderstand the problem? -- Best regards, Mike Kaganski
[Libreoffice-bugs] [Bug 147278] New: Strings without Spanish translation in Context Menu - Spelling correction.
https://bugs.documentfoundation.org/show_bug.cgi?id=147278 Bug ID: 147278 Summary: Strings without Spanish translation in Context Menu - Spelling correction. Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: albac...@gmail.com Description: I am a tester user of LO in Spanish. When I am testing LO Writer 7.3, in Spanish, and I try to use the spell check options to correct a misspelled word in Spanish, I find several strings in English without translating into Spanish, as we can see in the screenshot that I attached today February-8-2022. This bug has affected the entire branch of LO 7.X in Spanish. Steps to Reproduce: 1. Open LibreOffice Writer 7.3 in Spanish. 2. Write a word in Spanish, with some spelling error. For example "card". 3. Apply right click on the word that contains the spelling error. 4. Watch carefully for the pop-up context menu that appears immediately after. 5. Find the “Always AutoCorrect to” Option and hover over that option. 6. Observe also the contextual description corresponding to the “Always AutoCorrect to” option. There are those strings in English without translation into Spanish. Actual Results: The following strings appear in English without translation to Spanish as it should be: “Always AutoCorrect to”. "Add select correction as replacement for incorrect word in AutoCorrect replacement table". Expected Results: Weblate should fix those strings in Spanish for the LO 7.3 Spanish version and all your applications (Writer, Calc, Impress, Draw, etc.). Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: es Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no -- You are receiving this mail because: You are the assignee for the bug.
Re: Material preset "Metal" for extruded custom shapes
Hi Regina, On Mon, Feb 07, 2022 at 08:55:10PM +0100, Regina Henschel wrote: > I have discussed the problem with the OASIS TC today. Their advise is, to > not use Boolean as data type but a string and have namespaced values. That > way it is more flexible in allowing further different ways to implement a > 'metal' rendering. > So I will change that. > > The attribute itself will be with prefix 'loext' till it is integrated in > ODF. But what namespace prefix (and associated namespace) should I use for > the value? I think, a meaningful prefix would be "loext" or "drawooo". My understanding is that we try to standardize on "loext" for all new ODF extensions, so that looks like a better option. > And a second question is the data type of the internal (and API) property. > In the current state of the patch it is "MetalColored" with data type > Boolean. If you have an ODF attribute with a number of possible values, then that could be an enum internally and a set of constants at the UNO API level, I guess. (enum at the UNO API level would be nice, but then you'll have trouble extending that.) 'git grep constants offapi' can give you examples. Regards, Miklos
[Libreoffice-bugs] [Bug 139808] FILEOPEN PPTX Text with Z-rotation disappears from shape
https://bugs.documentfoundation.org/show_bug.cgi?id=139808 --- Comment #5 from Miklos Vajna --- Before it would be lost in the sea of abandoned patches, https://gerrit.libreoffice.org/c/core/+/129424 fixes this problem in practice, it just needs investigation if it's the correct fix + cover it with a test. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: sw/qa sw/source
sw/qa/uitest/writer_tests/tdf146462.py | 45 +
sw/source/ui/fldui/flddb.cxx |1
sw/source/ui/fldui/flddinf.cxx |1
sw/source/ui/fldui/flddok.cxx |1
sw/source/ui/fldui/fldfunc.cxx |1
sw/source/ui/fldui/fldref.cxx |1
sw/source/ui/fldui/fldvar.cxx |1
7 files changed, 51 insertions(+)
New commits:
commit d4d16e26a7deb5bfddc9736b4cc9e87c5f6704ee
Author: Xisco Fauli
AuthorDate: Mon Feb 7 18:06:46 2022 +0100
Commit: Xisco Fauli
CommitDate: Tue Feb 8 08:16:53 2022 +0100
tdf#146462: sw: Add UItest
Change-Id: Ifae155b3d6c727403d395c28842b3aea36b92b49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129633
Tested-by: Jenkins
Reviewed-by: Xisco Fauli
diff --git a/sw/qa/uitest/writer_tests/tdf146462.py
b/sw/qa/uitest/writer_tests/tdf146462.py
new file mode 100644
index ..95eae5ac0fed
--- /dev/null
+++ b/sw/qa/uitest/writer_tests/tdf146462.py
@@ -0,0 +1,45 @@
+# -*- tab-width: 4; indent-tabs-mode: nil; py-indent-offset: 4 -*-
+#
+# This file is part of the LibreOffice project.
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
+#
+
+from uitest.framework import UITestCase
+from libreoffice.uno.propertyvalue import mkPropertyValues
+from uitest.uihelper.common import get_state_as_dict, type_text
+from uitest.uihelper.common import select_pos
+
+class Tdf146462(UITestCase):
+
+def test_tdf146462(self):
+
+with self.ui_test.create_doc_in_start_center("writer") as document:
+xWriterDoc = self.xUITest.getTopFocusWindow()
+xWriterEdit = xWriterDoc.getChild("writer_edit")
+
+type_text(xWriterEdit, "Header")
+
+
self.xUITest.executeCommand(".uno:StyleApply?Style:string=Heading%201:string=ParagraphStyles")
+
+with
self.ui_test.execute_modeless_dialog_through_command(".uno:InsertField",
close_button="cancel") as xDialog:
+xTab = xDialog.getChild("tabcontrol")
+select_pos(xTab, "1")
+
+xType = xDialog.getChild("type-ref")
+xType.getChild('2').executeAction("SELECT", tuple())
+self.assertEqual("Headings",
get_state_as_dict(xType)['SelectEntryText'])
+
+xFormat = xDialog.getChild("format-ref")
+self.assertEqual("Page number (unstyled)",
get_state_as_dict(xFormat)['SelectEntryText'])
+
+xSelect = xDialog.getChild("selecttip")
+
+# Without the fix in place, this test would have failed with
+# AssertionError: 'Header' != ''
+self.assertEqual("Header",
get_state_as_dict(xSelect)['SelectEntryText'])
+self.assertEqual("1", get_state_as_dict(xSelect)['Children'])
+
+# vim: set shiftwidth=4 softtabstop=4 expandtab:
diff --git a/sw/source/ui/fldui/flddb.cxx b/sw/source/ui/fldui/flddb.cxx
index dd5e7046728d..d59da9aabf63 100644
--- a/sw/source/ui/fldui/flddb.cxx
+++ b/sw/source/ui/fldui/flddb.cxx
@@ -66,6 +66,7 @@ SwFieldDBPage::SwFieldDBPage(weld::Container* pPage,
weld::DialogController* pCo
// uitests
m_xTypeLB->set_buildable_name(m_xTypeLB->get_buildable_name() + "-db");
m_xNumFormatLB->set_buildable_name(m_xNumFormatLB->get_buildable_name() +
"-db");
+m_xFormatLB->set_buildable_name(m_xFormatLB->get_buildable_name() + "-db");
}
SwFieldDBPage::~SwFieldDBPage()
diff --git a/sw/source/ui/fldui/flddinf.cxx b/sw/source/ui/fldui/flddinf.cxx
index 1729a68c148c..86e61c60e705 100644
--- a/sw/source/ui/fldui/flddinf.cxx
+++ b/sw/source/ui/fldui/flddinf.cxx
@@ -82,6 +82,7 @@ SwFieldDokInfPage::SwFieldDokInfPage(weld::Container* pPage,
weld::DialogControl
// uitests
m_xTypeTLB->set_buildable_name(m_xTypeTLB->get_buildable_name() +
"-docinf");
m_xSelectionLB->set_buildable_name(m_xSelectionLB->get_buildable_name() +
"-docinf");
+m_xFormatLB->set_buildable_name(m_xFormatLB->get_buildable_name() +
"-docinf");
}
SwFieldDokInfPage::~SwFieldDokInfPage()
diff --git a/sw/source/ui/fldui/flddok.cxx b/sw/source/ui/fldui/flddok.cxx
index 3a4288fdcfcb..4546dfd34ded 100644
--- a/sw/source/ui/fldui/flddok.cxx
+++ b/sw/source/ui/fldui/flddok.cxx
@@ -74,6 +74,7 @@ SwFieldDokPage::SwFieldDokPage(weld::Container* pPage,
weld::DialogController* p
m_xValueED->set_buildable_name(m_xValueED->get_buildable_name() + "-doc");
m_xNumFormatLB->set_buildable_name(m_xNumFormatLB->get_buildable_name() +
"-doc");
m_xSelectionLB->set_buildable_name(m_xSelectionLB->get_buildable_name() +
"-doc");
+m_xFormatLB->set_buildable_name(m_xFormatLB->get_buildable_name() +
"-doc");
}
SwFieldDokPage::~SwFieldDokPage()
diff --git a/sw/source/ui/fldui/fldfunc.cxx b/sw/source/ui/fldui/fldfunc.cxx
index
[Libreoffice-commits] core.git: sc/qa
sc/qa/uitest/data/tdf96499.html | 821 1 file changed, 1 insertion(+), 820 deletions(-) New commits: commit 2b36aec3abca0da7222e126fa46dd2b4387e240f Author: Xisco Fauli AuthorDate: Mon Feb 7 21:10:54 2022 +0100 Commit: Xisco Fauli CommitDate: Tue Feb 8 08:16:03 2022 +0100 uitest: simplify sample file Submitted by mistake in 9d02b1edafd44b75a8996a97c329fdd4967e8f54 < tdf#96499: sc: Add UItest > Change-Id: Idae2b5d7b51022439289ab6c870b47860feaa388 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129645 Tested-by: Jenkins Reviewed-by: Xisco Fauli diff --git a/sc/qa/uitest/data/tdf96499.html b/sc/qa/uitest/data/tdf96499.html index 74c4791c9c06..fac3fe5584d0 100644 --- a/sc/qa/uitest/data/tdf96499.html +++ b/sc/qa/uitest/data/tdf96499.html @@ -3,784 +3,7 @@ - - https://bugs.documentfoundation.org/attachment.cgi?id=178132=edit Navigator Outline Copy enhancement Here is an enhancement for consideration to the Navigator that adds 'Copy' to the Headings context menu: https://gerrit.libreoffice.org/c/core/+/129542 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147265] FORMATTING - Currency format bug - "$ English (Canada)" displays as "BZ$ English (Belize)"
https://bugs.documentfoundation.org/show_bug.cgi?id=147265 --- Comment #2 from tlbransco...@shaw.ca --- (In reply to Julien Nabet from comment #1) > On pc Debian x86-64 with LO 7.3.0.2, I don't reproduce this. > > 1) Do you reproduce this in a brand new ods file or just a specific file? > 2) Could you rename your LO directory profile (see > https://wiki.documentfoundation.org/QA/FirstSteps#Corrupted_user_profile) > and give a new try? Thanks for your questions. 1. I've confirmed that the problem persists when I attempt to format a numeric cell in a new ods file. 2. I can also confirm that the problem persists after I rename my LO profile directory. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147267] Sidebar will not stay docked in a new position from previous docked position before the install of 7.3.0.3
https://bugs.documentfoundation.org/show_bug.cgi?id=147267 V Stuart Foote changed: What|Removed |Added Blocks||103459 Keywords||bibisectRequest, ||needsUXEval, regression Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rayk...@gmail.com, ||samuel.mehrbrodt@allotropia ||.de, vstuart.fo...@utsa.edu --- Comment #1 from V Stuart Foote --- IIRC the Sidebar is not a per-document UI setting. Rather it is recorded into user profile per LO module. If you move it from its default docking location on the right edge of the UI to its alternate docking location on the left edge it should remain there for all subsequent launches of the module. Or if you undock it from one of its two docking locations, it should continue to float at that location until moved. Unfortunately, with a recent Windows build of master against 7.4.0 that is not the behavior. Confirming an issue. Either a drag-and-drop movement, or an "undock" and then drag to opposite side docking location will dock the Sidebar--but it is erratic as to where a subsequent launch of the module will show the Sidebar. @Samuel, @Jim are you getting sane behavior between launches of a module? =-testing-= Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 80723fccbb03c215bab84b10ac1eefaedef66b7c CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103459 [Bug 103459] [META] Sidebar UI and UX bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 103459] [META] Sidebar UI and UX bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=103459 V Stuart Foote changed: What|Removed |Added Depends on||147267 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=147267 [Bug 147267] Sidebar will not stay docked in a new position from previous docked position before the install of 7.3.0.3 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 147267] Sidebar will not stay docked in a new position from previous docked position before the install of 7.3.0.3
https://bugs.documentfoundation.org/show_bug.cgi?id=147267 V Stuart Foote changed: What|Removed |Added Blocks||103459 Keywords||bibisectRequest, ||needsUXEval, regression Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rayk...@gmail.com, ||samuel.mehrbrodt@allotropia ||.de, vstuart.fo...@utsa.edu --- Comment #1 from V Stuart Foote --- IIRC the Sidebar is not a per-document UI setting. Rather it is recorded into user profile per LO module. If you move it from its default docking location on the right edge of the UI to its alternate docking location on the left edge it should remain there for all subsequent launches of the module. Or if you undock it from one of its two docking locations, it should continue to float at that location until moved. Unfortunately, with a recent Windows build of master against 7.4.0 that is not the behavior. Confirming an issue. Either a drag-and-drop movement, or an "undock" and then drag to opposite side docking location will dock the Sidebar--but it is erratic as to where a subsequent launch of the module will show the Sidebar. @Samuel, @Jim are you getting sane behavior between launches of a module? =-testing-= Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 80723fccbb03c215bab84b10ac1eefaedef66b7c CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103459 [Bug 103459] [META] Sidebar UI and UX bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 147135] Crash in: _GLOBAL__sub_I_protectiondlg.cxx.lto_priv.2643 ( Calc crashes )
https://bugs.documentfoundation.org/show_bug.cgi?id=147135 --- Comment #38 from Michael Setzer II --- See same issue on my machines running Fedora 34. Tried the released 7.3 and the dev but same results. Did notice something in message log file. If run libreoffice7.3 but don't try calc there is nothing, but if try calc and it crashes the log has these lines?? Feb 8 11:04:04 setzconote audit[513755]: ANOM_ABEND auid=1000 uid=0 gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=513755 comm="soffice.bin" exe="/opt/libreoffice7.3/program/soffice.bin" sig=4 res=1 Feb 8 11:04:05 setzconote abrt-server[513792]: Package 'libreoffice7.3' isn't signed with proper key Unfortuantely, the lines on abrt at time don't seem to show anything to me. Feb 8 11:04:05 setzconote abrt-dump-journal-oops[2039]: abrt-dump-journal-oops: Found oopses: 1 Feb 8 11:04:05 setzconote abrt-dump-journal-oops[2039]: abrt-dump-journal-oops: Creating problem directories Feb 8 11:04:05 setzconote abrt-server[513792]: Package 'libreoffice7.3' isn't signed with proper key Feb 8 11:04:05 setzconote abrt-server[513792]: 'post-create' on '/var/spool/abrt/ccpp-2022-02-08-11:04:05.227869-513755' exited with 1 Feb 8 11:04:05 setzconote abrt-server[513792]: Deleting problem directory '/var/spool/abrt/ccpp-2022-02-08-11:04:05.227869-513755' Feb 8 11:04:06 setzconote abrt-server[513791]: Can't find a meaningful backtrace for hashing in '.' Feb 8 11:04:06 setzconote abrt-server[513791]: Preserving oops '.' because DropNotReportableOopses is 'no' Feb 8 11:04:06 setzconote abrt-notification[513811]: System encountered a non-fatal error in ??() Feb 8 11:04:06 setzconote abrt-dump-journal-oops[2039]: Reported 1 kernel oopses to Abrt -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147274] Listboxes corners don't update with dark and lightmode
https://bugs.documentfoundation.org/show_bug.cgi?id=147274 --- Comment #1 from jr...@hotmail.com --- Created attachment 178131 --> https://bugs.documentfoundation.org/attachment.cgi?id=178131=edit Screenshots showing default appearance with dark and light mode as well as dark to light change -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147274] New: Listboxes corners don't update with dark and lightmode
https://bugs.documentfoundation.org/show_bug.cgi?id=147274 Bug ID: 147274 Summary: Listboxes corners don't update with dark and lightmode Product: LibreOffice Version: 7.2.5.2 release Hardware: x86-64 (AMD64) OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: UI Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: jr...@hotmail.com Description: LibreOffice Writer Paragraph Style, Font Name and Size listboxes corners don't update when theme is changed from light (Adwaita) to dark (Adwaita dark) and vice-versa, keeping their previous colors instead of the default ones. LibreOffice Calc Font Name and Size listboxes corners, as well as formula input textbox border also keep their current color. Strangely, LibreOffice Impress Font Name and Size listboxes corners are not affected. Steps to Reproduce: 1. Open LibreOffice Calc or Writer. 2. Switch mode from dark to light or vice-versa without closing LibreOffice. Actual Results: Listboxes and text input boxes kept their previous color. Expected Results: Listboxes and text input boxes should change their color accordingly to match what is seem when the software is opened under that theme. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (Fedora 35) OS is 64bit: yes -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: vcl/inc vcl/source
vcl/inc/window.h |5 +
vcl/source/window/winproc.cxx | 122 ++
2 files changed, 127 insertions(+)
New commits:
commit 845e53ea13b317bd8ef4dc42cd60ea51359f34ab
Author: Henry Castro
AuthorDate: Wed Jun 23 07:44:26 2021 -0400
Commit: Henry Castro
CommitDate: Tue Feb 8 00:14:35 2022 +0100
lok: sc: introduce ImplLOKHandleMouseEvent
In tiled rendering case, each user has a View/Controller
object to interact with a unique document (Model) for
collaborating purposes. However, in the desktop case a
unique user has many View/Controller objects to handle a
unique document, so the user has only one global active focus,
capture and tracking window object.
In order to handle independent drag & drop for each user,
it is created ImplLOKHandleMouseEvent.
Change-Id: I735fae9b9858a75f9fedb603798220ab302d65f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118843
Reviewed-by: Szymon Kłos
Tested-by: Szymon Kłos
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117708
Tested-by: Jenkins
Reviewed-by: Henry Castro
diff --git a/vcl/inc/window.h b/vcl/inc/window.h
index bc4b1ee1fe49..050c0558eb7c 100644
--- a/vcl/inc/window.h
+++ b/vcl/inc/window.h
@@ -419,6 +419,11 @@ typedef std::unique_ptr
bool ImplHandleMouseEvent( const VclPtr& xWindow,
MouseNotifyEvent nSVEvent, bool bMouseLeave,
tools::Long nX, tools::Long nY, sal_uInt64 nMsgTime,
sal_uInt16 nCode, MouseEventModifiers nMode );
+
+bool ImplLOKHandleMouseEvent( const VclPtr& xWindow,
MouseNotifyEvent nSVEvent, bool bMouseLeave,
+ tools::Long nX, tools::Long nY, sal_uInt64
nMsgTime,
+ sal_uInt16 nCode, MouseEventModifiers nMode,
sal_uInt16 nClicks);
+
void ImplHandleResize( vcl::Window* pWindow, tools::Long nNewWidth,
tools::Long nNewHeight );
VCL_DLLPUBLIC void ImplWindowStateFromStr(WindowStateData& rData, const
OString& rStr);
diff --git a/vcl/source/window/winproc.cxx b/vcl/source/window/winproc.cxx
index 059e89980fbf..35a5ce2754d2 100644
--- a/vcl/source/window/winproc.cxx
+++ b/vcl/source/window/winproc.cxx
@@ -804,6 +804,128 @@ bool ImplHandleMouseEvent( const VclPtr&
xWindow, MouseNotifyEvent
return bRet;
}
+bool ImplLOKHandleMouseEvent(const VclPtr& xWindow,
MouseNotifyEvent nEvent, bool /*bMouseLeave*/,
+ tools::Long nX, tools::Long nY, sal_uInt64
/*nMsgTime*/,
+ sal_uInt16 nCode, MouseEventModifiers nMode,
sal_uInt16 nClicks)
+{
+Point aMousePos(nX, nY);
+
+if (!xWindow)
+return false;
+
+if (xWindow->isDisposed())
+return false;
+
+ImplFrameData* pFrameData = xWindow->ImplGetFrameData();
+if (!pFrameData)
+return false;
+
+Point aWinPos = xWindow->ImplFrameToOutput(aMousePos);
+
+pFrameData->mnLastMouseX = nX;
+pFrameData->mnLastMouseY = nY;
+pFrameData->mnClickCount = nClicks;
+pFrameData->mnMouseCode = nCode;
+pFrameData->mbMouseIn = false;
+
+vcl::Window* pDownWin = pFrameData->mpMouseDownWin;
+if (pDownWin && nEvent == MouseNotifyEvent::MOUSEMOVE)
+{
+const MouseSettings& aSettings =
pDownWin->GetSettings().GetMouseSettings();
+if ((nCode & (MOUSE_LEFT | MOUSE_RIGHT | MOUSE_MIDDLE)) ==
+(MouseSettings::GetStartDragCode() & (MOUSE_LEFT | MOUSE_RIGHT |
MOUSE_MIDDLE)) )
+{
+if (!pFrameData->mbStartDragCalled)
+{
+tools::Long nDragWidth = aSettings.GetStartDragWidth();
+tools::Long nDragHeight = aSettings.GetStartDragHeight();
+tools::Long nMouseX = aMousePos.X();
+tools::Long nMouseY = aMousePos.Y();
+
+if nMouseX - nDragWidth) > pFrameData->mnFirstMouseX) ||
+ ((nMouseX + nDragWidth) < pFrameData->mnFirstMouseX)) ||
+(((nMouseY - nDragHeight) > pFrameData->mnFirstMouseY) ||
+ ((nMouseY + nDragHeight) < pFrameData->mnFirstMouseY)))
+{
+pFrameData->mbStartDragCalled = true;
+
+if (pFrameData->mbInternalDragGestureRecognizer)
+{
+// query DropTarget from child window
+css::uno::Reference<
css::datatransfer::dnd::XDragGestureRecognizer > xDragGestureRecognizer(
+
pDownWin->ImplGetWindowImpl()->mxDNDListenerContainer,
+css::uno::UNO_QUERY );
+
+if (xDragGestureRecognizer.is())
+{
+// create a UNO mouse event out of the available
data
+css::awt::MouseEvent aEvent(
+static_cast < css::uno::XInterface * > (
nullptr ),
+ #ifdef
[Libreoffice-bugs] [Bug 147254] After changing the background color, on the screen the characters overlapped.
https://bugs.documentfoundation.org/show_bug.cgi?id=147254 Krithi changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #1 from Krithi --- Thank you for reporting the bug. I couldn't reproduce the issue in Version: 7.3.0.3 (x86) / LibreOffice Community 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community d140817428cdbb519efa496f578bf6c054c94361 Could you please explain the steps in details to recheck the issue. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: include/tools
include/tools/helpers.hxx |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
New commits:
commit dcd9e98383c767bbb6014c6ca5fe786579eda08f
Author: Stephan Bergmann
AuthorDate: Mon Feb 7 18:59:20 2022 +0100
Commit: Stephan Bergmann
CommitDate: Mon Feb 7 23:48:59 2022 +0100
float-cast-overflow
...after ea771e85b2302829394df545bb82c02bff2750c2 "Resolves: tdf#146997 use
sal_Int64 instead of sal_Int32 for spinbutton values" changed the default
values
of pcr::ONumericControl::setMin/MaxValue
(extensions/source/propctrlr/standardcontrol.cxx) from int to sal_Int64
limits.
With SAL_USE_VCLPLUGIN=gtk3, in Writer creating a "Form - Label" and
selecting
"Control Properties" in its context menu caused
> include/tools/helpers.hxx:75:93: runtime error: 9.22337e+18 is outside
the range of representable values of type 'long'
> #0 in FRound(double) at include/tools/helpers.hxx:75:93
> #1 in (anonymous namespace)::GtkInstanceSpinButton::fromGtk(double)
const at vcl/unx/gtk3/gtkinst.cxx:16443:16
> #2 in (anonymous namespace)::GtkInstanceSpinButton::get_range(long&,
long&) const at vcl/unx/gtk3/gtkinst.cxx:16521:15
> #3 in weld::MetricSpinButton::update_width_chars() at
vcl/source/window/builder.cxx:258:24
> #4 in weld::MetricSpinButton::set_range(long, long, FieldUnit) at
include/vcl/weld.hxx:1991:9
> #5 in weld::MetricSpinButton::set_min(long, FieldUnit) at
include/vcl/weld.hxx:2005:9
> #6 in
pcr::ONumericControl::setMinValue(com::sun::star::beans::Optional
const&) at extensions/source/propctrlr/standardcontrol.cxx:401:38
and similarly for pcr::ONumericControl::setMaxValue:
For one, for fVal = -9223372036854775808 (i.e., -2^63), -fVal + 0.5 (i.e.,
9223372036854775808.5) was outside the range of 64-bit tools::Long, so
rewrite
the non-positive branch in a simpler way (and I have no idea why it was
written
in the more complex way in the first place).
For another, for fVal = 9223372036854775807 (i.e., 2^63 - 1), fVal + 0.5
(i.e.,
9223372036854775807.5) cannot be represented as IEEE 754 double exactly and
is
represented as 9223372036854775808, which was similarly outside the range of
64-bit tools::Long, so treat that limit value specially on the positive
branch.
Change-Id: Ic2a553e9ce6319eac591058b1218b29dffaeab2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129638
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/include/tools/helpers.hxx b/include/tools/helpers.hxx
index 9340bf9f7294..5f61ba80836c 100644
--- a/include/tools/helpers.hxx
+++ b/include/tools/helpers.hxx
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
template
@@ -72,7 +73,10 @@ inline sal_uInt32 AlignedWidth4Bytes(sal_uInt32 nWidthBits)
inline tools::Long FRound( double fVal )
{
-return fVal > 0.0 ? static_cast( fVal + 0.5 ) :
-static_cast( -fVal + 0.5 );
+return fVal > 0.0
+? fVal == double(std::numeric_limits::max())
+? std::numeric_limits::max() :
static_cast( fVal + 0.5 )
+: static_cast( fVal - 0.5 );
}
//valid range: (-180,180]
[Libreoffice-commits] core.git: vcl/source
vcl/source/app/salvtables.cxx |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
New commits:
commit a56981e9f1710ae44637fa6a31a37dc40c0c445a
Author: Stephan Bergmann
AuthorDate: Mon Feb 7 19:27:04 2022 +0100
Commit: Stephan Bergmann
CommitDate: Mon Feb 7 23:45:31 2022 +0100
float-cast-overflow
...after ea771e85b2302829394df545bb82c02bff2750c2 "Resolves: tdf#146997 use
sal_Int64 instead of sal_Int32 for spinbutton values" changed the default
value
of pcr::ONumericControl::setMaxValue
(extensions/source/propctrlr/standardcontrol.cxx) from int to sal_Int64 max.
For example, UITest_calc_tests9 failed with
> vcl/source/app/salvtables.cxx:5507:12: runtime error: 9.22337e+18 is
outside the range of representable values of type 'long'
> #0 in SalInstanceSpinButton::fromField(double) const at
vcl/source/app/salvtables.cxx:5507:12
> #1 in SalInstanceSpinButton::get_range(long&, long&) const at
vcl/source/app/salvtables.cxx:5541:11
> #2 in weld::MetricSpinButton::update_width_chars() at
vcl/source/window/builder.cxx:258:24
> #3 in weld::MetricSpinButton::set_range(long, long, FieldUnit) at
include/vcl/weld.hxx:1991:9
> #4 in weld::MetricSpinButton::set_max(long, FieldUnit) at
include/vcl/weld.hxx:2012:9
> #5 in
pcr::ONumericControl::setMaxValue(com::sun::star::beans::Optional
const&) at extensions/source/propctrlr/standardcontrol.cxx:422:38
because std::round(fValue * Power10(get_digits())) = 9223372036854775807
(i.e.,
2^63 - 1) cannot be represented as IEEE 754 double exactly and is
represented as
9223372036854775808, which was outside the range of sal_Int64, so treat
that max
limit value specially. (The corresponding min limit value
-9223372036854775808
doesn't have that issue.)
Change-Id: I9ff7a281278a0c66b0b0d49deb0846bcdb91a8fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129639
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/vcl/source/app/salvtables.cxx b/vcl/source/app/salvtables.cxx
index 778901f85d37..c320b43c8592 100644
--- a/vcl/source/app/salvtables.cxx
+++ b/vcl/source/app/salvtables.cxx
@@ -19,6 +19,7 @@
#include
+#include
#include
#include
@@ -5504,7 +5505,10 @@ double SalInstanceSpinButton::toField(sal_Int64 nValue)
const
sal_Int64 SalInstanceSpinButton::fromField(double fValue) const
{
-return std::round(fValue * Power10(get_digits()));
+auto const x = fValue * Power10(get_digits());
+return x == double(std::numeric_limits::max())
+ ? std::numeric_limits::max()
+ : sal_Int64(std::round(x));
}
SalInstanceSpinButton::SalInstanceSpinButton(FormattedField* pButton,
SalInstanceBuilder* pBuilder,
[Libreoffice-bugs] [Bug 147273] Copying From Calc + Paste Unformatted Text into Writer = All Text in Single Cell
https://bugs.documentfoundation.org/show_bug.cgi?id=147273 --- Comment #2 from Tex2002ans --- Created attachment 178130 --> https://bugs.documentfoundation.org/attachment.cgi?id=178130=edit Writer 3x3 Table with Formatting -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147273] Copying From Calc + Paste Unformatted Text into Writer = All Text in Single Cell
https://bugs.documentfoundation.org/show_bug.cgi?id=147273 --- Comment #1 from Tex2002ans --- Created attachment 178129 --> https://bugs.documentfoundation.org/attachment.cgi?id=178129=edit Calc 3x3 Table with Colors -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147273] New: Copying From Calc + Paste Unformatted Text into Writer = All Text in Single Cell
https://bugs.documentfoundation.org/show_bug.cgi?id=147273 Bug ID: 147273 Summary: Copying From Calc + Paste Unformatted Text into Writer = All Text in Single Cell Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: tex2002ans+libreoff...@gmail.com Description: I think this is a regression of Bug #37223. I have a basic table in Calc: - Apples | Bananas | Carrots - A | B | C - 1 | 2 | 3 Pasting "Unformatted Text" into Writer results in all text being shoved into a single cell. Steps to Reproduce: 0. Open the two attached documents. (ODS + ODT) 1. In Calc, highlight 3x3 colorful table. 2. **Copy (Ctrl+C)**. 3. In Writer, click in first cell. 4. **Edit > Paste Special > Paste as Unformatted Text (Ctrl+Alt+Shift+V)**. Actual Results: All text gets shoved into the very first Writer cell. Expected Results: - Row 1 = Apples | Banana | Carrots - Row 2 = A | B | C - Row 3 = 1 | 2 | 3 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded * * * I was trying to debug an issue posted here: https://www.reddit.com/r/libreoffice/comments/smy4u2/paste_text_matching_style_keep_target_formatting/ and stumbled across this regression. If this "Paste Unformatted Text" bug is solved, I believe that user's issue will be solved too. (It dealt with Writer table formatting not appearing.) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147252] After Undo (Ctrl+Z) it changes font of the paragragh.
https://bugs.documentfoundation.org/show_bug.cgi?id=147252 Krithi changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #1 from Krithi --- Thank you for reporting the bug. I couldn't reproduce the issue in Version: 7.3.0.3 (x86) / LibreOffice Community 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community d140817428cdbb519efa496f578bf6c054c94361 I tried to do CTLR+Z but the font of the para didn't change. If you had this issue when following certain steps could you please explain the steps in detail -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147272] New: copy paste html to writer
https://bugs.documentfoundation.org/show_bug.cgi?id=147272
Bug ID: 147272
Summary: copy paste html to writer
Product: LibreOffice
Version: 7.3.0.3 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: c.huege...@gmail.com
Description:
Copy website content and paste it to write doc.
There are links instead of pics.
"auflösen" (german version) does not work - they are deleted ("löschen" /
"lösen".
Steps to Reproduce:
1. copy html contend
2. paste to writer doc
3. "lösen" of links
Actual Results:
copy paste again
Expected Results:
manual copying of pics.
Reproducible: Always
User Profile Reset: No
Additional Info:
"lösen" means: removing links and copying the pics (substitution of links to
pics)
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147271] LibreOfficeKit demo shows rtl Calc document as mirrored
https://bugs.documentfoundation.org/show_bug.cgi?id=147271 Hossein changed: What|Removed |Added CC||hoss...@libreoffice.org --- Comment #1 from Hossein --- Created attachment 178128 --> https://bugs.documentfoundation.org/attachment.cgi?id=178128=edit Example Calc file with an rtl sheet -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147271] New: LibreOfficeKit demo shows rtl Calc document as mirrored
https://bugs.documentfoundation.org/show_bug.cgi?id=147271 Bug ID: 147271 Summary: LibreOfficeKit demo shows rtl Calc document as mirrored Product: LibreOffice Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: LibreOffice Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: hoss...@libreoffice.org Description: When opening a Calc document with a right-to-left (rtl) sheet, the text is wrongly displayed as mirrored. The wrong mirroring is done both for English (ltr) and Arabic/Persian (rtl) text. Steps to Reproduce: 1. Open a Calc file with an rtl sheet. You can invoke this from the core folder after building LibrOffice: ./bin/run gtktiledviewer --lo-path=instdir/program rtl.ods Actual Results: All the texts are displayed as mirrored. Expected Results: The text should be shown as normal readable text, and not mirrored. Reproducible: Always User Profile Reset: No Additional Info: The same effect can be created by sending UNO command "SheetRightToLeft" from the UI in a Calc file with rtl sheets. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147243] LibreOffice spreadsheet. Entering a date of "1/2" (to represent the first of february) into a cell results in display of the fraction 1/2.
https://bugs.documentfoundation.org/show_bug.cgi?id=147243 m.a.riosv changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED CC||miguelangelrv@libreoffice.o ||rg --- Comment #2 from m.a.riosv --- You have the options. 1. To disable the substitution on Menu/Tools/Autocorrection - Replace. 2- Enter as 01/2 instead of 1/2. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'libreoffice-7-3' - sw/source
sw/source/core/doc/DocumentRedlineManager.cxx |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) New commits: commit 522160397ad5b4cb802fcef0b10294e84a612723 Author: Caolán McNamara AuthorDate: Mon Feb 7 12:45:33 2022 + Commit: Andras Timar CommitDate: Mon Feb 7 22:46:08 2022 +0100 ofz#44471 crash in isMoved if re-insert of invalid range failed Change-Id: I21a3a3e544c016205d65d7e81889ebfddc7e322d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129563 Tested-by: Jenkins Reviewed-by: Andras Timar diff --git a/sw/source/core/doc/DocumentRedlineManager.cxx b/sw/source/core/doc/DocumentRedlineManager.cxx index a3de2c9143fb..2c2f4a1b080b 100644 --- a/sw/source/core/doc/DocumentRedlineManager.cxx +++ b/sw/source/core/doc/DocumentRedlineManager.cxx @@ -1429,7 +1429,8 @@ DocumentRedlineManager::AppendRedline(SwRangeRedline* pNewRedl, bool const bCall bCompress = true; // set IsMoved checking nearby redlines -maRedlineTable.isMoved(n); +if (n < maRedlineTable.size()) // in case above 're-insert' failed +maRedlineTable.isMoved(n); } } else if( SwComparePosition::Inside == eCmpPos )
[Libreoffice-bugs] [Bug 147270] New: LibreCalc - Tools > Options > General -- text chopped off
https://bugs.documentfoundation.org/show_bug.cgi?id=147270 Bug ID: 147270 Summary: LibreCalc - Tools > Options > General -- text chopped off Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: ea4203...@gmail.com Description: text chopped off at bottom of > tools > options > general window pane (this needs an adjustment or vertical scroll added) Steps to Reproduce: go here, > tools > options > general Actual Results: you will see bottom line of text cut in half at window pane fold Expected Results: not chopped off text; is that the last line or does it go down further; don't know Reproducible: Always User Profile Reset: No Additional Info: also checked open office calc 4.1.11 and no problem with that -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 146047] UI: Orientation Landscape in Print dialog doesn't do anything
https://bugs.documentfoundation.org/show_bug.cgi?id=146047 --- Comment #11 from Julien Nabet --- Just for the record, I could reproduce this with LO Debian package 7.3.0.2 but I don't reproduce this with master sources updated today. For "Generic printer", preview shows landscape. For "Print to file", preview shows landscape and the file generated shows also landscape. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] dictionaries.git: Changes to 'distro/collabora/co-22.05'
New branch 'distro/collabora/co-22.05' available with the following commits:
[Libreoffice-commits] translations.git: Changes to 'distro/collabora/co-22.05'
New branch 'distro/collabora/co-22.05' available with the following commits:
[Libreoffice-commits] help.git: Changes to 'distro/collabora/co-22.05'
New branch 'distro/collabora/co-22.05' available with the following commits:
[Libreoffice-bugs] [Bug 147269] New: LibreCalc - no menu on the cell right click due to flagged spelling
https://bugs.documentfoundation.org/show_bug.cgi?id=147269 Bug ID: 147269 Summary: LibreCalc - no menu on the cell right click due to flagged spelling Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: ea4203...@gmail.com Description: Select cell and right click on that cell unselects cell instead pulling up right click menu, on certain cells. Deleting the cell text fixes the problem of course your text is gone. Problem is caused by spelling check flagging one word as incorrect, a cell with only one incorrect word will not duplicate the problem, numbers make no difference, you need two words or more with one word flagged as a spelling error to duplicate the problem. Also tested with Open Office that Libre is based on, same bug exists in Open Office. Steps to Reproduce: Problem is caused by spelling check flagging one word as incorrect, a cell with only one incorrect word will not duplicate the problem, numbers make no difference, you need two words or more with one word flagged as a spelling error to duplicate the problem. (IE type in a cell "ebay sold out", then attempt to right click for the cell menu) Actual Results: that will duplicate the problem Expected Results: cell should have stayed selected and displayed right click menu containing cell options Reproducible: Always User Profile Reset: No Additional Info: Same problem exists in Open Office 4.1.11 Libre Office problem found in 7.2.0, then I upgraded to 7.3.0.3 and still problem exists. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Changes to 'distro/collabora/co-22.05'
New branch 'distro/collabora/co-22.05' available with the following commits:
[Libreoffice-commits] core.git: Changes to 'refs/tags/co-22.05-branch-point'
Tag 'co-22.05-branch-point' created by Andras Timar at 2022-02-07 21:25 + co-22.05-branch-point Changes since libreoffice-7-3-branch-point-485: --- 0 files changed ---
[Libreoffice-commits] translations.git: Changes to 'refs/tags/co-22.05-branch-point'
Tag 'co-22.05-branch-point' created by Andras Timar at 2022-02-07 21:25 + co-22.05-branch-point Changes since libreoffice-7-3-branch-point-8: --- 0 files changed ---
[Libreoffice-commits] help.git: Changes to 'refs/tags/co-22.05-branch-point'
Tag 'co-22.05-branch-point' created by Andras Timar at 2022-02-07 21:25 + co-22.05-branch-point Changes since libreoffice-7-3-branch-point-25: --- 0 files changed ---
[Libreoffice-commits] dictionaries.git: Changes to 'refs/tags/co-22.05-branch-point'
Tag 'co-22.05-branch-point' created by Andras Timar at 2022-02-07 21:25 + co-22.05-branch-point Changes since libreoffice-7-3-branch-point-1: --- 0 files changed ---
[Libreoffice-bugs] [Bug 147268] New: Some selected preferences are not remembered when installing a new version
https://bugs.documentfoundation.org/show_bug.cgi?id=147268 Bug ID: 147268 Summary: Some selected preferences are not remembered when installing a new version Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: tarotf...@protonmail.com Description: Some selected preferences are not remembered when installing a new version. I have noticed this in previous versions, but how far back it goes I'm not certain. Here are the three cases: Tools > Options > Language Settings > English Sentence Checking Tools > Options > LibreOffice Writer > Grid (Resolution and Subdivision options) Tools > Options > LibreOffice Writer > Table (Keyboard Handling options) Steps to Reproduce: 1. Make a note of your preferences in the above mentioned categories 2. Download and install a new version of LO 3. Go back and check your preferences in the above mentioned categories Actual Results: The preferences are apparently set to some default settings -- not the settings you selected in the previous version. Expected Results: The preferences should migrate to the latest version without the user having to go back and check why, for example, some English Sentence Language Settings are not being automatically checked by the software. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 146572] Wrapped RTL String Incorrectly Positioned in LTR Paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=146572 --- Comment #8 from Eyal Rozenberg --- (In reply to jcuenod from comment #5) Actually, that doesn't make things clearer. Paragraph alignment is basically orthogonal paragraph direction. And the span of RTL text does not "align" anywhere; the only questions are: 1. Should the space character(s) between the last word fitting on the first line and the first word on the next line should be kept on the first line, assuming they fit, or moved to the next one? 2. If they are kept on the first line, should they appear on the left side, between the LTR span and the last letter of the last RTL word, or on the right side, to the right of the first RTL word? LO Writer answers this with "Kept on the first line" and "on the left side". I am not sure what Unicode standard says! It won't hurt to check using MS-Word and MS Notepad what Microsoft does. Using the XFCE mousepad editor, I notice the answers are "kept on the first line" and "on the right side" - unlike the LO logic, and perhaps more in line with what you expect. So does GNOME's gedit. AbiWord acts like LO Writer though. > Anecdotally, however, this is how I've seen other editors lay out such text > (e.g. Google docs) and this is how I've observed it in journal articles. Can you attach some screenshots? > If you need a list of examples, I will try to dig some up. Windows examples would be pertinent. If you can get them, please do. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147267] New: Sidebar will not stay docked in a new position from previous docked position before the install of 7.3.0.3
https://bugs.documentfoundation.org/show_bug.cgi?id=147267 Bug ID: 147267 Summary: Sidebar will not stay docked in a new position from previous docked position before the install of 7.3.0.3 Product: LibreOffice Version: 7.3.0.3 release Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: tarotf...@protonmail.com Description: In this latest version (7.3.0.3) the sidebar will not move to the opposite side of the screen and stay docked there upon reopening the saved document or saved template. In other words, if the sidebar was set to dock on the left side of the screen to ameliorate the text tearing issue, you can move it and dock it to the right side of the screen, and even save the document or template, but the next time you open the document or template it will be back to being docked on the left side again). This was not an issue in version 7.2.5 or previous versions to the best of my recollection. Steps to Reproduce: 1. Move and dock the sidebar to the opposite side of the screen from the default 2. Save the document or template 3. Close document or template 4. Reopen the document or template Actual Results: The document or template goes back to being wherever it was docked before the downloading and installing of version 7.3.0.3. Expected Results: The sidebar should stay located and docked where you set it, not keep opening up in the position you no longer want it be docked at just because you moved it in a prior version to avoid an issue (in this case, the issue being moving the sidebar to the left side of the screen to avoid the nasty text tearing issue). Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147266] New: 7.3.03 not usable on M1 Macmini
https://bugs.documentfoundation.org/show_bug.cgi?id=147266 Bug ID: 147266 Summary: 7.3.03 not usable on M1 Macmini Product: LibreOffice Version: 7.3.0.3 release Hardware: Other OS: macOS (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: LibreOffice Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: avrum...@verizon.net M1 Macmini Mac OS 11.6.03 Libre Office 7.3.03 and previous 7 . Opening docx or .odt documents Cursor has the shakes Cant select (to delete text etc) -- You are receiving this mail because: You are the assignee for the bug.
