[Libreoffice-bugs] [Bug 71224] Insert new fields between existing fields not working (ALTER TABLE ADD BEFORE/AFTER)
https://bugs.documentfoundation.org/show_bug.cgi?id=71224 Stéphane Guillou (stragu) changed: What|Removed |Added CC||petersmith60...@gmail.com --- Comment #15 from Stéphane Guillou (stragu) --- *** Bug 153340 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153340] Table - Edit - Insert Row between existing rows often does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=153340 Stéphane Guillou (stragu) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Stéphane Guillou (stragu) --- Thank you for your report, Peter. This has been reported before in bug 71224. *** This bug has been marked as a duplicate of bug 71224 *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 107158] [META] Notebookbar Groupedbar
https://bugs.documentfoundation.org/show_bug.cgi?id=107158 Bug 107158 depends on bug 153078, which changed state. Bug 153078 Summary: Whole section of Groupedbar Compact UI disappear https://bugs.documentfoundation.org/show_bug.cgi?id=153078 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141684] Groupedbar Compact changes when cursor is in table
https://bugs.documentfoundation.org/show_bug.cgi?id=141684 Xisco Faulí changed: What|Removed |Added Status|RESOLVED|REOPENED CC||xiscofa...@libreoffice.org Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 107158] [META] Notebookbar Groupedbar
https://bugs.documentfoundation.org/show_bug.cgi?id=107158 Bug 107158 depends on bug 141684, which changed state. Bug 141684 Summary: Groupedbar Compact changes when cursor is in table https://bugs.documentfoundation.org/show_bug.cgi?id=141684 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141684] Groupedbar Compact changes when cursor is in table
https://bugs.documentfoundation.org/show_bug.cgi?id=141684 --- Comment #9 from Commit Notification --- Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bcf9e47791d5b3e1d6a75c73f3b8c9940abda8eb tdf#153078: Revert "tdf#141684 fix disappearance of icons in Groupedbar and Groupedbar compact UI" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141684] Groupedbar Compact changes when cursor is in table
https://bugs.documentfoundation.org/show_bug.cgi?id=141684 Commit Notification changed: What|Removed |Added Whiteboard|target:7.5.0|target:7.5.0 target:7.6.0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: vcl/source
vcl/source/control/PriorityMergedHBox.cxx |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) New commits: commit bcf9e47791d5b3e1d6a75c73f3b8c9940abda8eb Author: Xisco Fauli AuthorDate: Thu Feb 2 16:35:28 2023 +0100 Commit: Xisco Fauli CommitDate: Fri Feb 3 07:56:35 2023 + tdf#153078: Revert "tdf#141684 fix disappearance of icons in Groupedbar and Groupedbar compact UI" This reverts commit 801e6272dc299d4468ec094ce11b66494eb5018b. Revert it for now, until a better solution for tdf#141684 is found Change-Id: I6c9fd7fb12149b67fe572d64cf00e6a3ec98611f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146504 Tested-by: Jenkins Reviewed-by: Justin Luth diff --git a/vcl/source/control/PriorityMergedHBox.cxx b/vcl/source/control/PriorityMergedHBox.cxx index c5e21c7c002c..75a26daa52c1 100644 --- a/vcl/source/control/PriorityMergedHBox.cxx +++ b/vcl/source/control/PriorityMergedHBox.cxx @@ -27,7 +27,6 @@ #define DUMMY_WIDTH 50 #define BUTTON_WIDTH 30 -#define TEMP_WIDTH 200 /* * PriorityMergedHBox is a VclHBox which hides its own children if there is no sufficient space. @@ -58,9 +57,6 @@ void PriorityMergedHBox::Resize() } tools::Long nWidth = GetSizePixel().Width(); -if (nWidth <= 1 || nWidth == TEMP_WIDTH || nWidth == TEMP_WIDTH + 6) -return VclHBox::Resize(); - tools::Long nCurrentWidth = VclHBox::calculateRequisition().getWidth() + BUTTON_WIDTH; // Hide lower priority controls @@ -159,7 +155,7 @@ Size PriorityMergedHBox::calculateRequisition() const accumulateMaxes(aChildSize, aSize); } -setPrimaryDimension(aSize, TEMP_WIDTH); +setPrimaryDimension(aSize, 200); return finalizeMaxes(aSize, nVisibleChildren); }
[Libreoffice-bugs] [Bug 153229] [RFE] Please provide a user preference to disable inheriting the system UI theme
https://bugs.documentfoundation.org/show_bug.cgi?id=153229
--- Comment #14 from Mike Kaganski ---
Created attachment 185079
--> https://bugs.documentfoundation.org/attachment.cgi?id=185079=edit
A screencast of a UWP app (calculator) selector
(In reply to Heiko Tietze from comment #12)
> Providing an option to switch automatic / light / dark theme is common
> functionality and should be implemented.
Confirming how the *overriding* of a system-defined *default* mode is a
standard for current UWP apps.
Note how Windows also talks about "defaults" in its UI - see attachment 184980.
So even though LibreOffice is not an UWP app, since we try to follow the mode,
we need also to provide the OS-specific UI conventions, thus implementing it is
a really important thing.
Those who use Visual Studio, can open its installer ("C:\Program Files
(x86)\Microsoft Visual Studio\Installer\vs_installer.exe"), and see how a
similar selector is implemented there as a switcher button in the title bar.
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'private/tvajngerl/staging' - 6 commits - basctl/source basegfx/CppunitTest_basegfx.mk basegfx/test chart2/source cui/source editeng/source filter/source include
Rebased ref, commits from common ancestor:
commit 01aca73b815adade6e09b0699148b1553c0798c7
Author: Tomaž Vajngerl
AuthorDate: Wed Nov 23 11:00:13 2022 +0900
Commit: Tomaž Vajngerl
CommitDate: Fri Feb 3 16:38:37 2023 +0900
svx: convert SdrTextObj rotate and move to use gfx::Length
Change-Id: I82f10f82db8ac9d5653f4902276ee58fc18c52d6
diff --git a/include/basegfx/utils/RectangleWrapper.hxx
b/include/basegfx/utils/RectangleWrapper.hxx
index 00586d6eae71..4f5dbe851f66 100644
--- a/include/basegfx/utils/RectangleWrapper.hxx
+++ b/include/basegfx/utils/RectangleWrapper.hxx
@@ -55,6 +55,11 @@ public:
m_aRange.setSize(width, height);
}
+void shift(gfx::Length const& rXDelta, gfx::Length const& rYDelta)
+{
+m_aRange.shift(rXDelta, rYDelta);
+}
+
void move(sal_Int32 nXDelta, sal_Int32 nYDelta)
{
auto deltaX = gfx::Length::hmm(nXDelta);
diff --git a/svx/source/svdraw/svdotxtr.cxx b/svx/source/svdraw/svdotxtr.cxx
index 1055e5dbe3bb..9ccc69709abf 100644
--- a/svx/source/svdraw/svdotxtr.cxx
+++ b/svx/source/svdraw/svdotxtr.cxx
@@ -40,6 +40,35 @@
using namespace com::sun::star;
+namespace
+{
+gfx::Tuple2DL rotatePoint(gfx::Tuple2DL const& rPoint, gfx::Tuple2DL const&
rReference, double sinAngle, double cosAngle)
+{
+gfx::Length dx = rPoint.getX() - rReference.getX();
+gfx::Length dy = rPoint.getY() - rReference.getY();
+
+auto x = rReference.getX() + gfx::Length::emu(basegfx::fround(dx.raw() *
cosAngle + dy.raw() * sinAngle));
+auto y = rReference.getY() + gfx::Length::emu(basegfx::fround(dy.raw() *
cosAngle - dx.raw() * sinAngle));
+
+return gfx::Tuple2DL(x, y);
+}
+
+gfx::Tuple2DL toTuple(Point const& rPointHmm)
+{
+auto x = gfx::Length::hmm(rPointHmm.X());
+auto y = gfx::Length::hmm(rPointHmm.Y());
+return {x, y};
+}
+
+gfx::Size2DL toSize2D(Size const& rSizeHmm)
+{
+auto x = gfx::Length::hmm(rSizeHmm.Width());
+auto y = gfx::Length::hmm(rSizeHmm.Height());
+return {x, y};
+}
+
+} // end anonymous ns
+
void SdrTextObj::NbcSetSnapRect(const tools::Rectangle& rRect)
{
if (maGeo.nRotationAngle || maGeo.nShearAngle)
@@ -92,7 +121,9 @@ Degree100 SdrTextObj::GetShearAngle(bool /*bVertical*/) const
void SdrTextObj::NbcMove(const Size& rSize)
{
-moveRectangle(rSize.Width(), rSize.Height());
+gfx::Size2DL aSize2D = toSize2D(rSize);
+maRectangle.shift(aSize2D.getWidth(), aSize2D.getHeight());
+
moveOutRectangle(rSize.Width(), rSize.Height());
maSnapRect.Move(rSize);
SetBoundAndSnapRectsDirty(true);
@@ -183,27 +214,37 @@ void SdrTextObj::NbcResize(const Point& rRef, const
Fraction& xFact, const Fract
SetBoundAndSnapRectsDirty();
}
-void SdrTextObj::NbcRotate(const Point& rRef, Degree100 nAngle, double sn,
double cs)
+void SdrTextObj::NbcRotate(const Point& rRef, Degree100 nAngle, double
sinAngle, double cosAngle)
{
+auto aReference = toTuple(rRef);
+
SetGlueReallyAbsolute(true);
-tools::Long dx = getRectangle().Right() - getRectangle().Left();
-tools::Long dy = getRectangle().Bottom() - getRectangle().Top();
-Point aPoint1(getRectangle().TopLeft());
-RotatePoint(aPoint1, rRef, sn, cs);
-Point aPoint2(aPoint1.X() + dx, aPoint1.Y() + dy);
-tools::Rectangle aRectangle(aPoint1, aPoint2);
-setRectangle(aRectangle);
+auto const& rRange = maRectangle.getRange();
+
+auto nWidth = rRange.getWidth();
+auto nHeight = rRange.getHeight();
+
+gfx::Tuple2DL aPoint1(rRange.getMinX(), rRange.getMinY());
+aPoint1 = rotatePoint(aPoint1, aReference, sinAngle, cosAngle);
-if (maGeo.nRotationAngle==0_deg100) {
-maGeo.nRotationAngle=NormAngle36000(nAngle);
-maGeo.mfSinRotationAngle=sn;
-maGeo.mfCosRotationAngle=cs;
-} else {
-maGeo.nRotationAngle=NormAngle36000(maGeo.nRotationAngle+nAngle);
+gfx::Tuple2DL aPoint2(aPoint1.getX() + nWidth, aPoint1.getY() + nHeight);
+
+gfx::Range2DL aRange{aPoint1, aPoint2};
+maRectangle.setRange(aRange);
+
+if (maGeo.nRotationAngle == 0_deg100)
+{
+maGeo.nRotationAngle = NormAngle36000(nAngle);
+maGeo.mfSinRotationAngle = sinAngle;
+maGeo.mfCosRotationAngle = cosAngle;
+}
+else
+{
+maGeo.nRotationAngle = NormAngle36000(maGeo.nRotationAngle + nAngle);
maGeo.RecalcSinCos();
}
SetBoundAndSnapRectsDirty();
-NbcRotateGluePoints(rRef,nAngle,sn,cs);
+NbcRotateGluePoints(rRef, nAngle, sinAngle, cosAngle);
SetGlueReallyAbsolute(false);
}
commit 80ebdd107811acaa63c1b3a1d5eb15be7baa54c5
Author: Tomaž Vajngerl
AuthorDate: Tue Nov 22 13:33:30 2022 +0900
Commit: Tomaž Vajngerl
CommitDate: Fri Feb 3 16:38:37 2023 +0900
svx: use RectangleWrapper for maRectangle on SdrTextObj
This is needed so we can now transition to use gfx::Length and
gfx::Range2DL to define the object position and size.
Change-Id:
[Libreoffice-bugs] [Bug 152816] Form - Label in a new document: warning in console with debug LO
https://bugs.documentfoundation.org/show_bug.cgi?id=152816 Robert Großkopf changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3343 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153343] Forms: Label field creates wrong font height as default (default 10 pt, but shows only 8 pt)
https://bugs.documentfoundation.org/show_bug.cgi?id=153343 Robert Großkopf changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2816 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153343] Forms: Label field creates wrong font height as default (default 10 pt, but shows only 8 pt)
https://bugs.documentfoundation.org/show_bug.cgi?id=153343 --- Comment #1 from Robert Großkopf --- Created attachment 185078 --> https://bugs.documentfoundation.org/attachment.cgi?id=185078=edit Same as first attachment, exported to pdf. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153343] New: Forms: Label field creates wrong font height as default (default 10 pt, but shows only 8 pt)
https://bugs.documentfoundation.org/show_bug.cgi?id=153343 Bug ID: 153343 Summary: Forms: Label field creates wrong font height as default (default 10 pt, but shows only 8 pt) Product: LibreOffice Version: 7.5.0.3 release Hardware: x86-64 (AMD64) OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: rob...@familiegrosskopf.de Created attachment 185077 --> https://bugs.documentfoundation.org/attachment.cgi?id=185077=edit Writer file with 2 label fields. Both are set to 10 pt. First field appears 8 pt. Open a new Writer document. Form → Design Mode must be set. Form → Label Create a label field. Text Label Field appears very small. Have a look at the properties (right mouse click → Control Properties → General → Font). Says it is set to (Default). Press Button with … and have a look. Size should be 10 pt, but it isn't. Switch Size to 12 pt and press OK. Reopen the dialog and switch size to 10 pt. Now the font is set the right size. This bug appears in Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded It doesn't appear in LO 7.4.5.1. If you open the attached file in LO 7.4.5.1 you see to label fields with identical height of fonts. If you open this in LO 7.5.0.3 it will show different height. I have attached also a *.pdf-file to show the difference. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 41775] Don't remove all menus when no windows are open - keep Tools and Help
https://bugs.documentfoundation.org/show_bug.cgi?id=41775 --- Comment #25 from Shad Sterling --- As with every previous time, no change for more than 10 years now Version: 7.4.1.2 / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 16; OS: Mac OS X 13.2; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153342] New: Copying-and-pasting HTML text with an inline style into LibreOffice Impress will show copy text, not formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=153342 Bug ID: 153342 Summary: Copying-and-pasting HTML text with an inline style into LibreOffice Impress will show copy text, not formatting Product: LibreOffice Version: 7.4.4.2 release Hardware: All OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Impress Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fpes...@tuxfamily.org Description: Hello, copying-and-pasting HTML text with an inline style into LibreOffice Impress will only show text, not formatting. Doing the same in LibreOffice Writer also shows the formatting. Steps to Reproduce: 1. Create a blank HTML file with this text: Color test 1) This text is pasted with color This text is pasted at standard size 2. Open the created HTML file with a web browser 3. Copy into the clipboard the text from the page 4. Paste the clipboard into LibreOffice Impress Actual Results: The text is pasted correctly but formatting is ignored entirely. Expected Results: The text should show formatting, as it happens in LibreOffice Writer. Unformatted text should be pasted via Paste Special. Reproducible: Always User Profile Reset: No Additional Info: See #153341 for a related bug in LibreOffice Writer. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: opencl/source
opencl/source/opencl_device.cxx | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
New commits:
commit c544f9ea78eab46c4f5230273a5a8571b28ea84d
Author: Ilmari Lauhakangas
AuthorDate: Thu Feb 2 16:19:11 2023 +0200
Commit: Ilmari Lauhakangas
CommitDate: Fri Feb 3 07:13:52 2023 +
Use raw string literal in opencl to keep PMD static analyser happy
Change-Id: Ibf2bd12b79c6e7c7eae59fc516e75c1bda971a7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146502
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas
Reviewed-by: Ilmari Lauhakangas
diff --git a/opencl/source/opencl_device.cxx b/opencl/source/opencl_device.cxx
index ca9f4f43b5d1..e8712cb5a745 100644
--- a/opencl/source/opencl_device.cxx
+++ b/opencl/source/opencl_device.cxx
@@ -30,8 +30,6 @@
#define INPUTSIZE 15360
#define OUTPUTSIZE 15360
-#define STRINGIFY(...) #__VA_ARGS__"\n"
-
namespace {
void DS_CHECK_STATUS(cl_int status, char const * name) {
@@ -55,13 +53,13 @@ struct LibreOfficeDeviceEvaluationIO
tools::ULong outputSize;
};
-const char* source = STRINGIFY(
-\n#if defined(KHR_DP_EXTENSION)
-\n#pragma OPENCL EXTENSION cl_khr_fp64 : enable
-\n#elif defined(AMD_DP_EXTENSION)
-\n#pragma OPENCL EXTENSION cl_amd_fp64 : enable
-\n#endif
-\n
+const char* source = R"delimit(
+#if defined(KHR_DP_EXTENSION)
+#pragma OPENCL EXTENSION cl_khr_fp64 : enable
+#elif defined(AMD_DP_EXTENSION)
+#pragma OPENCL EXTENSION cl_amd_fp64 : enable
+#endif
+
int isNan(fp_t a) { return a != a; }
fp_t fsum(fp_t a, fp_t b) { return a + b; }
@@ -108,7 +106,7 @@ const char* source = STRINGIFY(
fp_t tmp1 = fMin(input1) * fSoP(input2, input3);
result[gid0] = fsum(tmp0, tmp1);
}
-);
+)delimit";
size_t sourceSize[] = { strlen(source) };
[Libreoffice-bugs] [Bug 153341] New: Copied HTML text which uses the alpha channel is pasted either without it (when rgb(r g b / a) notation is used) or without any color (when rgba(r, g, b, a) notati
https://bugs.documentfoundation.org/show_bug.cgi?id=153341 Bug ID: 153341 Summary: Copied HTML text which uses the alpha channel is pasted either without it (when rgb(r g b / a) notation is used) or without any color (when rgba(r, g, b, a) notation is used) Product: LibreOffice Version: 7.4.4.2 release Hardware: x86-64 (AMD64) OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fpes...@tuxfamily.org Description: Hello, copying-and-pasting HTML text whose inline style contains color into LibreOffice Writer does not work properly, as the pasted text will not always show its actual color. When the rgb(r g b / a) CSS notation is used, the alpha channel is ignored and rgb(r, g, b) is used instead. When the rgba(r, g, b, a) CSS format is used, the color is ignored entirely. Only text using the rgb(r, g, b) CSS format (without an alpha channel) will show the correct color in LibreOffice writer. Steps to Reproduce: 1. Copy this HTML markup inside a file: Color test 1) This text is pasted with color 2) This text is also pasted with color, but the text pasted has a color which ignores the alpha channel 3) This text is pasted without color 2. Open the created HTML file with a web browser 3. Copy the three lines of text into the clipboard 4. Paste the clipboard into LibreOffice Writer Actual Results: Pasting line 1) (which uses the rgb(r, g, b) format) into LibreOffice Writer will show the right color. Pasting line 2) (which used the rgb(r g b / a) format) into LibreOffice Writer will show a wrong color (in this case, rgb(r, g, b) without the alpha channel). Pasting line 3) into LibreOffice Writer will not show any color. Expected Results: All three lines should show the correct color. Reproducible: Always User Profile Reset: No Additional Info: Please note that an alpha channel is not needed to show rgba text. The algorithm in https://marcodiiga.github.io/rgba-to-rgb-conversion can be used to turn a RGBA color into RGB. So, from my example, rgba(255, 0, 0, 0.3) can be rendered as: rgb(255,179,179) by setting white as the background color. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: sw/inc sw/source
sw/inc/swtable.hxx |2 ++
sw/source/core/docnode/ndtbl.cxx | 12 +---
sw/source/core/table/swtable.cxx | 17 +
3 files changed, 20 insertions(+), 11 deletions(-)
New commits:
commit 2422e1b0418d057e08ef08251e8638d1478631fe
Author: Miklos Vajna
AuthorDate: Thu Feb 2 20:10:17 2023 +0100
Commit: Miklos Vajna
CommitDate: Fri Feb 3 07:11:51 2023 +
sw layout xml dump: extract SwTable::dumpAsXml() from SwTableNode
The idea is that each class only dumps itself & what it owns, otherwise
the same info is dumped multiple times.
Change-Id: Ib21bd2d31aa0d70d58b2b8aa453e0ede788c7144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146511
Tested-by: Jenkins
Reviewed-by: Miklos Vajna
diff --git a/sw/inc/swtable.hxx b/sw/inc/swtable.hxx
index 0ad1deffb42e..3858c55217be 100644
--- a/sw/inc/swtable.hxx
+++ b/sw/inc/swtable.hxx
@@ -357,6 +357,8 @@ public:
// it doesn't contain box content (except single empty nested tables of
the boxes
// which could remain after deletion of text content of the selected table)
bool IsEmpty() const;
+
+void dumpAsXml(xmlTextWriterPtr pWriter) const;
};
/// SwTableLine is one table row in the document model.
diff --git a/sw/source/core/docnode/ndtbl.cxx b/sw/source/core/docnode/ndtbl.cxx
index 77f7a4d3e97c..5e2cd8605bdd 100644
--- a/sw/source/core/docnode/ndtbl.cxx
+++ b/sw/source/core/docnode/ndtbl.cxx
@@ -2488,17 +2488,7 @@ void SwTableNode::dumpAsXml(xmlTextWriterPtr pWriter)
const
if (m_pTable)
{
-(void)xmlTextWriterStartElement(pWriter, BAD_CAST("SwTable"));
-(void)xmlTextWriterWriteFormatAttribute(pWriter, BAD_CAST("ptr"),
"%p", m_pTable.get());
-m_pTable->GetFrameFormat()->dumpAsXml(pWriter);
-for (const auto& pLine : m_pTable->GetTabLines())
-{
-(void)xmlTextWriterStartElement(pWriter, BAD_CAST("SwTableLine"));
-(void)xmlTextWriterWriteFormatAttribute(pWriter, BAD_CAST("ptr"),
"%p", pLine);
-pLine->GetFrameFormat()->dumpAsXml(pWriter);
-(void)xmlTextWriterEndElement(pWriter);
-}
-(void)xmlTextWriterEndElement(pWriter);
+m_pTable->dumpAsXml(pWriter);
}
// (void)xmlTextWriterEndElement(pWriter); - it is a start node, so don't
end, will make xml better nested
diff --git a/sw/source/core/table/swtable.cxx b/sw/source/core/table/swtable.cxx
index 7fa3c3caea4d..06c76771434d 100644
--- a/sw/source/core/table/swtable.cxx
+++ b/sw/source/core/table/swtable.cxx
@@ -17,6 +17,8 @@
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
+#include
+
#include
#include
#include
@@ -1610,6 +1612,21 @@ bool SwTable::IsDeleted() const
return true;
}
+void SwTable::dumpAsXml(xmlTextWriterPtr pWriter) const
+{
+(void)xmlTextWriterStartElement(pWriter, BAD_CAST("SwTable"));
+(void)xmlTextWriterWriteFormatAttribute(pWriter, BAD_CAST("ptr"), "%p",
this);
+GetFrameFormat()->dumpAsXml(pWriter);
+for (const auto& pLine : GetTabLines())
+{
+(void)xmlTextWriterStartElement(pWriter, BAD_CAST("SwTableLine"));
+(void)xmlTextWriterWriteFormatAttribute(pWriter, BAD_CAST("ptr"),
"%p", pLine);
+pLine->GetFrameFormat()->dumpAsXml(pWriter);
+(void)xmlTextWriterEndElement(pWriter);
+}
+(void)xmlTextWriterEndElement(pWriter);
+}
+
// TODO Set HasTextChangesOnly=true, if needed based on the redlines in the
cells.
// At tracked row deletion, return with the newest deletion of the row or
// at tracked row insertion, return with the oldest insertion in the row, which
[Libreoffice-bugs] [Bug 153330] The XFilePickerControlAccess.setLabel method does not change the name of the "Open" button (when LO Open/Save dialogs are not used).
https://bugs.documentfoundation.org/show_bug.cgi?id=153330 Mike Kaganski changed: What|Removed |Added Ever confirmed|0 |1 CC||caol...@redhat.com Status|UNCONFIRMED |NEW Component|UI |sdk Keywords||difficultyBeginner, ||easyHack, skillCpp --- Comment #2 from Mike Kaganski --- Repro using Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded and also on gtk3 (the button label is "Open", not the requested "Select"). Code pointer specific for Windows: In VistaFilePickerImpl::impl_sta_SetControlLabel, the constant css::ui::dialogs::CommonFilePickerElementIds::PUSHBUTTON_OK should be handled explicitly, and instead of IFileDialogCustomize::SetControlLabel, another function should be called: IFileDialog::SetOkButtonLabel. A similar handling is possible for filename box label: IFileDialog::SetFileNameLabel. Other integrations (like gtk3) need their own fixes (if possible). -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 83066] [META] CJK (Chinese, Japanese, Korean, and Vietnamese) language issues
https://bugs.documentfoundation.org/show_bug.cgi?id=83066 Bug 83066 depends on bug 153324, which changed state. Bug 153324 Summary: Wrong kerning in print preview of CJK characters https://bugs.documentfoundation.org/show_bug.cgi?id=153324 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153324] Wrong kerning in print preview of CJK characters
https://bugs.documentfoundation.org/show_bug.cgi?id=153324 Faisal changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Faisal --- Issue disappeared after a profile reset. Marking as worksforme -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150585] Crash when recording macro with Find/Replace
https://bugs.documentfoundation.org/show_bug.cgi?id=150585 --- Comment #19 from grofaty --- I tested this bug in LibreOffice 7.5.0.3 as flatpak on Ubuntu 22.10 and problem is fixed. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153340] New: Table - Edit - Insert Row between existing rows often does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=153340 Bug ID: 153340 Summary: Table - Edit - Insert Row between existing rows often does not work Product: LibreOffice Version: 7.5.0.3 release Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Base Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: petersmith60...@gmail.com Description: When I need to insert a row between existing rows in a table design, the Insert Row command often doesn't work. Instead, it moves the cursor to the end of the field list and attempts to insert the row there. This issue existed in V7.4 also. I like to keep my table designs neat and tidy by listing indexed fields used in table relationships together at the top of the table layout. Steps to Reproduce: 1.Edit a preexisting table having at least 2 rows 2.Right click in the column to the left of the field name 3.Choose Insert Rows Actual Results: In my case the cursor shifts to the row after the second row to insert the row at that point. Expected Results: A new empty row should appear at the point I chose, and all subsequent rows should shift downwards. Reproducible: Sometimes User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: OfficeDatabaseDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: yes Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 16; OS: Windows 11.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 --- Comment #2 from Tex2002ans --- I agree with Eyal. Having an easy-to-access "page color" toggle would help, because all 4 options could be taken: - Light UI + White Page - Light UI + Dark Page - Dark UI + White Page --- (This is what I prefer most of the time.) - Dark UI + Dark Page This is especially helpful when dealing with colors + contrast issues. - - - *Insert famous psychology experiment of same color looking completely different on white or black backgrounds.* See famous blue/black or white/gold dress! - https://www.techdirt.com/2015/02/27/have-you-been-debating-what-color-some-random-dress-is-all-day-thank-fair-use/ - - - Most documents are printed on white paper, so need color accuracy, but in order to not be blinded at night, I might want a darker shade page temporarily. Currently, going through: - Tools > Options - LibreOffice > Application Colors then choosing: - Application Background - Change color to Automatic<->White (Or toggling Scheme between LibreOffice<->LibreOffice Dark + tweaks) is a little clunky. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 --- Comment #2 from Tex2002ans --- I agree with Eyal. Having an easy-to-access "page color" toggle would help, because all 4 options could be taken: - Light UI + White Page - Light UI + Dark Page - Dark UI + White Page --- (This is what I prefer most of the time.) - Dark UI + Dark Page This is especially helpful when dealing with colors + contrast issues. - - - *Insert famous psychology experiment of same color looking completely different on white or black backgrounds.* See famous blue/black or white/gold dress! - https://www.techdirt.com/2015/02/27/have-you-been-debating-what-color-some-random-dress-is-all-day-thank-fair-use/ - - - Most documents are printed on white paper, so need color accuracy, but in order to not be blinded at night, I might want a darker shade page temporarily. Currently, going through: - Tools > Options - LibreOffice > Application Colors then choosing: - Application Background - Change color to Automatic<->White (Or toggling Scheme between LibreOffice<->LibreOffice Dark + tweaks) is a little clunky. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153339] New: Feature request: Add option to NOT round up very large numbers or any numbers
https://bugs.documentfoundation.org/show_bug.cgi?id=153339 Bug ID: 153339 Summary: Feature request: Add option to NOT round up very large numbers or any numbers Product: LibreOffice Version: 7.5.0.3 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: n...@lacasses.com Description: Hi, I would like to request a feature to show and calc exact numbers instead of rounding up. I don't want a ballpark number, I want the exact number. If my number is 5461154115994554615, that is what I want in the cell and what I want to be used to do the calculation. Thanks, NRL Actual Results: 546115411599455 Expected Results: 5461154115994554615 Reproducible: Always User Profile Reset: No Additional Info: 4615 isn't much in a large number but if you are calculating 50 or 100 or 200 cells, that small amount becomes a very large amount difference in the final total. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153338] New: Wrong position when importing DOC with frame in header that spills outside of page
https://bugs.documentfoundation.org/show_bug.cgi?id=153338 Bug ID: 153338 Summary: Wrong position when importing DOC with frame in header that spills outside of page Product: LibreOffice Version: 7.4.5.1 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: filters and storage Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: jorge.moral...@gmail.com Created attachment 185076 --> https://bugs.documentfoundation.org/attachment.cgi?id=185076=edit doc file that causes the problem (anonymized so it can be made public) Dear developers, The attached doc file contains a frame in the header that is too wide for the position specified. So the frame goes beyond the right edge of the page (when opened in MS Word one can see this). When I convert the doc using libreoffice, the width of the frame is maintained but the position is changed (shifted left) so the frame's right edge fits just at the right edge of the page. I assume this behavior is not really "a bug" but the result of forcing the frame to fit within the page. If libreoffice must indeed have all frames within the page, can the importer be configured to force frames inside the page by modifying the width/height of the frame rather than its position? In this document, the result of modifying the width rather than the position would be much more desirable (since the part of the frame that spills outside of the page does not have any visible information). I can imagine that changing the width (height) could produce better results not only in this case but in many others. So can the importer be configured to preserve position rather than size? If not, this would be a feature request to enable manual configuration of whether to preserve position or size when forcing frames to fit inside a page . Of course an automatic heuristic that chooses between changing position and trimming size (or a combination of both) based on the fact that trimming white space that falls outside of the page is acceptable might be even better than a manual configuration switch. Thank you for your contributions to the open source community! By the way I received the original document with the problem described from a customer. I have anonymized it by using a binary editor to replace actual words with x so it can be placed in the public domain without issue. The issue may be present in versions of libreoffice earlier than the one reported, but this is the one I have access to. (I run libreoffice in linux debian bookworm installed from the package manager) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 76131] Existing pinned icon on Win7/8/10/11 is taskbar invalid after re-installation/update
https://bugs.documentfoundation.org/show_bug.cgi?id=76131 Mike Kaganski changed: What|Removed |Added CC||i...@dietmar-repare.fr --- Comment #73 from Mike Kaganski --- *** Bug 153337 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153337] Updating LibreOffice deletes taskbar links and swaps start menu links
https://bugs.documentfoundation.org/show_bug.cgi?id=153337 Mike Kaganski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mike Kaganski --- *** This bug has been marked as a duplicate of bug 76131 *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153327] LO crashes on create/edit comment in Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=153327 Daniel changed: What|Removed |Added OS|macOS (All) |Linux (All) Hardware|ARM |x86-64 (AMD64) CC||dan.dun...@gmail.com Version|7.5.0.3 release |7.5.0.1 rc --- Comment #4 from Daniel --- Error reproduced. Works after starting with fresh profile. Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: 50(Build:3) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 7.5.0-1 Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'distro/collabora/co-22.05' - vcl/jsdialog
vcl/jsdialog/jsdialogbuilder.cxx |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
New commits:
commit 196079fe57de17ee5e635064f6eb9be30b6efb09
Author: Szymon Kłos
AuthorDate: Thu Feb 2 11:57:48 2023 +0100
Commit: Aron Budea
CommitDate: Fri Feb 3 04:00:19 2023 +
jsdialog: weld all message boxes
This fixes regression from:
commit 9785cebe4cfdc296143757da6098a74b0252c618
jsdialog: fix validation error dialog in Calc
When inserting autofilter without header data
- message box should appear
Change-Id: Id5d26604a67f43700310cc0f51954b886c9de0f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146495
Reviewed-by: Henry Castro
Tested-by: Jenkins CollaboraOffice
diff --git a/vcl/jsdialog/jsdialogbuilder.cxx b/vcl/jsdialog/jsdialogbuilder.cxx
index 7d8579ba7483..3998ddf0e130 100644
--- a/vcl/jsdialog/jsdialogbuilder.cxx
+++ b/vcl/jsdialog/jsdialogbuilder.cxx
@@ -1184,8 +1184,7 @@ weld::MessageDialog*
JSInstanceBuilder::CreateMessageDialog(weld::Widget* pParen
else
SAL_WARN("vcl", "No notifier in
JSInstanceBuilder::CreateMessageDialog");
-// fallback
-return new SalInstanceMessageDialog(xMessageDialog, nullptr, true);
+return new JSMessageDialog(xMessageDialog, nullptr, true);
}
JSDialog::JSDialog(JSDialogSender* pSender, ::Dialog* pDialog,
SalInstanceBuilder* pBuilder,
[Libreoffice-bugs] [Bug 152686] UI: Hamburger menu looks like gray square in start center with macOS dark mode
https://bugs.documentfoundation.org/show_bug.cgi?id=152686 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150649] odd behaviors when clicking help buttons in pop windows (settings, format cells, so on and so forth)
https://bugs.documentfoundation.org/show_bug.cgi?id=150649 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151274] Event "Losing focus" happens twice for Listbox and Combobox in a tablecontrol
https://bugs.documentfoundation.org/show_bug.cgi?id=151274 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153114] Customization not Working for Groupedbar Compact UI
https://bugs.documentfoundation.org/show_bug.cgi?id=153114 QA Administrators changed: What|Removed |Added Whiteboard|| QA:needsComment -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150215] CONFIGURATION (possibility of allowing multiple sheets/tabs)
https://bugs.documentfoundation.org/show_bug.cgi?id=150215 --- Comment #4 from QA Administrators --- Dear Chris, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150021] Sentence disappear when I press Enter
https://bugs.documentfoundation.org/show_bug.cgi?id=150021 --- Comment #2 from QA Administrators --- Dear up61963, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 149739] General input/output error saving complex spreadsheet
https://bugs.documentfoundation.org/show_bug.cgi?id=149739 --- Comment #2 from QA Administrators --- Dear Tim Daley, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 84449] URL highlighting ignoring '|' character
https://bugs.documentfoundation.org/show_bug.cgi?id=84449 --- Comment #7 from QA Administrators --- Dear Sebastian Posch, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 76280] FORMATTING: Upper table border is missing on subsequent pages/columns (after page / column breaks)
https://bugs.documentfoundation.org/show_bug.cgi?id=76280 --- Comment #14 from QA Administrators --- Dear Marc PHILIPPE, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 41775] Don't remove all menus when no windows are open - keep Tools and Help
https://bugs.documentfoundation.org/show_bug.cgi?id=41775 --- Comment #24 from QA Administrators --- Dear Shad Sterling, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 140082] Undo doesn't restore original layout (likely frame anchoring related)
https://bugs.documentfoundation.org/show_bug.cgi?id=140082 --- Comment #5 from QA Administrators --- Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 139924] Tools > Autocorrect > Apply with "Replace bullets with" only works with Default Style in [M], while hyphen is not converted to chosen symbol in [T], and chosen bullet s
https://bugs.documentfoundation.org/show_bug.cgi?id=139924 --- Comment #6 from QA Administrators --- Dear sdc.blanco, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137752] Paragraph indent is limited
https://bugs.documentfoundation.org/show_bug.cgi?id=137752 --- Comment #8 from QA Administrators --- Dear John, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 118295] Improve gridlines option UI
https://bugs.documentfoundation.org/show_bug.cgi?id=118295 --- Comment #18 from QA Administrators --- Dear Heiko Tietze, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 115328] Impress: paragraph margins do not work correctly with AutoFit text boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=115328 --- Comment #5 from QA Administrators --- Dear sergio.callegari, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 114827] FILESAVE of Letter Wizard is complaining about existing file if you cancel saving
https://bugs.documentfoundation.org/show_bug.cgi?id=114827 --- Comment #4 from QA Administrators --- Dear Clemens Prill, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 113955] EDITING: embedded table changes the style after editing it
https://bugs.documentfoundation.org/show_bug.cgi?id=113955 --- Comment #5 from QA Administrators --- Dear Xisco Faulí, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 113177] Can't select part of cell in read-only Calc spreadsheet
https://bugs.documentfoundation.org/show_bug.cgi?id=113177 --- Comment #5 from QA Administrators --- Dear Dan Dascalescu, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 105510] Bullets and numbering contained in a table cell don't get pasted using paste special formatted text
https://bugs.documentfoundation.org/show_bug.cgi?id=105510 --- Comment #8 from QA Administrators --- Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 96000] [META] Spelling and grammar checking bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=96000 Bug 96000 depends on bug 97595, which changed state. Bug 97595 Summary: Create list of misspelled and corrected words from spellcheck process ? https://bugs.documentfoundation.org/show_bug.cgi?id=97595 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 97595] Create list of misspelled and corrected words from spellcheck process ?
https://bugs.documentfoundation.org/show_bug.cgi?id=97595 Shantanu changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #8 from Shantanu --- You can check this list based spell-checker extension. https://extensions.libreoffice.org/en/extensions/show/20644 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153113] Writer does not open at the last cursor position with a long file
https://bugs.documentfoundation.org/show_bug.cgi?id=153113 --- Comment #5 from alan.ger...@opcug.ca --- (In reply to Buovjaga from comment #2) > Just to check, as the cursor position is saved based on user information, do > you have data in Tools - Options - LibreOffice - User Data? Yes, there are entries for First/last_name/initials. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153113] Writer does not open at the last cursor position with a long file
https://bugs.documentfoundation.org/show_bug.cgi?id=153113 --- Comment #4 from alan.ger...@opcug.ca --- (In reply to csyu.279 from comment #1) > Is the 140 pg file available for us to use so we can test for the bug? Regret, this is not a public document; however, I would expect the same behaviour from any large file. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'private/tvajngerl/staging' - 6 commits - basctl/source basegfx/CppunitTest_basegfx.mk basegfx/test chart2/source cui/source editeng/source filter/source include
Rebased ref, commits from common ancestor:
commit 33b00eac7f6fecdb9ed0f0195dc9f72eb2c06493
Author: Tomaž Vajngerl
AuthorDate: Wed Nov 23 11:00:13 2022 +0900
Commit: Tomaž Vajngerl
CommitDate: Fri Feb 3 11:49:33 2023 +0900
svx: convert SdrTextObj rotate and move to use gfx::Length
Change-Id: I82f10f82db8ac9d5653f4902276ee58fc18c52d6
diff --git a/include/basegfx/utils/RectangleWrapper.hxx
b/include/basegfx/utils/RectangleWrapper.hxx
index 00586d6eae71..4f5dbe851f66 100644
--- a/include/basegfx/utils/RectangleWrapper.hxx
+++ b/include/basegfx/utils/RectangleWrapper.hxx
@@ -55,6 +55,11 @@ public:
m_aRange.setSize(width, height);
}
+void shift(gfx::Length const& rXDelta, gfx::Length const& rYDelta)
+{
+m_aRange.shift(rXDelta, rYDelta);
+}
+
void move(sal_Int32 nXDelta, sal_Int32 nYDelta)
{
auto deltaX = gfx::Length::hmm(nXDelta);
diff --git a/svx/source/svdraw/svdotxtr.cxx b/svx/source/svdraw/svdotxtr.cxx
index 1055e5dbe3bb..9ccc69709abf 100644
--- a/svx/source/svdraw/svdotxtr.cxx
+++ b/svx/source/svdraw/svdotxtr.cxx
@@ -40,6 +40,35 @@
using namespace com::sun::star;
+namespace
+{
+gfx::Tuple2DL rotatePoint(gfx::Tuple2DL const& rPoint, gfx::Tuple2DL const&
rReference, double sinAngle, double cosAngle)
+{
+gfx::Length dx = rPoint.getX() - rReference.getX();
+gfx::Length dy = rPoint.getY() - rReference.getY();
+
+auto x = rReference.getX() + gfx::Length::emu(basegfx::fround(dx.raw() *
cosAngle + dy.raw() * sinAngle));
+auto y = rReference.getY() + gfx::Length::emu(basegfx::fround(dy.raw() *
cosAngle - dx.raw() * sinAngle));
+
+return gfx::Tuple2DL(x, y);
+}
+
+gfx::Tuple2DL toTuple(Point const& rPointHmm)
+{
+auto x = gfx::Length::hmm(rPointHmm.X());
+auto y = gfx::Length::hmm(rPointHmm.Y());
+return {x, y};
+}
+
+gfx::Size2DL toSize2D(Size const& rSizeHmm)
+{
+auto x = gfx::Length::hmm(rSizeHmm.Width());
+auto y = gfx::Length::hmm(rSizeHmm.Height());
+return {x, y};
+}
+
+} // end anonymous ns
+
void SdrTextObj::NbcSetSnapRect(const tools::Rectangle& rRect)
{
if (maGeo.nRotationAngle || maGeo.nShearAngle)
@@ -92,7 +121,9 @@ Degree100 SdrTextObj::GetShearAngle(bool /*bVertical*/) const
void SdrTextObj::NbcMove(const Size& rSize)
{
-moveRectangle(rSize.Width(), rSize.Height());
+gfx::Size2DL aSize2D = toSize2D(rSize);
+maRectangle.shift(aSize2D.getWidth(), aSize2D.getHeight());
+
moveOutRectangle(rSize.Width(), rSize.Height());
maSnapRect.Move(rSize);
SetBoundAndSnapRectsDirty(true);
@@ -183,27 +214,37 @@ void SdrTextObj::NbcResize(const Point& rRef, const
Fraction& xFact, const Fract
SetBoundAndSnapRectsDirty();
}
-void SdrTextObj::NbcRotate(const Point& rRef, Degree100 nAngle, double sn,
double cs)
+void SdrTextObj::NbcRotate(const Point& rRef, Degree100 nAngle, double
sinAngle, double cosAngle)
{
+auto aReference = toTuple(rRef);
+
SetGlueReallyAbsolute(true);
-tools::Long dx = getRectangle().Right() - getRectangle().Left();
-tools::Long dy = getRectangle().Bottom() - getRectangle().Top();
-Point aPoint1(getRectangle().TopLeft());
-RotatePoint(aPoint1, rRef, sn, cs);
-Point aPoint2(aPoint1.X() + dx, aPoint1.Y() + dy);
-tools::Rectangle aRectangle(aPoint1, aPoint2);
-setRectangle(aRectangle);
+auto const& rRange = maRectangle.getRange();
+
+auto nWidth = rRange.getWidth();
+auto nHeight = rRange.getHeight();
+
+gfx::Tuple2DL aPoint1(rRange.getMinX(), rRange.getMinY());
+aPoint1 = rotatePoint(aPoint1, aReference, sinAngle, cosAngle);
-if (maGeo.nRotationAngle==0_deg100) {
-maGeo.nRotationAngle=NormAngle36000(nAngle);
-maGeo.mfSinRotationAngle=sn;
-maGeo.mfCosRotationAngle=cs;
-} else {
-maGeo.nRotationAngle=NormAngle36000(maGeo.nRotationAngle+nAngle);
+gfx::Tuple2DL aPoint2(aPoint1.getX() + nWidth, aPoint1.getY() + nHeight);
+
+gfx::Range2DL aRange{aPoint1, aPoint2};
+maRectangle.setRange(aRange);
+
+if (maGeo.nRotationAngle == 0_deg100)
+{
+maGeo.nRotationAngle = NormAngle36000(nAngle);
+maGeo.mfSinRotationAngle = sinAngle;
+maGeo.mfCosRotationAngle = cosAngle;
+}
+else
+{
+maGeo.nRotationAngle = NormAngle36000(maGeo.nRotationAngle + nAngle);
maGeo.RecalcSinCos();
}
SetBoundAndSnapRectsDirty();
-NbcRotateGluePoints(rRef,nAngle,sn,cs);
+NbcRotateGluePoints(rRef, nAngle, sinAngle, cosAngle);
SetGlueReallyAbsolute(false);
}
commit b46c3917b16396b9cfd61bd17586494957b3afce
Author: Tomaž Vajngerl
AuthorDate: Tue Nov 22 13:33:30 2022 +0900
Commit: Tomaž Vajngerl
CommitDate: Fri Feb 3 11:49:33 2023 +0900
svx: use RectangleWrapper for maRectangle on SdrTextObj
This is needed so we can now transition to use gfx::Length and
gfx::Range2DL to define the object position and size.
Change-Id:
[Libreoffice-bugs] [Bug 153337] Updating LibreOffice deletes taskbar links and swaps start menu links
https://bugs.documentfoundation.org/show_bug.cgi?id=153337 Dietmar changed: What|Removed |Added Summary|Updating LibreOffice|Updating LibreOffice |deletes links or messes |deletes taskbar links and |them up |swaps start menu links -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153336] enhancement bug for setup : installation automation with configuration file
https://bugs.documentfoundation.org/show_bug.cgi?id=153336 Dietmar changed: What|Removed |Added Summary|enhancement bug for setup : |enhancement bug for setup : |automation with |installation automation |configuration file |with configuration file -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153336] enhancement bug for setup : automation with configuration file
https://bugs.documentfoundation.org/show_bug.cgi?id=153336 Dietmar changed: What|Removed |Added Summary|enhancement bug for setup : |enhancement bug for setup : |add a configuration file|automation with ||configuration file -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153336] enhancement bug for setup : add a configuration file
https://bugs.documentfoundation.org/show_bug.cgi?id=153336 Dietmar changed: What|Removed |Added Summary|enhancement bug for setup - |enhancement bug for setup : |configuration file |add a configuration file -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153337] New: Updating LibreOffice deletes links or messes them up
https://bugs.documentfoundation.org/show_bug.cgi?id=153337 Bug ID: 153337 Summary: Updating LibreOffice deletes links or messes them up Product: LibreOffice Version: unspecified Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: minor Priority: medium Component: Installation Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: i...@dietmar-repare.fr Description: Hi, Thank you for LibreOffice. As a computer engineer, I frequently install LibreOffice on my clients' computers. When updating LibreOffice, it would help me a lot if the existing links in the Windows taskbar were not always deleted and the order of the links in the Start menu were swapped. As an example: I would like to preconfigure links in the taskbar and start menu for my customers for easier access, e.g. for LibreOffice, LibreOffice Writer and LibreOffice Calc in exactly this order. After installing a new version, all these links in the taskbar regularly disappear and the order in the Start menu is, for example, LibreOffice Calc - LibreOffice - LibreOffice Writer. Of course, this is not a big problem, but it is a bit annoying if you have to move or recreate these links unnecessarily several times a day. A revision of this part of the setup would be really cool! Have a nice day, Dietmar. Steps to Reproduce: 1.Install LibreOffice 2.Pin for example Libre Office, LibreOffice Writer and LibreOffice Calc to the TaskBar and the Start Menu 3.Install an update of LibreOffice (tested with customized setup) Actual Results: LibreOffice icons in Start Menu are messed up and LibreOffice Icons in TaskBar disappear Expected Results: LibreOffice icons in Start Menu keep their order and LibreOffice icons in the TaskBar do not disappear Reproducible: Always User Profile Reset: No Additional Info: A fix would be great :-) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'libreoffice-7-5' - sc/source
sc/source/ui/app/inputwin.cxx |9 +
sc/source/ui/inc/inputwin.hxx |2 --
2 files changed, 1 insertion(+), 10 deletions(-)
New commits:
commit 9739a874b64e770728d62713b070f37de4ec8328
Author: Samuel Mehrbrodt
AuthorDate: Thu Jan 26 16:52:32 2023 +0100
Commit: Kohei Yoshida
CommitDate: Fri Feb 3 02:06:13 2023 +
tdf#151682 Fix gap above input bar
Remove vertical offset, looks like it's not needed anymore.
Change-Id: If0f7f7dce7a7e4249036930b60fe353890b495fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146179
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt
(cherry picked from commit f7544650cc4e31da67873898e2d587afa846b9b4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146199
Reviewed-by: Kohei Yoshida
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index 14ef498976ba..14249fe2eb04 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -495,7 +495,7 @@ void ScInputWindow::Resize()
if (pGroupBar->GetNumLines() > 1)
{
Size aGroupBarSize = pGroupBar->GetSizePixel();
-aSize.setHeight(aGroupBarSize.Height() + 2 *
(pGroupBar->GetVertOffset() + 1));
+aSize.setHeight(aGroupBarSize.Height());
}
}
SetSizePixel(aSize);
@@ -847,7 +847,6 @@ ScInputBarGroup::ScInputBarGroup(vcl::Window* pParent,
ScTabViewShell* pViewSh)
, mxTextWndGroup(new ScTextWndGroup(*this, pViewSh))
, mxButtonUp(m_xBuilder->weld_button("up"))
, mxButtonDown(m_xBuilder->weld_button("down"))
-, mnVertOffset(0)
{
InitControlBase(m_xContainer.get());
@@ -1083,12 +1082,6 @@ void ScInputBarGroup::TriggerToolboxLayout()
ScInputWindow = dynamic_cast(*w);
SfxViewFrame* pViewFrm = SfxViewFrame::Current();
-// Capture the vertical position of this window in the toolbar, when we
increase
-// the size of the toolbar to accommodate expanded line input we need to
take this
-// into account
-if ( !mnVertOffset )
-mnVertOffset = rParent.GetItemPosRect( rParent.GetItemCount() - 1
).Top();
-
if ( !pViewFrm )
return;
diff --git a/sc/source/ui/inc/inputwin.hxx b/sc/source/ui/inc/inputwin.hxx
index 12bc461f2836..ac96062af137 100644
--- a/sc/source/ui/inc/inputwin.hxx
+++ b/sc/source/ui/inc/inputwin.hxx
@@ -262,7 +262,6 @@ public:
voidDecrementVerticalSize();
voidNumLinesChanged();
virtual tools::LongGetNumLines() const override { return
mxTextWndGroup->GetNumLines(); }
-tools::LongGetVertOffset() const { return
mnVertOffset; }
int GetPixelHeightForLines() const
{
@@ -278,7 +277,6 @@ private:
std::unique_ptr mxTextWndGroup;
std::unique_ptr mxButtonUp;
std::unique_ptr mxButtonDown;
-tools::Long mnVertOffset;
DECL_LINK(ClickHdl, weld::Button&, void);
};
[Libreoffice-bugs] [Bug 153336] New: enhancement bug for setup - configuration file
https://bugs.documentfoundation.org/show_bug.cgi?id=153336 Bug ID: 153336 Summary: enhancement bug for setup - configuration file Product: LibreOffice Version: unspecified Hardware: All OS: Windows (All) Status: UNCONFIRMED Severity: enhancement Priority: medium Component: Installation Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: i...@dietmar-repare.fr Description: Hi, I am a computer scientist and I really appreciate LibreOffice and its developers. I frequently install LibreOffice on my clients' computers and on the computers of several primary schools. I always use the customised installation, for example to add certain dictionaries or to select Writer as the default programme. In order to be able to automate this custom installation, I would really appreciate as a new feature (if it does not already exist contrary to my knowledge) an easily customisable and reusable configuration file for these settings in the style of a setup.ini, which is automatically used by the setup if this file exists. It would also be nice to be able to specify standard answers for example for a possible restart, so that the customised installation can run completely without user intervention... Have a nice day, Dietmar. Platform : Windows Steps to Reproduce: 1.start setup 2. 3. Actual Results: setup is not automatable with configuration file Expected Results: setup is automatable with configuration file Reproducible: Always User Profile Reset: No Additional Info: would be very nice if possible :-) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153246] FILESAVE DOCX actual handle positions are not written to VML
https://bugs.documentfoundation.org/show_bug.cgi?id=153246 --- Comment #5 from Regina Henschel --- The bug is fixed for the special case of preset Fontwork shapes. Prior to extending the fix to other preset shapes, bug 153296 needs to be solved. For other preset shapes the VML export is only a Fallback for MS Office versions older than 2010 and therefore has a low priority. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 112364] Automatic saving on exit without prompt
https://bugs.documentfoundation.org/show_bug.cgi?id=112364 --- Comment #12 from Justin L --- Saving on exit would be the same thing as getting rid of the "cancel" button on all dialogs and only having an "OK" option. Clearly a bad thing. Only in extreme situations should "auto-save" affect the working document - it certainly does not apply to the general desktop application, and doing so as a default config would be a tragedy. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153246] FILESAVE DOCX actual handle positions are not written to VML
https://bugs.documentfoundation.org/show_bug.cgi?id=153246 Commit Notification changed: What|Removed |Added Whiteboard||target:7.6.0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: oox/qa oox/source
oox/qa/unit/data/tdf153246_VML_export_Fontwork_Adjustment.odt |binary
oox/qa/unit/export.cxx| 27 ++
oox/source/export/vmlexport.cxx | 26 +
3 files changed, 53 insertions(+)
New commits:
commit a834bbad8295cba0ca88a91a524aad48640271ec
Author: Regina Henschel
AuthorDate: Thu Feb 2 23:24:01 2023 +0100
Commit: Regina Henschel
CommitDate: Fri Feb 3 01:17:48 2023 +
tdf#153246 VML export write adj attribute for Fontwork
The fix for tdf#153296 has introduced correct shapetype markup for
Fontwork shapes so that handles are moveable in Word. But the actual
adjustment value of the handle was not exported. This patch adds the
missing 'adj' attribute to the element.
The fix is restricted to the preset Fontwork types because for other
shapetypes the VML export is not yet suitable in regard to handles.
Change-Id: I7ecda9e63d50ab7d8c1fda3e09f7383546ddaf5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146537
Tested-by: Jenkins
Reviewed-by: Regina Henschel
diff --git a/oox/qa/unit/data/tdf153246_VML_export_Fontwork_Adjustment.odt
b/oox/qa/unit/data/tdf153246_VML_export_Fontwork_Adjustment.odt
new file mode 100644
index ..1a26191821cf
Binary files /dev/null and
b/oox/qa/unit/data/tdf153246_VML_export_Fontwork_Adjustment.odt differ
diff --git a/oox/qa/unit/export.cxx b/oox/qa/unit/export.cxx
index 64c97b56a24d..50c953135623 100644
--- a/oox/qa/unit/export.cxx
+++ b/oox/qa/unit/export.cxx
@@ -883,6 +883,33 @@ CPPUNIT_TEST_FIXTURE(Test, testVMLFontworkArchUp)
// ..., but a element with subelement
assertXPath(pXmlDoc, "//v:shapetype/v:textpath", 1);
}
+
+CPPUNIT_TEST_FIXTURE(Test, testVMLAdjustmentExport)
+{
+// The document has a Fontwork shape type 'textCirclePour' (150). When
exporting to docx, the
+// adjustment values were not exported at all.
+loadFromURL(u"tdf153246_VML_export_Fontwork_Adjustment.odt");
+
+// FIXME: tdf#153183 validation error in OOXML export: Errors: 1
+// Attribute 'ID' is not allowed to appear in element 'v:shape'.
+skipValidation();
+
+// Save to DOCX:
+save("Office Open XML Text");
+
+// Examine the saved markup.
+xmlDocUniquePtr pXmlDoc = parseExport("word/document.xml");
+
+// Make sure an "adj" attribute exists
+assertXPath(pXmlDoc, "//v:shape[@adj]", 1);
+// ... and has the correct values
+OUString sAdjustments = getXPath(pXmlDoc, "//v:shape", "adj");
+sal_Int32 nTokenStart = 0;
+OUString sAngle = sAdjustments.getToken(0, ',', nTokenStart);
+CPPUNIT_ASSERT_DOUBLES_EQUAL(sal_Int32(-7341733), sAngle.toInt32(), 2);
+OUString sRadius = sAdjustments.copy(nTokenStart);
+CPPUNIT_ASSERT_DOUBLES_EQUAL(sal_Int32(5296), sRadius.toInt32(), 2);
+}
}
CPPUNIT_PLUGIN_IMPLEMENT();
diff --git a/oox/source/export/vmlexport.cxx b/oox/source/export/vmlexport.cxx
index 82d92536b226..3a7fb417f2fc 100644
--- a/oox/source/export/vmlexport.cxx
+++ b/oox/source/export/vmlexport.cxx
@@ -1010,6 +1010,32 @@ void VMLExport::Commit( EscherPropertyContainer& rProps,
const tools::Rectangle&
bAlreadyWritten[ESCHER_Prop_gtextFont] = true;
}
break;
+case DFF_Prop_adjustValue:
+case DFF_Prop_adjust2Value:
+{
+// FIXME: tdf#153296: The currently exported markup for
is based on
+// OOXML presets and unusable in regard to handles.
Fontwork shapes use dedicated
+// own markup, see
FontworkHelpers::GetVMLFontworkShapetypeMarkup.
+// Thus this is restricted to preset Fontwork shapes. Such
have maximal two
+// adjustment values.
+if ((mso_sptTextSimple <= m_nShapeType && m_nShapeType <=
mso_sptTextOnRing)
+|| (mso_sptTextPlainText <= m_nShapeType &&
m_nShapeType <= mso_sptTextCanDown))
+{
+sal_uInt32 nValue;
+OString sAdj;
+if (rProps.GetOpt(DFF_Prop_adjustValue, nValue))
+{
+sAdj =
OString::number(static_cast(nValue));
+if (rProps.GetOpt(DFF_Prop_adjust2Value, nValue))
+sAdj += "," +
OString::number(static_cast(nValue));
+}
+if (!sAdj.isEmpty())
+m_pShapeAttrList->add(XML_adj, sAdj);
+bAlreadyWritten[DFF_Prop_adjustValue] = true;
+bAlreadyWritten[DFF_Prop_adjust2Value] = true;
+}
+}
+break;
case ESCHER_Prop_Rotation:
{
// The higher half of the variable contains the angle.
[Libreoffice-bugs] [Bug 150037] Upon entering a legacy text fieldmark, placeholder text should be recognized as default text and thus pre-selected (so typing overwrites)
https://bugs.documentfoundation.org/show_bug.cgi?id=150037 Justin L changed: What|Removed |Added Summary|Writer: Entering text in|Upon entering a legacy text |text field in docx-file |fieldmark, placeholder text |should replace default |should be recognized as |placeholders|default text and thus ||pre-selected (so typing ||overwrites) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153327] LO crashes on create/edit comment in Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=153327 m.a.riosv changed: What|Removed |Added CC||miguelangelrv@libreoffice.o ||rg --- Comment #3 from m.a.riosv --- Works for me Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Please test with a clean profile, Menu/Help/Restart in Safe Mode -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152804] (python generated) TABLES: Numbers in a cell equal to or greater than 10 are set to 0 upon saving and re-opening
https://bugs.documentfoundation.org/show_bug.cgi?id=152804 Justin L changed: What|Removed |Added Summary|TABLES: Numbers in a cell |(python generated) TABLES: |equal to or greater than 10 |Numbers in a cell equal to |are set to 0 upon saving|or greater than 10 are set |and re-opening |to 0 upon saving and ||re-opening -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 140202] [META] Issues with files in MS Office formats created by external producers (not MS Office)
https://bugs.documentfoundation.org/show_bug.cgi?id=140202 Justin L changed: What|Removed |Added Depends on||152804 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=152804 [Bug 152804] TABLES: Numbers in a cell equal to or greater than 10 are set to 0 upon saving and re-opening -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152804] TABLES: Numbers in a cell equal to or greater than 10 are set to 0 upon saving and re-opening
https://bugs.documentfoundation.org/show_bug.cgi?id=152804 Justin L changed: What|Removed |Added Blocks||140202 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=140202 [Bug 140202] [META] Issues with files in MS Office formats created by external producers (not MS Office) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153324] Wrong kerning in print preview of CJK characters
https://bugs.documentfoundation.org/show_bug.cgi?id=153324 m.a.riosv changed: What|Removed |Added CC||miguelangelrv@libreoffice.o ||rg --- Comment #1 from m.a.riosv --- Woks fine for me. Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded Please test with a clean profile, Menu/Help/Restart in Safe Mode -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 45284] formulas in writer file exported to word are sized incorrectly
https://bugs.documentfoundation.org/show_bug.cgi?id=45284 --- Comment #27 from Justin L --- I looked at the results of export to DOCX, and it does not include any sizes. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153078] Whole section of Groupedbar Compact UI disappear
https://bugs.documentfoundation.org/show_bug.cgi?id=153078 Justin L changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |xiscofa...@libreoffice.org |desktop.org | Status|NEW |ASSIGNED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval Blocks||125823 --- Comment #1 from V Stuart Foote --- But we can already directly format the "Application color" 'Document background' and 'Font color' in user profile picking something other than "Automatic" that follows the os/DE Light/Dark theme -- and saving to a user "Color scheme" in profile for reuse. Printing and Export is not otherwise affected by the visible UI document background. Why would we need to automate this further? And flat NO to it as default. Especially given the minimal theme support from System Color values vs. needs for the much broader Application Color values. If defaults don't work, users should Personalize their own Application Color scheme and save it for reuse. The LibreOffice Dark theme provides an example, but users can build their own. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=125823 [Bug 125823] [META] Personalization (LibreOffice Themes) bugs and Improvements -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 125823] [META] Personalization (LibreOffice Themes) bugs and Improvements
https://bugs.documentfoundation.org/show_bug.cgi?id=125823 V Stuart Foote changed: What|Removed |Added Depends on||153334 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153334 [Bug 153334] Support/default to a non-white background in Dark Mode -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval Blocks||125823 --- Comment #1 from V Stuart Foote --- But we can already directly format the "Application color" 'Document background' and 'Font color' in user profile picking something other than "Automatic" that follows the os/DE Light/Dark theme -- and saving to a user "Color scheme" in profile for reuse. Printing and Export is not otherwise affected by the visible UI document background. Why would we need to automate this further? And flat NO to it as default. Especially given the minimal theme support from System Color values vs. needs for the much broader Application Color values. If defaults don't work, users should Personalize their own Application Color scheme and save it for reuse. The LibreOffice Dark theme provides an example, but users can build their own. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=125823 [Bug 125823] [META] Personalization (LibreOffice Themes) bugs and Improvements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 153335] New: Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 Bug ID: 153335 Summary: Establishing a keyboard shortcut is doubly counter-intuitive Product: LibreOffice Version: 7.4.5.1 release Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: nicholasj...@mailfence.com Description: When setting up a keyboard shortcut I expect to select the action (that which the shortcut will achieve) and then assign the shortcut. It turns out (I had to ask on the forum) that what one must do is first select the keyboard shortcut - from a very long list of shortcuts - and then click . . 'modify' (that latter, I think, even if the shortcut is assigned to nothing at present). Hence 'doubly counter-intuitive'. Compare e.g. Linux Mint's way of assigning system-wide keyboard shortcuts - which I never liked, but it does not have things backwards (it solicits the action first) and it does not ask one to 'modify' something non-existent. I file this bug under 'Writer' but I think it affects all LibreOffice applications (and/but I found no way on Bugzilla of conveying that). Steps to Reproduce: 1. Realise that the 'customize' menu option is what one wants for keyboards shortcuts, and click it. 2. Select the function one wants to assign to a key. 3. Try vainly to get a key press to appear in the 'keys' field. Actual Results: Confusion. Frustration. Expected Results: Establishing a keyboard shortcut. Even Microsoft _Word_ (if I may say so) is better in this regard. Reproducible: Always User Profile Reset: Yes Additional Info: The software should solicit the function first - and do so clearly (for, I _thought_, falsely, that it _was_ doing that) - and then solicit the keyboard shortcut and then solicit confirmation via a button less confusing that one labelled 'modify'. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150534] Hiding Recently Expanded Columns Results in Significant Performance Loss
https://bugs.documentfoundation.org/show_bug.cgi?id=150534 --- Comment #14 from m.a.riosv --- Sorry they are. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153321] Notebook Bar (MUFFIN) separator color inconsistent in dark mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153321 V Stuart Foote changed: What|Removed |Added Ever confirmed|1 |0 Status|NEW |UNCONFIRMED Summary|Toolbar separator color |Notebook Bar (MUFFIN) |inconsistent in dark mode |separator color ||inconsistent in dark mode Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org --- Comment #3 from V Stuart Foote --- Those are all Notebook Bar (MUFFIN) constructs. Personally I have no issue with the brighter #FF as it offers higher contrast responding to a Windows Dark mode App theme. It also provides good contrast to the NB "Tab" rendering. The standard Toolbar fg/bg toggle is fine as it is as well. There is no requirement that the UIs match in this context as folks otherwise choose to use one of the MUFFIN .UI constructs or our Standard Toolbar/Dialog/SB. Consistency of the Light/Dark fg/bg toggle is a non-issue. IMHO => WF -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 153321] Notebook Bar (MUFFIN) separator color inconsistent in dark mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153321 V Stuart Foote changed: What|Removed |Added Ever confirmed|1 |0 Status|NEW |UNCONFIRMED Summary|Toolbar separator color |Notebook Bar (MUFFIN) |inconsistent in dark mode |separator color ||inconsistent in dark mode Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org --- Comment #3 from V Stuart Foote --- Those are all Notebook Bar (MUFFIN) constructs. Personally I have no issue with the brighter #FF as it offers higher contrast responding to a Windows Dark mode App theme. It also provides good contrast to the NB "Tab" rendering. The standard Toolbar fg/bg toggle is fine as it is as well. There is no requirement that the UIs match in this context as folks otherwise choose to use one of the MUFFIN .UI constructs or our Standard Toolbar/Dialog/SB. Consistency of the Light/Dark fg/bg toggle is a non-issue. IMHO => WF -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 153293] [META] Dark Mode bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=153293 Eyal Rozenberg changed: What|Removed |Added Depends on||153334 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153334 [Bug 153334] Support/default to a non-white background in Dark Mode -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Eyal Rozenberg changed: What|Removed |Added Blocks||153293 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153293 [Bug 153293] [META] Dark Mode bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153229] [RFE] Please provide a user preference to disable inheriting the system UI theme
https://bugs.documentfoundation.org/show_bug.cgi?id=153229 Eyal Rozenberg changed: What|Removed |Added Blocks||153293 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153293 [Bug 153293] [META] Dark Mode bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153334] New: Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Bug ID: 153334 Summary: Support/default to a non-white background in Dark Mode Product: LibreOffice Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: minor Priority: medium Component: LibreOffice Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: eyalr...@gmx.com When your desktop environment is in Dark Mode, and so is LO's UI, it is hard on the eyes to stare at a white page. And yet - that's what LO shows users. It also sort of defeats the purpose of being in dark mode if the screen is mostly not-dark. So, it should be at least an option, or perhaps the default, for the background of a page - Writer page, Draw drawing page, Calc spreadsheet - to not be white when in Dark Mode. I've stated this request with intentional vagueness, because there is more than one way of having a "non-white background". One is a reverse palette altogether: Black background, white text etc. Another is some mid-brightness color, with text still being black. We could have white text and dark-gray background, like Microsoft Word: https://office-watch.com/fredagg/uploads/2021/02/Word-365-Dark-mode-on-page-toggle-opt.gif ... or it could depend on how the GUI toolkit behaves in dark mode in other contexts. This issue has come up in context of the discussion of bug 153229. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153293] [META] Dark Mode bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=153293 Eyal Rozenberg changed: What|Removed |Added Depends on||153229 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153229 [Bug 153229] [RFE] Please provide a user preference to disable inheriting the system UI theme -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153229] [RFE] Please provide a user preference to disable inheriting the system UI theme
https://bugs.documentfoundation.org/show_bug.cgi?id=153229 --- Comment #13 from Eyal Rozenberg --- Another point which was briefly mentioned in the design meeting was that of discoverability/ease-of-access of this setting. To state it more concretely: If this option is hidden away under Tools | Options | LO General | View , new(bie) users will not find it easily. On the other hand, perhaps that's not so bad with our choice of default, which is following the system setting. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150534] Hiding Recently Expanded Columns Results in Significant Performance Loss
https://bugs.documentfoundation.org/show_bug.cgi?id=150534 --- Comment #13 from m.a.riosv --- I think last patches are not in the https://dev-builds.libreoffice.org/daily/master/current.html -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153297] A complex formula does not work in Calc 7.4.x; (MATCH function)
https://bugs.documentfoundation.org/show_bug.cgi?id=153297 --- Comment #5 from m.a.riosv --- Sample file from reporter in duplicate bug https://bugs.documentfoundation.org/show_bug.cgi?id=153297 The issue in that file is in DOWN.A1 a formula with MATCH in it. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153297] A complex formula does not work in Calc 7.4.x; (MATCH function)
https://bugs.documentfoundation.org/show_bug.cgi?id=153297 m.a.riosv changed: What|Removed |Added Summary|A complex formula does not |A complex formula does not |work in Calc 7.4.x |work in Calc 7.4.x; (MATCH ||function) Status|NEEDINFO|NEW -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153297] A complex formula does not work in Calc 7.4.x
https://bugs.documentfoundation.org/show_bug.cgi?id=153297 --- Comment #4 from m.a.riosv --- Created attachment 185075 --> https://bugs.documentfoundation.org/attachment.cgi?id=185075=edit Sample file Attached a sample reduced to the behavior of MATCH() function. What's seems the issue with the reported sample in Where seems Type=1 or dafault behaves different from in 7.3 Regression with Version: 7.4.0.3 (x86) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL from Version: 7.3.7.2 (x64) / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL There were some fixed bugs lately in relation with MATCH, but I don't find any of them in relation. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153311] ¶ copy-past/search LibreOffice
https://bugs.documentfoundation.org/show_bug.cgi?id=153311 --- Comment #5 from V Stuart Foote --- (In reply to Neolinux from comment #4) > If is possible copy ¶ and past ¶ in to search and substitution, without > expression, it could be better for the next improve for LibreOffice. > Example text for test, copy and past into search: > Word¶ > ¶ > phrase¶ > ¶ > --- substitution Word¶dog¶--- > Word¶ > dog¶ The "¶" has no meaning, it is simply screen decoration symbol for a paragraph break on the VCL canvas. It is not searchable. And as noted in duplicate bug 108256 the ICU based regex \n will search for the newline (+ entry in LO), but as replacement the \n places a paragraph object break. -- You are receiving this mail because: You are the assignee for the bug.
Re: Request for [API CHANGE] in spell checking: add new options to disable rule-based compounding
Hi Stephan, Stephan Bergmann ezt írta (időpont: 2023. febr. 2., Cs, 21:17): > On 1/6/23 17:42, Németh László wrote: > > Stephan Bergmann mailto:sberg...@redhat.com>> ezt > > írta (időpont: 2023. jan. 5., Cs, 10:32): > > Thus I would suggest to: > > > > * Revert the addition of the two new attributes, instead adding > > documentation to offapi/com/sun/star/linguistic2/XLinguProperties.idl > > that those two properties are available through the XPropertySet > > interface since LibreOffice 7.6. > > the above is done in > < > https://git.libreoffice.org/core/+/537a8de72b935a406e6154a8cc55040ed521741e%5E%21> > > "Remove redundant attributes that were added to published > XLinguProperties", while the below is still up for grab: > > > * Optionally, also mark all the other attributes of XLinguProperties > as > > deprecated, stating in the documentation that they should instead be > > accessed via the XPropertySet interface. > > Sorry for my delay. Many thanks for your help! Best regards, László
[Libreoffice-bugs] [Bug 153331] Base Database files no longer working after update
https://bugs.documentfoundation.org/show_bug.cgi?id=153331 lex...@yahoo.com changed: What|Removed |Added Ever confirmed|1 |0 Status|NEEDINFO|UNCONFIRMED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153331] Base Database files no longer working after update
https://bugs.documentfoundation.org/show_bug.cgi?id=153331 --- Comment #2 from lex...@yahoo.com --- Created attachment 185074 --> https://bugs.documentfoundation.org/attachment.cgi?id=185074=edit The file that is not working properly The issue is with the Inventory Form. Once you enter a value and try to move on to the next record or close the form and save, it gives the error message and will not save. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151274] Event "Losing focus" happens twice for Listbox and Combobox in a tablecontrol
https://bugs.documentfoundation.org/show_bug.cgi?id=151274 Gerhard Weydt changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Gerhard Weydt --- I can confirm the behaviour in Version: 7.3.3.2 (x64) / LibreOffice Community Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded and Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147250] WebDAV SSL not working with self signed CA and host cert
https://bugs.documentfoundation.org/show_bug.cgi?id=147250 Gabor Kelemen (allotropia) changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Gabor Kelemen (allotropia) --- If I understand correctly, this can be considered fixed. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 117073] [META] WebDAV bugs
https://bugs.documentfoundation.org/show_bug.cgi?id=117073 Bug 117073 depends on bug 147250, which changed state. Bug 147250 Summary: WebDAV SSL not working with self signed CA and host cert https://bugs.documentfoundation.org/show_bug.cgi?id=147250 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137434] Chart settings not diplayed correclty
https://bugs.documentfoundation.org/show_bug.cgi?id=137434 --- Comment #4 from medmedin2014 --- Still repro on : Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9740331d8bc56a9b6fbe3e4c1b26fb97f6639cc6 CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
