[Libreoffice-bugs] [Bug 148426] Inserting image via clipboard or drag and drop inserts only placeholder

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148426

Robert Großkopf  changed:

   What|Removed |Added

   Keywords||regression
 CC||rob...@familiegrosskopf.de

--- Comment #3 from Robert Großkopf  ---
Works with the same page on LO 7.2.5 and all LO versions before. See bug
147272. So a regression.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: Branch 'libreoffice-7-3' - vcl/inc vcl/qt5

[Michael Weghorn (via logerrit)]

 vcl/inc/qt5/QtTransferable.hxx |2 +-
 vcl/qt5/QtTransferable.cxx |   25 +
 2 files changed, 18 insertions(+), 9 deletions(-)

New commits:
commit b60e4b4ba11c726cbbc45f0747d8fc4d3da0ed74
Author: Michael Weghorn 
AuthorDate: Wed Apr 6 13:51:59 2022 +0200
Commit: Michael Weghorn 
CommitDate: Thu Apr 7 07:21:58 2022 +0200

tdf#147285 qt: Prefer "text/plain;charset=utf-8" over "text/plain"

If there were no data for MIME type "text/plain;charset=utf-16"
in the clipboard, but "text/plain" was provided, it was previously
assumed that this would be encoded in the locale's encoding, and
corresponding conversion using that encoding happened to provide
"text/plain;charset=utf-16" ourselves.

"text/plain;charset=utf-8" data was simply ignored, but using
it (if present) and preferring it over "text/plain"
is more reliable (and e.g. avoids incorrect paste of Chinese
characters from Firefox into Impress when using the qt5/qt6/kf5
VCL plugins on Wayland), so use it if present.

Rename the "m_bConvertFromLocale" member to better fit
the new meaning.

(An alternative solution to adding our own handling for
"text/plain;charset=utf-8" and making assumptions for the
encoding of "text/plain" data would be to let Qt handle
this and just call `QMimeData::text()` for the
`m_bProvideUTF16FromOtherEncoding=true` case
in `QtTransferable::getTransferData`.
Since qtbase commit 589a01ff6b1eacf81e74a5fc4801572135214f43
("QMimeData: Prefer UTF-8 when multiple charsets are available",
contained in Qt >= 5.13), that one handles MIME type
"text/plain;charset=utf-8" in addition to "text/plain".)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=589a01ff6b1eacf81e74a5fc4801572135214f43

Change-Id: I89f33216bf6be02a347d245b2359273af2eb530a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132631
Reviewed-by: Jan-Marek Glogowski 
Tested-by: Jenkins
(cherry picked from commit 5b3227fac58dcbd588e2389e205679cd77842bac)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132607
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/vcl/inc/qt5/QtTransferable.hxx b/vcl/inc/qt5/QtTransferable.hxx
index f2997089c037..5f1533dd5968 100644
--- a/vcl/inc/qt5/QtTransferable.hxx
+++ b/vcl/inc/qt5/QtTransferable.hxx
@@ -35,7 +35,7 @@ class QtTransferable : public 
cppu::WeakImplHelper m_aMimeTypeSeq;
 
 public:
diff --git a/vcl/qt5/QtTransferable.cxx b/vcl/qt5/QtTransferable.cxx
index a2483b4b5f3a..1ab07dbb6224 100644
--- a/vcl/qt5/QtTransferable.cxx
+++ b/vcl/qt5/QtTransferable.cxx
@@ -42,7 +42,7 @@ static bool lcl_textMimeInfo(const OUString& rMimeString, 
bool& bHaveNoCharset,
 
 QtTransferable::QtTransferable(const QMimeData* pMimeData)
 : m_pMimeData(pMimeData)
-, m_bConvertFromLocale(false)
+, m_bProvideUTF16FromOtherEncoding(false)
 {
 assert(pMimeData);
 }
@@ -62,7 +62,7 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 QStringList aFormatList(m_pMimeData->formats());
 // we might add the UTF-16 mime text variant later
 const int nMimeTypeSeqSize = aFormatList.size() + 1;
-bool bHaveNoCharset = false, bHaveUTF16 = false;
+bool bHaveNoCharset = false, bHaveUTF16 = false, bHaveUTF8 = false;
 css::uno::Sequence 
aMimeTypeSeq(nMimeTypeSeqSize);
 auto pMimeTypeSeq = aMimeTypeSeq.getArray();
 
@@ -85,6 +85,7 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 {
 bHaveNoCharset |= bIsNoCharset;
 bHaveUTF16 |= bIsUTF16;
+bHaveUTF8 |= bIsUTF8;
 if (bIsUTF16)
 aFlavor.DataType = cppu::UnoType::get();
 else
@@ -99,8 +100,8 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 nMimeTypeCount++;
 }
 
-m_bConvertFromLocale = bHaveNoCharset && !bHaveUTF16;
-if (m_bConvertFromLocale)
+m_bProvideUTF16FromOtherEncoding = (bHaveNoCharset || bHaveUTF8) && 
!bHaveUTF16;
+if (m_bProvideUTF16FromOtherEncoding)
 {
 aFlavor.MimeType = "text/plain;charset=utf-16";
 aFlavor.DataType = cppu::UnoType::get();
@@ -133,11 +134,19 @@ css::uno::Any SAL_CALL 
QtTransferable::getTransferData(const css::datatransfer::
 if (rFlavor.MimeType == "text/plain;charset=utf-16")
 {
 OUString aString;
-if (m_bConvertFromLocale)
+if (m_bProvideUTF16FromOtherEncoding)
 {
-QByteArray 
aByteData(m_pMimeData->data(QStringLiteral("text/plain")));
-aString = OUString(reinterpret_cast(aByteData.data()), aByteData.size(),
-   osl_getThreadTextEncoding());
+if (m_pMimeData->hasFormat("text/plain;charset=utf-8"))
+{
+QByteArray 
aByteData(m_pMimeData->data(QStringLiteral("text/plain;charset=utf-8")));
+aString = OUString::fromUtf8(reinterpret_cast(aByteData.data()));
+}
+ 

[Libreoffice-commits] core.git: helpcontent2

[Adolfo Jayme Barrientos (via logerrit)]

 helpcontent2 |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 6240902d996c31c1200fa523f89a419a934cde58
Author: Adolfo Jayme Barrientos 
AuthorDate: Thu Apr 7 00:21:00 2022 -0500
Commit: Gerrit Code Review 
CommitDate: Thu Apr 7 07:21:00 2022 +0200

Update git submodules

* Update helpcontent2 from branch 'master'
  to 9839c0b071de018ea00af1ae180756e9e5a52793
  - Revert "Fix typo"

Besides being a wrong fix, please refrain from changing external code 
locally.
Go to the upstream project instead, Andrea!

This reverts commit 1e37e14da918a278abe5df8a5885fa211c02ee8b.

diff --git a/helpcontent2 b/helpcontent2
index 4b68b8f837be..9839c0b071de 16
--- a/helpcontent2
+++ b/helpcontent2
@@ -1 +1 @@
-Subproject commit 4b68b8f837be5932a30a9ff3546afeeaea4f93a5
+Subproject commit 9839c0b071de018ea00af1ae180756e9e5a52793

[Libreoffice-commits] help.git: help3xsl/prism.js

[Adolfo Jayme Barrientos (via logerrit)]

 help3xsl/prism.js |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 9839c0b071de018ea00af1ae180756e9e5a52793
Author: Adolfo Jayme Barrientos 
AuthorDate: Thu Apr 7 00:20:00 2022 -0500
Commit: Adolfo Jayme Barrientos 
CommitDate: Thu Apr 7 00:20:00 2022 -0500

Revert "Fix typo"

Besides being a wrong fix, please refrain from changing external code 
locally.
Go to the upstream project instead, Andrea!

This reverts commit 1e37e14da918a278abe5df8a5885fa211c02ee8b.

diff --git a/help3xsl/prism.js b/help3xsl/prism.js
index 347f0f090..546388f44 100644
--- a/help3xsl/prism.js
+++ b/help3xsl/prism.js
@@ -292,7 +292,7 @@ var Prism = (function (_self) {
},
 
/**
-* This namespace contains all currently loaded languages and 
the same helper functions to create and modify languages.
+* This namespace contains all currently loaded languages and 
the some helper functions to create and modify languages.
 *
 * @namespace
 * @memberof Prism

[Libreoffice-bugs] [Bug 144981] Insert Hyperlink dialog with artifacts in icons on the left bar (using kf5)

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=144981

--- Comment #6 from Jan-Marek Glogowski  ---
This looks like a bug in the headless VCL plugin code. Removing the 

cairo_matrix_t aMatrix;
cairo_matrix_init_translate(, 0.5, 0.5);
cairo_set_matrix(cr, );

block from SvpGraphicsBackend::drawPolyPolygon fixes this artifact, but results
in other drawing glitches, because the sub-pixel positioning then is a bit off
(half a pixel). Or I'm missing something else or maybe it's a Cairo bug.

It doesn't show up in gtk3, which also uses Cairo / this code, because gtk3 -
via weld - uses a native widget instead of LO's widget (some GtkNotebook). The
QPainter Qt5 code is also correct.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: Branch 'libreoffice-7-3' - solenv/flatpak-manifest.in

[Stephan Bergmann (via logerrit)]

 solenv/flatpak-manifest.in |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 3270581ba9abf3b73a28475fdbb3e23534995fae
Author: Stephan Bergmann 
AuthorDate: Wed Apr 6 08:36:13 2022 +0200
Commit: Adolfo Jayme Barrientos 
CommitDate: Thu Apr 7 07:13:55 2022 +0200

Sync flatpak-manifest.in with Flathub

...including


"Merge pull request #184 from xlejo/adding-gvfsd:  Adding xdg-run/gvfsd"

Change-Id: I1b700c1e7170e67abf3fb1351be9f8c11cc15f8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132617
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit fd0aa82a61612b90352b0780e62bb4d4dd0d94f8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132603
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/solenv/flatpak-manifest.in b/solenv/flatpak-manifest.in
index a4c786063363..8733619463f1 100644
--- a/solenv/flatpak-manifest.in
+++ b/solenv/flatpak-manifest.in
@@ -723,6 +723,7 @@
 "--socket=pulseaudio",
 "--device=dri",
 "--filesystem=xdg-config/gtk-3.0",
+"--filesystem=xdg-run/gvfsd",
 "--filesystem=host",
 "--env=GIO_EXTRA_MODULES=/app/lib/gio/modules",
 "--env=JAVA_HOME=/app/jre",

[Libreoffice-bugs] [Bug 148385] Textimport doesn't work correct

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148385

--- Comment #6 from Rolf  ---
(In reply to Xisco Faulí from comment #1)
> Thank you for reporting the bug. Please attach a sample document, as this
> makes it easier for us to verify the bug. 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' once the requested document is provided.
> (Please note that the attachment will be public, remove any sensitive
> information before attaching it. 
> See
> https://wiki.documentfoundation.org/QA/
> FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help
> on how to do so.)

Thanks , i have uploaded a file and a description.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148385] Textimport doesn't work correct

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148385

--- Comment #5 from Rolf  ---
(In reply to m.a.riosv from comment #4)
> Maybe I'm wrong, but it not looks as normalized csv file format.
> https://en.wikipedia.org/wiki/Comma-separated_values

I used such a file many times befor, it works, but in the currend Office it
doesn't
work.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 147040] Impress crashes with kf5 / qt5 after editing slide text

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=147040

Michael Weghorn  changed:

   What|Removed |Added

 CC||m.wegh...@posteo.de

--- Comment #2 from Michael Weghorn  ---
Is this the same as tdf#143135, which I can reproduce on Wayland only?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 102495] [META] KDE VCL backend bugs and enhancements

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=102495
Bug 102495 depends on bug 147285, which changed state.

Bug 147285 Summary: Pasting from Firefox results in raw code (\u) instead 
of Chinese text under kf5 (cairo+wayland)
https://bugs.documentfoundation.org/show_bug.cgi?id=147285

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 100156] [META] Wayland-related bugs

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=100156
Bug 100156 depends on bug 147285, which changed state.

Bug 147285 Summary: Pasting from Firefox results in raw code (\u) instead 
of Chinese text under kf5 (cairo+wayland)
https://bugs.documentfoundation.org/show_bug.cgi?id=147285

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: vcl/inc vcl/qt5

[Michael Weghorn (via logerrit)]

 vcl/inc/qt5/QtTransferable.hxx |2 +-
 vcl/qt5/QtTransferable.cxx |   25 +
 2 files changed, 18 insertions(+), 9 deletions(-)

New commits:
commit 5b3227fac58dcbd588e2389e205679cd77842bac
Author: Michael Weghorn 
AuthorDate: Wed Apr 6 13:51:59 2022 +0200
Commit: Michael Weghorn 
CommitDate: Thu Apr 7 06:36:35 2022 +0200

tdf#147285 qt: Prefer "text/plain;charset=utf-8" over "text/plain"

If there were no data for MIME type "text/plain;charset=utf-16"
in the clipboard, but "text/plain" was provided, it was previously
assumed that this would be encoded in the locale's encoding, and
corresponding conversion using that encoding happened to provide
"text/plain;charset=utf-16" ourselves.

"text/plain;charset=utf-8" data was simply ignored, but using
it (if present) and preferring it over "text/plain"
is more reliable (and e.g. avoids incorrect paste of Chinese
characters from Firefox into Impress when using the qt5/qt6/kf5
VCL plugins on Wayland), so use it if present.

Rename the "m_bConvertFromLocale" member to better fit
the new meaning.

(An alternative solution to adding our own handling for
"text/plain;charset=utf-8" and making assumptions for the
encoding of "text/plain" data would be to let Qt handle
this and just call `QMimeData::text()` for the
`m_bProvideUTF16FromOtherEncoding=true` case
in `QtTransferable::getTransferData`.
Since qtbase commit 589a01ff6b1eacf81e74a5fc4801572135214f43
("QMimeData: Prefer UTF-8 when multiple charsets are available",
contained in Qt >= 5.13), that one handles MIME type
"text/plain;charset=utf-8" in addition to "text/plain".)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=589a01ff6b1eacf81e74a5fc4801572135214f43

Change-Id: I89f33216bf6be02a347d245b2359273af2eb530a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132631
Reviewed-by: Jan-Marek Glogowski 
Tested-by: Jenkins

diff --git a/vcl/inc/qt5/QtTransferable.hxx b/vcl/inc/qt5/QtTransferable.hxx
index f2997089c037..5f1533dd5968 100644
--- a/vcl/inc/qt5/QtTransferable.hxx
+++ b/vcl/inc/qt5/QtTransferable.hxx
@@ -35,7 +35,7 @@ class QtTransferable : public 
cppu::WeakImplHelper m_aMimeTypeSeq;
 
 public:
diff --git a/vcl/qt5/QtTransferable.cxx b/vcl/qt5/QtTransferable.cxx
index 4f42f93a238b..ed31a54d769e 100644
--- a/vcl/qt5/QtTransferable.cxx
+++ b/vcl/qt5/QtTransferable.cxx
@@ -42,7 +42,7 @@ static bool lcl_textMimeInfo(const OUString& rMimeString, 
bool& bHaveNoCharset,
 
 QtTransferable::QtTransferable(const QMimeData* pMimeData)
 : m_pMimeData(pMimeData)
-, m_bConvertFromLocale(false)
+, m_bProvideUTF16FromOtherEncoding(false)
 {
 assert(pMimeData);
 }
@@ -62,7 +62,7 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 QStringList aFormatList(m_pMimeData->formats());
 // we might add the UTF-16 mime text variant later
 const int nMimeTypeSeqSize = aFormatList.size() + 1;
-bool bHaveNoCharset = false, bHaveUTF16 = false;
+bool bHaveNoCharset = false, bHaveUTF16 = false, bHaveUTF8 = false;
 css::uno::Sequence 
aMimeTypeSeq(nMimeTypeSeqSize);
 auto pMimeTypeSeq = aMimeTypeSeq.getArray();
 
@@ -85,6 +85,7 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 {
 bHaveNoCharset |= bIsNoCharset;
 bHaveUTF16 |= bIsUTF16;
+bHaveUTF8 |= bIsUTF8;
 if (bIsUTF16)
 aFlavor.DataType = cppu::UnoType::get();
 else
@@ -99,8 +100,8 @@ css::uno::Sequence SAL_CALL 
QtTransferable::getTr
 nMimeTypeCount++;
 }
 
-m_bConvertFromLocale = bHaveNoCharset && !bHaveUTF16;
-if (m_bConvertFromLocale)
+m_bProvideUTF16FromOtherEncoding = (bHaveNoCharset || bHaveUTF8) && 
!bHaveUTF16;
+if (m_bProvideUTF16FromOtherEncoding)
 {
 aFlavor.MimeType = "text/plain;charset=utf-16";
 aFlavor.DataType = cppu::UnoType::get();
@@ -133,11 +134,19 @@ css::uno::Any SAL_CALL 
QtTransferable::getTransferData(const css::datatransfer::
 if (rFlavor.MimeType == "text/plain;charset=utf-16")
 {
 OUString aString;
-if (m_bConvertFromLocale)
+if (m_bProvideUTF16FromOtherEncoding)
 {
-QByteArray 
aByteData(m_pMimeData->data(QStringLiteral("text/plain")));
-aString = OUString(reinterpret_cast(aByteData.data()), aByteData.size(),
-   osl_getThreadTextEncoding());
+if (m_pMimeData->hasFormat("text/plain;charset=utf-8"))
+{
+QByteArray 
aByteData(m_pMimeData->data(QStringLiteral("text/plain;charset=utf-8")));
+aString = OUString::fromUtf8(reinterpret_cast(aByteData.data()));
+}
+else
+{
+QByteArray 
aByteData(m_pMimeData->data(QStringLiteral("text/plain")));
+aString = 

Re: Headless mail merge

[Michael Weghorn]

On 06/04/2022 12.47, Marco Marinello wrote:

what's the easiest way to perform a mail-merge with libreoffice by
passing arguments from an automated script? Should I use UNO?

Do you have any reference?


A rather complex example is the WollMux extension [1], in particular the 
"core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/" directory 
[2]. Class "OOoBasedMailMerge" [3] might be a good starting point.



[1] https://github.com/WollMux/WollMux

[2] 
https://github.com/WollMux/WollMux/tree/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge


[3] 
https://github.com/WollMux/WollMux/blob/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/print/OOoBasedMailMerge.java

[Libreoffice-bugs] [Bug 81952] Installing 4.3 does not remove 4.2

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=81952

Ben Affleck  changed:

   What|Removed |Added

URL||https://wordle-2.com/

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 81953] 2d chart cannot be rendered normally by the opengl

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=81953

Jimmy Dean  changed:

   What|Removed |Added

URL||https://wordleunlimited.onl
   ||ine

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 145644] FILESAVE XLSX character color in header has changed to white

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=145644

Kevin Suo  changed:

   What|Removed |Added

Summary|FILESAVE XLSX character |FILESAVE XLSX character
   |color in header has |color in header has changed
   |changed.|to white
 CC||suokunl...@126.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 76595] Microsoft Offfice

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=76595

--- Comment #28 from luna beth  ---

IJ Scan Utility is an application that allows users to scan documents, photos,
and more quickly. Users can complete from scanning to storage at once by
clicking on the corresponding icon in the IJ Scan Utility main screen.
https://istartsetup.com/ij-scan-utility/ 
https://istartsetup.com/canon-com-ijsetup/ 
https://www.ijstartcan-on.org/

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148154] Reordering Conditional Formats (Not Conditions)?

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148154

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 148325] Writer 7.3.2 will only print 1 blank page even if preview shows 3 pages

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148325

QA Administrators  changed:

   What|Removed |Added

 Status|NEEDINFO|UNCONFIRMED
 Ever confirmed|1   |0

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148325] Writer 7.3.2 will only print 1 blank page even if preview shows 3 pages

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148325

--- Comment #3 from QA Administrators  ---
[Automated Action] NeedInfo-To-Unconfirmed

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 141584] Bug at Export directly to PDF file, in the Standard bar, when using arab characters

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141584

QA Administrators  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 141584] Bug at Export directly to PDF file, in the Standard bar, when using arab characters

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141584

--- Comment #7 from QA Administrators  ---
[Automated Action] NeedInfo-To-Unconfirmed

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=140900

QA Administrators  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|NEEDINFO|UNCONFIRMED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-bugs] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=140900

QA Administrators  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 140900] [Feature Request] A setting to change the size of the font previews dropdown

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=140900

--- Comment #8 from QA Administrators  ---
[Automated Action] NeedInfo-To-Unconfirmed

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=140900

--- Comment #8 from QA Administrators  ---
[Automated Action] NeedInfo-To-Unconfirmed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-bugs] [Bug 145002] Crash when type command

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=145002

--- Comment #2 from QA Administrators  ---
Dear Giovanni Trotta,

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 144344] Incorrect result when editing cell value in Calc

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=144344

QA Administrators  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |INSUFFICIENTDATA

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 144344] Incorrect result when editing cell value in Calc

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=144344

--- Comment #3 from QA Administrators  ---
Dear d.dutoit1942,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148434] LibreOffice Calc Formatting Option for Leading Zeros in Numbers Does Not Format Correctly

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148434

--- Comment #1 from Jerry Sussman  ---
Created attachment 179365
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179365=edit
Screenshot Help - LibreOffice Calc

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148434] New: LibreOffice Calc Formatting Option for Leading Zeros in Numbers Does Not Format Correctly

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148434

Bug ID: 148434
   Summary: LibreOffice Calc Formatting Option for Leading Zeros
in Numbers Does Not Format Correctly
   Product: LibreOffice
   Version: 7.0.4.2 release
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: jsussma...@outlook.com

Description:
When I format a spreadsheet cell to set the number of leading zeros for a
number (N), the resultant format is not the number of leading zeros in the
number N. Rather, the format is the number of digits to the left of the decimal
at which a leading zero, if any, will appear. E.g., if I format the number of
leading zeros at 4, the number 01234 will be formatted as 1234. However, if I
format the number of leading zeros at 5, the number 01234will be formatted to
appear correctly as 01234. 

Global formatting of the cells of a spreadsheet containing numbers with
different numbers of digits to the left of a decimal point that are preceded by
one or more leading zeros (e.g., 01, 001, 0001, 1, etc.) now is practically
impossible.  To be accurate, the total number of digits to the left of a
decimal point within each cell now would need to be counted, and--unless all
cells contained numbers with both the same number of digits and the same number
of leading zeros--to be separately formatted to make sure that the correct
number of leading zeros are selected.  

Making matters worse, even if one painstakingly counts the numbers of digits to
the left of the decimal point and the number of leading zeros for each number,
and formats each cell accordingly, the efforts may be for naught if another
LibreOffice Calc formatting setting later is applied. Thus, e.g., in the case
of "Autoformatting" an otherwise properly formatted spreadsheet to enhance
visual appeal (e.g., different color backgrounds for every other row and
column) the number of leading zeros for every cell will be modified in accord
with the Autoformatting rather with the cell formatting set by the user.

Steps to Reproduce:
1.Open LibreOffice Calc;
2.Open Spreadsheet;
3.Enter number with one or more leading zeros in one or more cells;
4.Select one or more cell containing number with one or more leading zeros;
5.Select Format;
6.Select Numbers;
7.Select Options; and
8.Select Leading Zeros.
9.Enter number of Leading zeros. 

Actual Results:
Cells containing one or more numbers with leading zeros were not formatted to 
display the number of leading zeros selected. Instead, the cells were formatted
to display the number of digits to the left of the decimal point at which a
leading zero, if any, would appear.

Expected Results:
The number of leading zeros selected (LibreOffice
Calc>Spreadsheet>Format>Cells>Numbers>Options>Leading zeros) is the number of
leading zeros regardless of the number of digits to the left of the decimal
point that the number has.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
I have been using and enjoying LibreOffice (and its Sun Office progenitor) for
decades, in various Linux distributions. Insofar as I am aware, the "leading
zero" feature does not work as it did in previous versions of LibreOffice Calc.
Last week, I switched to the MX-21 XFCE Wildflower distro from Linux Mint
(Mate). I discovered this "bug" through happenstance while proofing a
spreadsheet containing numerous account data. See attached for "Help - About
LibreOffice."

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

Yotam Benshalom  changed:

   What|Removed |Added

 Attachment #179363|0   |1
is obsolete||

--- Comment #3 from Yotam Benshalom  ---
Created attachment 179364
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179364=edit
Input selay testcase - corrcet version

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

--- Comment #2 from Yotam Benshalom  ---
Sorry, incomplete attachment. I add the complete one here.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

Yotam Benshalom  changed:

   What|Removed |Added

   Keywords||filter:docx

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

Yotam Benshalom  changed:

   What|Removed |Added

   Keywords||text:rtl

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

--- Comment #1 from Yotam Benshalom  ---
Created attachment 179363
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179363=edit
Input delay testcase

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148433] New: Extreme keyboard input delays in paragraphs which contain both rtl and numeric characters in DOCX files

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148433

Bug ID: 148433
   Summary: Extreme keyboard input delays in paragraphs which
contain both rtl and numeric characters in DOCX files
   Product: LibreOffice
   Version: 7.3.2.2 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Writer
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: bensha...@gmail.com

Description:
There are extreme keyboard input delays (when typing characters and/or
navigating with the arrow keys) in paragraphs which contain both rtl and
numeric characters in DOCX files.

Since the arrow keys and the characters are handled in independent queues, for
some reason, this bug makes it very difficult to edit such files in
libreoffice. The characters typed are often inserted before the arrows even if
the user typed the arrow first.

Steps to Reproduce:
1.Open the attached file in writer.
2.Try to move the cursor along each of the four paragraphs using the arrow
keys.

Actual Results:
In the second paragraph (the only one containing both rtl and numeric
characters) the cursor moves extremely slowly and makes uncontrollable jumps.
In the other three paragraphs the cursor moves as expected.

Expected Results:
No input delay should occur in the second paragraph.


Reproducible: Always


User Profile Reset: No



Additional Info:
This is tested on ubuntu 22.04 with gnome 42, but I suspect that this problem
is platform-independent.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 49091] UI: Alt-Left, Alt-Right keyboard shortcuts ineffective

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=49091

--- Comment #20 from Vince  ---
As one who reported this bug a long time ago to
https://bz.apache.org/ooo/show_bug.cgi?id=113502 and later as duplicate bug
53190, I have have been resigned to live without the ability of customizing
Alt+(Right,Left) in Writer.

I finally decided to tackle this as well as another keyboard customization bug
and will be submitting a patch to gerrit soon.

The ability to interactively resize writer tables using the keyboard has been
around for a long time. This capability is described in the help:
https://help.libreoffice.org/6.2/en-US/text/swriter/guide/table_sizing.html

The way this capability has been implemented breaks the ability for users to
customize table sizing keystrokes to do other things. My patch corrects that by
giving priority to keyboard customization if it exists.

The keyboard table resizing functionality is pretty nice and I thought there
might be a case where even if a user wants to customize the table sizing
keystrokes to do other things, they still might want have access to that
functionality when needed. My patch provides for that as follows: When Caps
Lock is turned on, customized table sizing keystrokes are ignored and instead
will produce their default table sizing actions. Turning Caps Lock off restores
custom action.

Finally it should be noted even if Alt+Right or Alt+Left have NOT been
customized and you are NOT in a table, they behave like Right and Left
respectively instead of acting like dead keys. My patch does not address this
idiosyncrasy.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148432] New: Navigator never presents an RTL tree for RTL documents

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148432

Bug ID: 148432
   Summary: Navigator never presents an RTL tree for RTL documents
   Product: LibreOffice
   Version: Inherited From OOo
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Writer
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: eyalr...@gmx.com

Navigator presents the trees for various categories, e.g. Headings, fully in
LTR. This, even if the entire document is RTL: Default page style, Heading N
styles, Default Paragraph Style, the works.

For "RTL documents" (defining that as one will), either the entire tree, or at
least the subtrees of: Headings, References, Bookmarks, Tables, Indices,
Comments, Footnotes and Endnotes - should be RTL.

Note that the effect of the current state of affairs is, that if your Navigator
is not very wide, you are likely to not be able to see the numbers and the
first several words of headings, bookmarks, etc. - which is exactly the content
you _must_ see to understand what item this is.


This is somewhat similar to the issue of the Cross-Reference dialog hierarchy
of items.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 131725] RTL paragraphs aligned-left in cross-reference dialog

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=131725

Eyal Rozenberg  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=14
   ||8432

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 113438] [META] Font name combobox bugs and enhancements

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113438
Bug 113438 depends on bug 136943, which changed state.

Bug 136943 Summary: TOOLBAR: Fonts Name Combobox has wrong height
https://bugs.documentfoundation.org/show_bug.cgi?id=136943

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 136943] TOOLBAR: Fonts Name Combobox has wrong height

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=136943

medmedin2014  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #4 from medmedin2014  ---
(In reply to Dieter from comment #3)
> Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it
> back to NEW with a short reasoning, if you disagree.
> 
> *** This bug has been marked as a duplicate of bug 91130 ***

The item 91130 is just an enhancement to modify the whole list view for better
usability, but this bug is regression because the combobox is there and what
should be fixed is just its height to fit inside screen and using the scrollbar
thumb user can reach any item in the list.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-ux-advise] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

Mike Kaganski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Mike Kaganski  ---
(In reply to Eyal Rozenberg from comment #10)
> What's really bothering me is seeing non-headings in the tree for headings.
> 
> ...
> 
> I have a document with heading styles applied, but also with paragraph style
> which have an outline level. They're not section headings. I don't want to
> see them in Headings view in navigator. They have an outline level because I
> want them to participate in numbering.

The participation of outline levels in numbering means what exactly? I *guess*
you mean things like table captions or formula numbering (created using
respective numbering fields); and the intended use of that feature is exactly
per-chapter numbering - thus the outline level being a synonym of chapter is
clear, again. But indeed, one is not forced to use features only as intended -
any creative (mis)use is OK. But when one would use outline levels for that,
one could limit the outline levels in Navigator to only those levels that are
used for chapters.

Again: using features outside of their intended use (outline level of
paragraphs = (sub)chapter heading) is OK, but not a reason to introduce some
changes that make everyone's life (except yours) much harder. Most (MOST) users
would be confused (to put it politely) if your proposal is implemented.

> I understand that you're stating, or claiming, that Outline level = Heading
> level. But as long as different names are used, then they're not. These
> words are not synonyms.

They are. The "words" in any program are not "words of human language". They
are terms, and they mean specific things in the program, and that meaning
should not (and cannot) match all the breadth of meaning the human language
word bears. The LibreOffice Writer's Outline level is the same as LibreOffice
Writer's Heading level. Period.

> Outlines = Headings = Chapters
> 
> any of those two false equivalencies is annoying, but how can you seriously
> defend both of them, while keeping the triple-inconsistent names?

So - your problem in this discussion is just that you believe that you know how
we should use words, and if we are allowed or not to use some of them as
synonyms. And you know what, you may discuss that (renaming the three to a
single term), and it might even make sense - but it is not what this issue is
about.

Closing WONTFIX again (in fact, it should be INVALID, because WONTFIX means
"there's a problem, but resolving it is undesirable", while this is "I do not
want to believe that the term means what it really means"). Nothing to discuss
here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-bugs] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

Mike Kaganski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Mike Kaganski  ---
(In reply to Eyal Rozenberg from comment #10)
> What's really bothering me is seeing non-headings in the tree for headings.
> 
> ...
> 
> I have a document with heading styles applied, but also with paragraph style
> which have an outline level. They're not section headings. I don't want to
> see them in Headings view in navigator. They have an outline level because I
> want them to participate in numbering.

The participation of outline levels in numbering means what exactly? I *guess*
you mean things like table captions or formula numbering (created using
respective numbering fields); and the intended use of that feature is exactly
per-chapter numbering - thus the outline level being a synonym of chapter is
clear, again. But indeed, one is not forced to use features only as intended -
any creative (mis)use is OK. But when one would use outline levels for that,
one could limit the outline levels in Navigator to only those levels that are
used for chapters.

Again: using features outside of their intended use (outline level of
paragraphs = (sub)chapter heading) is OK, but not a reason to introduce some
changes that make everyone's life (except yours) much harder. Most (MOST) users
would be confused (to put it politely) if your proposal is implemented.

> I understand that you're stating, or claiming, that Outline level = Heading
> level. But as long as different names are used, then they're not. These
> words are not synonyms.

They are. The "words" in any program are not "words of human language". They
are terms, and they mean specific things in the program, and that meaning
should not (and cannot) match all the breadth of meaning the human language
word bears. The LibreOffice Writer's Outline level is the same as LibreOffice
Writer's Heading level. Period.

> Outlines = Headings = Chapters
> 
> any of those two false equivalencies is annoying, but how can you seriously
> defend both of them, while keeping the triple-inconsistent names?

So - your problem in this discussion is just that you believe that you know how
we should use words, and if we are allowed or not to use some of them as
synonyms. And you know what, you may discuss that (renaming the three to a
single term), and it might even make sense - but it is not what this issue is
about.

Closing WONTFIX again (in fact, it should be INVALID, because WONTFIX means
"there's a problem, but resolving it is undesirable", while this is "I do not
want to believe that the term means what it really means"). Nothing to discuss
here.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148430] Use std functions instead of our own implementation

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148430

Roman Kuznetsov <79045_79...@mail.ru> changed:

   What|Removed |Added

 CC||79045_79...@mail.ru
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Roman Kuznetsov <79045_79...@mail.ru> ---
Set to NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

--- Comment #11 from Mike Kaganski  ---
(In reply to Eyal Rozenberg from comment #10)
> (In reply to Mike Kaganski from comment #7)
> > and for now, LibreOffice only
> > uses outline level of paragraphs to e.g. create ToC.
> 
> Also for numbering. But I'll grant you it's not that much. What's really
> bothering me is seeing non-headings in the tree for headings.

No one claimed that outline level is only used for ToC, and for nothing else.
If you tried to read what I wrote, you could see that "e.g.", which implies
"for this, but not only for this", in addition to the contraposition (implied
in the whole description, but also explicit in the next sentence discussing
that LO does not use heading styles specially). Again: the sentence you
incorrectly quotes meant not "outline level is used exclusively for ToC, and
for nothing else", but "to build ToC, only outline level is used by default by
LO, and nothing else is used to build ToC by default". Sorry for having to
clarify this.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-ux-advise] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

--- Comment #11 from Mike Kaganski  ---
(In reply to Eyal Rozenberg from comment #10)
> (In reply to Mike Kaganski from comment #7)
> > and for now, LibreOffice only
> > uses outline level of paragraphs to e.g. create ToC.
> 
> Also for numbering. But I'll grant you it's not that much. What's really
> bothering me is seeing non-headings in the tree for headings.

No one claimed that outline level is only used for ToC, and for nothing else.
If you tried to read what I wrote, you could see that "e.g.", which implies
"for this, but not only for this", in addition to the contraposition (implied
in the whole description, but also explicit in the next sentence discussing
that LO does not use heading styles specially). Again: the sentence you
incorrectly quotes meant not "outline level is used exclusively for ToC, and
for nothing else", but "to build ToC, only outline level is used by default by
LO, and nothing else is used to build ToC by default". Sorry for having to
clarify this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Headless mail merge

[Andrew Pitonyak]

The first step is always do it without a script until you like the result. Then 
you try to automate it.

I did it a few times many years ago and do not remember the process.

⁣Get BlueMail for Android ​

On Apr 6, 2022, 3:37 PM, at 3:37 PM, Marco Marinello  
wrote:
>Hi Andew,
>
>
>thank you for your answer. I'll take a look at the links you pointed
>to.
>
>The idea is, starting from a template in odt/doc/docx, to "fill in the
>gaps" and save the filled document. Is there any other way rather than
>mail merge?
>
>
>All the best,
>
>Marco
>
>
>Il 06/04/22 18:19, Andrew Pitonyak ha scritto:
>>
>> I had planned on documenting how to do this some years back and
>> AndrewBase.odt, and my only notes say that I should document the new
>> e-mail merge API released in OpenOffice.org version 2.01; that was a
>> long time ago. 
>>
>> I generally do not have reason to use mailmerge, but did you want to
>> send something by email or to print? 
>>
>> Someone posted a question about using mail merge with UNO in Basic
>here: 
>>
>>
>https://ask.libreoffice.org/t/syntax-for-using-spreadsheet-as-data-source-in-emailmerge-macro/24831
>>
>> From my perspective, the fact that they used the
>> server com.sun.star.text.MailMerge is useful in that it provides a
>> pointer to the service to look at. 
>>
>> Another request for help here: 
>>
>> https://forum.openoffice.org/en/forum/viewtopic.php?f=20=59312
>>
>> No answer; sadly. 
>>
>> In AndrewMacro.odt, there is an example that merges a bunch of
>> documents from a directory into a single document and it is listed as
>> being related to "mail merge", so I assume that somebody had run a
>> mail merge and this processes created many documents. But again, I
>> have not run a mail merge in many years. 
>>
>> On Wednesday, April 06, 2022 06:47 EDT, Marco Marinello
>>  wrote:
>>  
>>> Hi all,
>>>
>>>
>>> what's the easiest way to perform a mail-merge with libreoffice by
>>> passing arguments from an automated script? Should I use UNO?
>>>
>>> Do you have any reference?
>>>
>>>
>>> Thanks in advance,
>>>
>>> Best,
>>>
>>> Marco
>>>
>>>  
>>
>>
>>  

[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - desktop/source filter/source

[Mert Tumer (via logerrit)]

 desktop/source/lib/init.cxx|9 -
 filter/source/storagefilterdetect/filterdetect.cxx |7 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

New commits:
commit 49f8a7333bddceb3b8bd18d81ff593fa39f5a437
Author: Mert Tumer 
AuthorDate: Wed Apr 6 16:59:53 2022 +0300
Commit: Andras Timar 
CommitDate: Wed Apr 6 22:20:14 2022 +0200

lok: load template documents as regular documents

otherwise lok cannot save them directly because
libreoffice will try to open a save-as dialog
For odg, change the draw8_template type draw8

Signed-off-by: Mert Tumer 
Change-Id: I34b0ed03adcac89eaa926f8ae6c57e6f622a90f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132633
Tested-by: Jenkins CollaboraOffice 
Reviewed-by: Henry Castro 

diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 5721b56573d6..f3396a3f4bc7 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -2380,7 +2380,7 @@ static LibreOfficeKitDocument* 
lo_documentLoadWithOptions(LibreOfficeKit* pThis,
  Application::SetDialogCancelMode(DialogCancelMode::LOKSilent);
 }
 
-uno::Sequence aFilterOptions(3);
+uno::Sequence aFilterOptions(4);
 aFilterOptions[0] = css::beans::PropertyValue( "FilterOptions",
0,
uno::makeAny(aOptions),
@@ -2427,6 +2427,13 @@ static LibreOfficeKitDocument* 
lo_documentLoadWithOptions(LibreOfficeKit* pThis,
 aFilterOptions[3].Value <<= nUpdateDoc;
 */
 
+// set this explicitly false to be able to load template files
+// as regular files, otherwise we cannot save them; it will try
+// to bring saveas dialog which cannot work with LOK case
+aFilterOptions[3].Name = "AsTemplate";
+aFilterOptions[3].Value <<= false;
+
+
 const int nThisDocumentId = nDocumentIdCounter++;
 SfxViewShell::SetCurrentDocId(ViewShellDocId(nThisDocumentId));
 uno::Reference xComponent = 
xComponentLoader->loadComponentFromURL(
diff --git a/filter/source/storagefilterdetect/filterdetect.cxx 
b/filter/source/storagefilterdetect/filterdetect.cxx
index 02ed875c6699..694251c389b3 100644
--- a/filter/source/storagefilterdetect/filterdetect.cxx
+++ b/filter/source/storagefilterdetect/filterdetect.cxx
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include 
+
 using namespace ::com::sun::star;
 using utl::MediaDescriptor;
 
@@ -103,6 +105,11 @@ OUString SAL_CALL 
StorageFilterDetect::detect(uno::SequencegetPropertyValue( "MediaType" ) >>= aMediaType;
 aTypeName = getInternalFromMediaType( aMediaType );
+if (comphelper::LibreOfficeKit::isActive() && aTypeName == 
"draw8_template")
+{
+// save it as draw8 instead of template format
+aTypeName = "draw8";
+}
 }
 
 catch( const lang::WrappedTargetException& aWrap )

[Libreoffice-commits] core.git: Changes to 'refs/tags/cp-6.4-60'

[Mert Tumer (via logerrit)]

Tag 'cp-6.4-60' created by Andras Timar  at 
2022-04-06 20:47 +

cp-6.4-60

Changes since cp-6.4-59-14:
---
 0 files changed
---

[Libreoffice-commits] core.git: Branch 'refs/tags/cp-6.4-60' - 0 commits -

[(via logerrit)]

Rebased ref, commits from common ancestor:

[Libreoffice-bugs] [Bug 148431] New: document recovery includes file which failed previously

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148431

Bug ID: 148431
   Summary: document recovery includes file which failed
previously
   Product: LibreOffice
   Version: 7.3.1.3 release
  Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: p...@pfortin.com

During normal operation, tried to load a file that was too big for calc.  OK,
ignore and move on.  To test for another bug, "kill"ed office. On starting
oocalc, got the Document Recovery with 10 documents.  One of those docs was the
one that failed to load days earlier. Got the "The data could not be loaded
completely because the maximum number of rows per sheet was exceeded."
This file, having failed previously and the load cancelled, should not appear
in the Document Recovery.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 113438] [META] Font name combobox bugs and enhancements

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113438
Bug 113438 depends on bug 136943, which changed state.

Bug 136943 Summary: TOOLBAR: Fonts Name Combobox has wrong height
https://bugs.documentfoundation.org/show_bug.cgi?id=136943

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 91130] Smaller default font name list

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=91130

Dieter  changed:

   What|Removed |Added

 CC||med.medin.2...@gmail.com

--- Comment #37 from Dieter  ---
*** Bug 136943 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 136943] TOOLBAR: Fonts Name Combobox has wrong height

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=136943

Dieter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dieter  ---
Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it back
to NEW with a short reasoning, if you disagree.

*** This bug has been marked as a duplicate of bug 91130 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 113438] [META] Font name combobox bugs and enhancements

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113438

Dieter  changed:

   What|Removed |Added

 Depends on||148169


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=148169
[Bug 148169] Font selection in format toolbar is very slow to respond
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148169] Font selection in format toolbar is very slow to respond

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148169

Dieter  changed:

   What|Removed |Added

 Blocks||113438
 CC||dgp-m...@gmx.de

--- Comment #1 from Dieter  ---
(In reply to robgrune from comment #0)
> Problem:
> Open LO Writer.
> On format toolbar, click the font menu box to list fonts.
> Very long delay to show list of fonts: about 15 seconds
> Cannot scroll up or down to find a font.

I can't confirm with

Version: 7.3.2.2 (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: zh-CN (de_DE); UI: en-GB
Calc: CL


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=113438
[Bug 113438] [META] Font name combobox bugs and enhancements
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148430] New: Use std functions instead of our own implementation

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148430

Bug ID: 148430
   Summary: Use std functions instead of our own implementation
   Product: LibreOffice
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Keywords: difficultyMedium, easyHack, skillCpp
  Severity: normal
  Priority: medium
 Component: LibreOffice
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: hoss...@libreoffice.org
CC: mentor...@documentfoundation.org
Blocks: 143781

Historically, some functions including various mathematical functions were not
available in the early versions of C/C++. In order to use those functions
inside LibreOffice, these functions were implemented internally.

For an example, some (inverse) trigonometric and (inverse) hyperbolic functions
like asinh() and acosh() were not available in the early versions of C++ std.

Instead of our own implementation inside LibreOffice, we now can use
std::asinh() and std::acosh() from , available since C++11:

https://en.cppreference.com/w/cpp/numeric/math/asinh

The underlying methods from  are available since C99:

https://en.cppreference.com/w/c/numeric/math/asinh

The reason provided in f70de5267d7d9b7b6946cd72fe26e91bb6ac8431 to provide an
internal implementation was that asinh() and acosh() were "part of the C99
standard, but not provided by some compilers". This was true at that time, but
is no longer the case as the methods are now well established.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=143781
[Bug 143781] [META] Development- and code-related bug reports
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 143781] [META] Development- and code-related bug reports

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=143781

Hossein  changed:

   What|Removed |Added

 Depends on||148430


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=148430
[Bug 148430] Use std functions instead of our own implementation
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: Changes to 'refs/tags/cp-21.06.26-1'

[Andras Timar (via logerrit)]

Tag 'cp-21.06.26-1' created by Andras Timar  at 
2022-04-06 20:14 +

cp-21.06.26-1

Changes since cp-21.06.25-1-3:
---
 0 files changed
---

[Libreoffice-commits] translations.git: Changes to 'refs/tags/cp-21.06.26-1'

[Andras Timar (via logerrit)]

Tag 'cp-21.06.26-1' created by Andras Timar  at 
2022-04-06 20:14 +

cp-21.06.26-1

Changes since cp-21.06.13-1-1:
---
 0 files changed
---

[Libreoffice-commits] help.git: Changes to 'refs/tags/cp-21.06.26-1'

[Adolfo Jayme Barrientos (via logerrit)]

Tag 'cp-21.06.26-1' created by Andras Timar  at 
2022-04-06 20:14 +

cp-21.06.26-1

Changes since co-2021-branch-point-10:
---
 0 files changed
---

[Libreoffice-commits] dictionaries.git: Changes to 'refs/tags/cp-21.06.26-1'

[Andras Timar (via logerrit)]

Tag 'cp-21.06.26-1' created by Andras Timar  at 
2022-04-06 20:14 +

cp-21.06.26-1

Changes since libreoffice-7-1-branch-point-5:
---
 0 files changed
---

[Libreoffice-commits] core.git: Branch 'distro/collabora/co-2021' - configure.ac

[Andras Timar (via logerrit)]

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 524dda8d3e7e2c35d15500e0da47682f2208c027
Author: Andras Timar 
AuthorDate: Wed Apr 6 22:08:40 2022 +0200
Commit: Andras Timar 
CommitDate: Wed Apr 6 22:08:40 2022 +0200

Bump version to 21.06.26.1

Change-Id: Ib342ce38a00855a057991568eea464a299789824

diff --git a/configure.ac b/configure.ac
index ed53a71a5c7c..8cefe8bd7e3a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,7 +9,7 @@ dnl in order to create a configure script.
 # several non-alphanumeric characters, those are split off and used only for 
the
 # ABOUTBOXPRODUCTVERSIONSUFFIX in openoffice.lst. Why that is necessary, no 
idea.
 
-AC_INIT([Collabora Office],[21.06.25.1],[],[],[https://collaboraoffice.com/])
+AC_INIT([Collabora Office],[21.06.26.1],[],[],[https://collaboraoffice.com/])
 
 dnl libnumbertext needs autoconf 2.68, but that can pick up autoconf268 just 
fine if it is installed
 dnl whereas aclocal (as run by autogen.sh) insists on using autoconf and fails 
hard

[Libreoffice-commits] core.git: Branch 'feature/cib_contract138c' - 15 commits - external/coinmp Makefile.in RepositoryExternal.mk solenv/gbuild xmlsecurity/CppunitTest_xmlsecurity_pdfsigning.mk xmlse

[Caolán McNamara (via logerrit)]

 Makefile.in
   |2 
 RepositoryExternal.mk  
   |   26 
 dev/null   
   |binary
 external/coinmp/UnpackedTarball_coinmp.mk  
   |2 
 external/coinmp/configure-exit.patch   
   |   33 
 external/coinmp/register.patch 
   |  369 ++
 solenv/gbuild/platform/com_GCC_defs.mk 
   |4 
 xmlsecurity/CppunitTest_xmlsecurity_pdfsigning.mk  
   |8 
 xmlsecurity/CppunitTest_xmlsecurity_signing.mk 
   |9 
 xmlsecurity/inc/biginteger.hxx 
   |   11 
 xmlsecurity/inc/xmlsec-wrapper.h   
   |4 
 xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx  
   |   37 -
 
xmlsecurity/qa/unit/signing/data/02_doc_macros_signed_by_attacker_manipulated.odt
 |binary
 xmlsecurity/qa/unit/signing/data/02_doc_signed_by_attacker_manipulated.odt 
   |binary
 xmlsecurity/qa/unit/signing/data/02_doc_signed_by_attacker_manipulated2.odt
   |binary
 
xmlsecurity/qa/unit/signing/data/02_doc_signed_by_attacker_manipulated_triple.odt
 |binary
 
xmlsecurity/qa/unit/signing/data/02_doc_signed_by_trusted_person_manipulated.odt
  |binary
 xmlsecurity/qa/unit/signing/data/cert9.db  
   |binary
 xmlsecurity/qa/unit/signing/data/key4.db   
   |binary
 xmlsecurity/qa/unit/signing/data/pkcs11.txt
   |5 
 xmlsecurity/qa/unit/signing/data/signed_with_x509certificate_chain.odt 
   |binary
 xmlsecurity/qa/unit/signing/data/test.p7b  
   |  249 ++
 xmlsecurity/qa/unit/signing/signing.cxx
   |  174 
 xmlsecurity/source/component/documentdigitalsignatures.cxx 
   |   13 
 xmlsecurity/source/helper/xmlsignaturehelper.cxx   
   |6 
 xmlsecurity/source/helper/xsecverify.cxx   
   |6 
 xmlsecurity/source/xmlsec/mscrypt/securityenvironment_mscryptimpl.cxx  
   |   63 +
 xmlsecurity/source/xmlsec/mscrypt/x509certificate_mscryptimpl.cxx  
   |   92 ++
 xmlsecurity/source/xmlsec/mscrypt/xmlsignature_mscryptimpl.cxx 
   |4 
 xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx  
   |   95 ++
 xmlsecurity/source/xmlsec/nss/xmlsignature_nssimpl.cxx 
   |4 
 31 files changed, 1180 insertions(+), 36 deletions(-)

New commits:
commit 59e239eb6210e10b75b097810c02f90ab7e0715b
Author: Caolán McNamara 
AuthorDate: Thu Mar 3 14:22:37 2022 +
Commit: Michael Stahl 
CommitDate: Wed Apr 6 20:46:38 2022 +0200

compare authors using Thumbprint

Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130929
Tested-by: Jenkins
Reviewed-by: Miklos Vajna 
(cherry picked from commit 65442205b5b274ad309308162f150f8d41648f72)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130866
Reviewed-by: Michael Stahl 
(cherry picked from commit a7aaa78acea4c1d51283c2fce54ff9f5339026f8)

Change-Id: I338f58eb07cbf0a3d13a7dafdaddac09252a8546
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131368
Tested-by: Michael Stahl 
Reviewed-by: Michael Stahl 
(cherry picked from commit 2c8c221b88f2e2bb5b29a6c1bcce1ea75e98136a)

diff --git a/xmlsecurity/source/component/documentdigitalsignatures.cxx 
b/xmlsecurity/source/component/documentdigitalsignatures.cxx
index 928b1d67aed8..385f5121d14c 100644
--- a/xmlsecurity/source/component/documentdigitalsignatures.cxx
+++ b/xmlsecurity/source/component/documentdigitalsignatures.cxx
@@ -647,8 +647,17 @@ sal_Bool DocumentDigitalSignatures::isAuthorTrusted(
 for ( ; pAuthors != pAuthorsEnd; ++pAuthors )
 {
 SvtSecurityOptions::Certificate aAuthor = *pAuthors;
-if (xmlsecurity::EqualDistinguishedNames(aAuthor[0], 
xAuthor->getIssuerName(), xmlsecurity::NOCOMPAT)
-&& (aAuthor[1] == sSerialNum))
+if (!xmlsecurity::EqualDistinguishedNames(aAuthor[0], 
xAuthor->getIssuerName(), xmlsecurity::NOCOMPAT))
+continue;
+if (aAuthor[1] != sSerialNum)
+continue;
+
+DocumentSignatureManager aSignatureManager(mxCtx, {});
+if (!aSignatureManager.init())
+return false;
+uno::Reference xCert =
+
aSignatureManager.getSecurityEnvironment()->createCertificateFromAscii(aAuthor[2]);
+if (xCert->getSHA1Thumbprint() == xAuthor->getSHA1Thumbprint())
   

[Libreoffice-bugs] [Bug 148426] Inserting image via clipboard or drag and drop inserts only placeholder

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148426

Gerhard Weydt  changed:

   What|Removed |Added

 CC||c.huege...@gmail.com

--- Comment #2 from Gerhard Weydt  ---
*** Bug 147272 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 147272] Images lost while copy paste html to Writer

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=147272

Gerhard Weydt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Gerhard Weydt  ---


*** This bug has been marked as a duplicate of bug 148426 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148412] TexMath does not install on version 7.2.6

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148412

--- Comment #1 from V Stuart Foote  ---
No issue with download or the install of the extension, doing a simple os
download from web browser from the LibreOffice Extension service:

https://extensions.libreoffice.org/?q=texmaths_doExtensionSearch=Search

The TexMaths button entries are made to the Standard toolbar, and a project
Help menu entry is added.

=> WFM


Version: 7.3.2.2 (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 147272] Images lost while copy paste html to Writer

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=147272

Robert Großkopf  changed:

   What|Removed |Added

 OS|Windows (All)   |All

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 147272] Images lost while copy paste html to Writer

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=147272

--- Comment #5 from Robert Großkopf  ---
This seems to be a special problem with content like it is designed on
https://www.ndr.de/
Other websites like https://www.wdr.de/ or wikipedia will be pasted together
with images, but content from ndr.de won't be pasted since LO 7.3.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

Eyal Rozenberg  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #10 from Eyal Rozenberg  ---
Heiko, we're in the middle of a conversation, so please don't just close this
as WONTFIX.

Anyway...

(In reply to Mike Kaganski from comment #7)
> and for now, LibreOffice only
> uses outline level of paragraphs to e.g. create ToC.

Also for numbering. But I'll grant you it's not that much. What's really
bothering me is seeing non-headings in the tree for headings.

> what is
> the intended *use case* for what you propose; what *real-life problem*
> should if solve. 

I have a document with heading styles applied, but also with paragraph style
which have an outline level. They're not section headings. I don't want to see
them in Headings view in navigator. They have an outline level because I want
them to participate in numbering.

I understand that you're stating, or claiming, that Outline level = Heading
level. But as long as different names are used, then they're not. These words
are not synonyms.

You mentioned an official LO definition - can you link to it?

I must say this reminds me of another inconsistent annoyance, which is that in
LO, Outlines = Chapters, but the project refuses to name things consistently
(bug 141452). Oh yes, I see you mentioned this too.

So, with this additional artificial synonym, we now have:

Outlines = Headings = Chapters

any of those two false equivalencies is annoying, but how can you seriously
defend both of them, while keeping the triple-inconsistent names?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-ux-advise] [Bug 141456] Separate outline browsing and heading browsing in Navigator

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=141456

Eyal Rozenberg  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #10 from Eyal Rozenberg  ---
Heiko, we're in the middle of a conversation, so please don't just close this
as WONTFIX.

Anyway...

(In reply to Mike Kaganski from comment #7)
> and for now, LibreOffice only
> uses outline level of paragraphs to e.g. create ToC.

Also for numbering. But I'll grant you it's not that much. What's really
bothering me is seeing non-headings in the tree for headings.

> what is
> the intended *use case* for what you propose; what *real-life problem*
> should if solve. 

I have a document with heading styles applied, but also with paragraph style
which have an outline level. They're not section headings. I don't want to see
them in Headings view in navigator. They have an outline level because I want
them to participate in numbering.

I understand that you're stating, or claiming, that Outline level = Heading
level. But as long as different names are used, then they're not. These words
are not synonyms.

You mentioned an official LO definition - can you link to it?

I must say this reminds me of another inconsistent annoyance, which is that in
LO, Outlines = Chapters, but the project refuses to name things consistently
(bug 141452). Oh yes, I see you mentioned this too.

So, with this additional artificial synonym, we now have:

Outlines = Headings = Chapters

any of those two false equivalencies is annoying, but how can you seriously
defend both of them, while keeping the triple-inconsistent names?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Libreoffice-bugs] [Bug 148327] table row still visible after deletion with track & changes enabled (comment 3)

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148327

Regina Henschel  changed:

   What|Removed |Added

 CC||rb.hensc...@t-online.de

--- Comment #9 from Regina Henschel  ---
The commit does not belong to this bug report but to bug 148342.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 127477] Incomplete description of date & time functions in the help information

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=127477

--- Comment #10 from Albrecht Müller  ---
I think your patch does not address the rounding issues discussed at the
beginning of this thread. The use of different rounding methods can produce
quite different results. Therefore the help information should explain how date
and time functions handle the rounding that is necessary due to the inherently
inexact representation of time values.

Note: There is a pending change of the open document specification that
addresses this problem (see https://issues.oasis-open.org/browse/OFFICE-4094).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148408] Pasting a not-so-long section of a webpage takes lots of time

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148408

--- Comment #4 from Eyal Rozenberg  ---
(In reply to Rainer Bielefeld Retired from comment #2)

I realize this might not be easy to reproduce. But like Telesto says, it's some
brittle combination of circumstances. I can't even reproduce it myself. But
there _are_ some code paths which wait, and wait, and wait.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Headless mail merge

[Marco Marinello]

Hi Andew,


thank you for your answer. I'll take a look at the links you pointed to.

The idea is, starting from a template in odt/doc/docx, to "fill in the
gaps" and save the filled document. Is there any other way rather than
mail merge?


All the best,

Marco


Il 06/04/22 18:19, Andrew Pitonyak ha scritto:
>
> I had planned on documenting how to do this some years back and
> AndrewBase.odt, and my only notes say that I should document the new
> e-mail merge API released in OpenOffice.org version 2.01; that was a
> long time ago. 
>
> I generally do not have reason to use mailmerge, but did you want to
> send something by email or to print? 
>
> Someone posted a question about using mail merge with UNO in Basic here: 
>
> https://ask.libreoffice.org/t/syntax-for-using-spreadsheet-as-data-source-in-emailmerge-macro/24831
>
> From my perspective, the fact that they used the
> server com.sun.star.text.MailMerge is useful in that it provides a
> pointer to the service to look at. 
>
> Another request for help here: 
>
> https://forum.openoffice.org/en/forum/viewtopic.php?f=20=59312
>
> No answer; sadly. 
>
> In AndrewMacro.odt, there is an example that merges a bunch of
> documents from a directory into a single document and it is listed as
> being related to "mail merge", so I assume that somebody had run a
> mail merge and this processes created many documents. But again, I
> have not run a mail merge in many years. 
>
> On Wednesday, April 06, 2022 06:47 EDT, Marco Marinello
>  wrote:
>  
>> Hi all,
>>
>>
>> what's the easiest way to perform a mail-merge with libreoffice by
>> passing arguments from an automated script? Should I use UNO?
>>
>> Do you have any reference?
>>
>>
>> Thanks in advance,
>>
>> Best,
>>
>> Marco
>>
>>  
>
>
>   

[Libreoffice-bugs] [Bug 98259] [META] Keyboard shortcuts and accelerators bugs and enhancements

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=98259
Bug 98259 depends on bug 148258, which changed state.

Bug 148258 Summary: Allow customization of Alt+ on gtk3
https://bugs.documentfoundation.org/show_bug.cgi?id=148258

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 103182] [META] GTK3-specific bugs

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=103182
Bug 103182 depends on bug 148258, which changed state.

Bug 148258 Summary: Allow customization of Alt+ on gtk3
https://bugs.documentfoundation.org/show_bug.cgi?id=148258

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 146174] ALT no longer usable for hotkeys, goes to dropdown menu now (started in 7.2.3) (gtk3 only)

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=146174

Vince  changed:

   What|Removed |Added

 CC||l...@4reher.org

--- Comment #25 from Vince  ---
*** Bug 148258 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 148403] Impossible to move square or circle shapes to free selected direction in unsaved document

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148403

--- Comment #5 from fml2  ---
Windows 10.0 Build 19043

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: sc/qa

[Xisco Fauli (via logerrit)]

 sc/qa/unit/data/xlsx/tdf121887.xlsx|binary
 sc/qa/unit/subsequent_filters_test.cxx |1 +
 2 files changed, 1 insertion(+)

New commits:
commit 55b20c8781d7718fa992769df90282563694f7fe
Author: Xisco Fauli 
AuthorDate: Wed Apr 6 17:01:50 2022 +0200
Commit: Xisco Fauli 
CommitDate: Wed Apr 6 20:58:22 2022 +0200

tdf#121887: subsequent_filters: Add unittest

Change-Id: Id3eff5a59e80483d24e4a09227161aa24c4618f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132639
Tested-by: Jenkins
Reviewed-by: Xisco Fauli 

diff --git a/sc/qa/unit/data/xlsx/tdf121887.xlsx 
b/sc/qa/unit/data/xlsx/tdf121887.xlsx
new file mode 100644
index ..57d67d5a5298
Binary files /dev/null and b/sc/qa/unit/data/xlsx/tdf121887.xlsx differ
diff --git a/sc/qa/unit/subsequent_filters_test.cxx 
b/sc/qa/unit/subsequent_filters_test.cxx
index d2cdaee3da54..3706fb00d451 100644
--- a/sc/qa/unit/subsequent_filters_test.cxx
+++ b/sc/qa/unit/subsequent_filters_test.cxx
@@ -2974,6 +2974,7 @@ void ScFiltersTest::testImportCrashes() {
 testImportCrash(u"tdf139782.", FORMAT_ODS);
 testImportCrash(u"tdf136551.", FORMAT_ODS);
 testImportCrash(u"tdf90391.", FORMAT_ODS);
+testImportCrash(u"tdf121887.", FORMAT_XLSX); // 'Maximum number of rows 
per sheet' warning
 }
 
 void ScFiltersTest::testTdf129681()

[Libreoffice-bugs] [Bug 148406] RFE - Mouse Autoscroll

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148406

V Stuart Foote  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDINFO
 Ever confirmed|0   |1
Summary|Feature Request |RFE - Mouse Autoscroll
 CC||vstuart.fo...@utsa.edu

--- Comment #1 from V Stuart Foote  ---
Something beyond the current default assignment to the Mouse - 'Middle button'?

See Tools -> Options -> View in the 'Mouse' segment.

And with a two button mouse (no third-button, or scroll wheel) you should have
an os/DE available sequence to generate the "Middle button".

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

Daniel Kamil Kozar  changed:

   What|Removed |Added

 Attachment #179360|0   |1
is obsolete||

--- Comment #6 from Daniel Kamil Kozar  ---
Created attachment 179362
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179362=edit
Using a pl-PL date with a en-GB LibreOffice on Linux

Previous video was improperly encoded.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

--- Comment #5 from Daniel Kamil Kozar  ---
Submitted a proposed fix to Gerrit :
https://gerrit.libreoffice.org/c/core/+/132532

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148410] content of formula bar placed too low (kf5)

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148410

V Stuart Foote  changed:

   What|Removed |Added

Summary|content of formula bar  |content of formula bar
   |placed too low  |placed too low (kf5)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148410] content of formula bar placed too low

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148410

V Stuart Foote  changed:

   What|Removed |Added

  Component|UI  |Calc
 CC||vstuart.fo...@utsa.edu

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

--- Comment #4 from Daniel Kamil Kozar  ---
Perhaps this happens to work when the combination is en-US / es-ES. In my
particular case, I'm running a en-GB locale and the selected date format is
(one of) pl-PL ones.

Attached, please see the explanatory videos trying to use a pl-PL date with a
en-GB LibreOffice on Linux, and the other way around on Windows 7.

Build infos :
Version: 7.3.2.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 16; OS: Linux 5.17; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
7.3.2-1
Calc: threaded

Version: 7.3.2.2 (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render:
Skia/Raster; VCL: win
Locale: pl-PL (pl_PL); UI: pl-PL
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

--- Comment #3 from Daniel Kamil Kozar  ---
Created attachment 179361
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179361=edit
Using a en-GB date with a pl-PL LibreOffice on Windows 7

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

--- Comment #2 from Daniel Kamil Kozar  ---
Created attachment 179360
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179360=edit
Using a pl-PL date with a en-GB LibreOffice on Linux

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148365] CRASH: Writer 7.4 enters infinite loop while opening DOCX file (works fine in 7.3)

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148365

Julien Nabet  changed:

   What|Removed |Added

 CC||michael.st...@allotropia.de
   ||, serval2...@yahoo.fr,
   ||vmik...@collabora.com

--- Comment #11 from Julien Nabet  ---
On pc Debian x86-64 with master sources updated today, I could reproduce this.
I got different types of logs first (let's say 20secs), eg:
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:legacy.osl:187945:187945:sw/source/core/text/frmform.cxx:1217:
SwTextFrame::FormatLine: line height is zero
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move
anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move
anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184:
SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the
textframe!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move
anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move
anchor from invalid page - fix layouting!

then the never ending loop:
warn:legacy.osl:187945:187945:sw/source/core/layout/objectformatter.cxx:326:
LoopControl in SwObjectFormatter::FormatObj_: Stage 3!!!


Michael/Miklos: I know it's no news layout mechanism is quite complex, any idea
about at least a bandaid here?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148422] Assertion failed: (rSData.empty() || rSData[0].m_bRedlineMoved || (rSData[0].m_nRedlineCount == rDoc.getIDocumentRedlineAccess().GetRedlineTable().size())), function Se

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148422

--- Comment #4 from Telesto  ---
(In reply to Julien Nabet from comment #3)
> Created attachment 179359 [details]
> bt with debug symbols
> 
> On pc Debian x86-64 with master sources updated today, I had an assertion
> applied first example but after some extra undoing.
> 
> About the second example, "Undo" button is disabled since LO considers
> there's nothing to undo. I suppose I missed something.

Apply Yellow Character Highlighting to 'grit' and 'put'. And next undo both
changes..

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148422] Assertion failed: (rSData.empty() || rSData[0].m_bRedlineMoved || (rSData[0].m_nRedlineCount == rDoc.getIDocumentRedlineAccess().GetRedlineTable().size())), function Se

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148422

Julien Nabet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 148422] Assertion failed: (rSData.empty() || rSData[0].m_bRedlineMoved || (rSData[0].m_nRedlineCount == rDoc.getIDocumentRedlineAccess().GetRedlineTable().size())), function Se

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148422

--- Comment #3 from Julien Nabet  ---
Created attachment 179359
  --> https://bugs.documentfoundation.org/attachment.cgi?id=179359=edit
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I had an assertion
applied first example but after some extra undoing.

About the second example, "Undo" button is disabled since LO considers there's
nothing to undo. I suppose I missed something.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: include/svtools sd/source sw/source

[Mike Kaganski (via logerrit)]

 include/svtools/htmlout.hxx  |6 +--
 sd/source/filter/html/htmlex.cxx |5 ---
 sw/source/filter/html/css1atr.cxx|5 +--
 sw/source/filter/html/htmlatr.cxx|   25 +---
 sw/source/filter/html/htmlbas.cxx|5 +--
 sw/source/filter/html/htmldrawwriter.cxx |3 -
 sw/source/filter/html/htmlfldw.cxx   |   18 ---
 sw/source/filter/html/htmlflywriter.cxx  |   14 +++--
 sw/source/filter/html/htmlforw.cxx   |   47 +++
 sw/source/filter/html/htmlftn.cxx|   21 ++---
 sw/source/filter/html/htmlplug.cxx   |   25 +++-
 sw/source/filter/html/htmltabw.cxx   |5 +--
 sw/source/filter/html/wrthtml.cxx|   31 +++-
 sw/source/filter/html/wrthtml.hxx|1 
 14 files changed, 84 insertions(+), 127 deletions(-)

New commits:
commit aeeacd28456c8c1f223342c45bf8c7199e3acd34
Author: Mike Kaganski 
AuthorDate: Wed Apr 6 20:11:23 2022 +0300
Commit: Mike Kaganski 
CommitDate: Wed Apr 6 20:09:22 2022 +0200

Drop write-only uses of pNonConvertableChars argument

Change-Id: Ibf60405868cfda08d125f63c45f8b74e52b32da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132642
Tested-by: Jenkins
Reviewed-by: Mike Kaganski 

diff --git a/include/svtools/htmlout.hxx b/include/svtools/htmlout.hxx
index 4207bcb4d2bc..8bd34b5f1d2a 100644
--- a/include/svtools/htmlout.hxx
+++ b/include/svtools/htmlout.hxx
@@ -44,12 +44,12 @@ struct HTMLOutEvent
 struct HTMLOutFuncs
 {
 SVT_DLLPUBLIC static OString ConvertStringToHTML( const OUString& sSrc,
-OUString *pNonConvertableChars );
+OUString *pNonConvertableChars = nullptr );
 
 SVT_DLLPUBLIC static SvStream& Out_AsciiTag( SvStream&, std::string_view 
rStr,
bool bOn = true);
 SVT_DLLPUBLIC static SvStream& Out_Char( SvStream&, sal_uInt32 cChar,
-OUString *pNonConvertableChars );
+OUString *pNonConvertableChars = nullptr );
 SVT_DLLPUBLIC static SvStream& Out_String( SvStream&, const OUString&,
 OUString *pNonConvertableChars = nullptr );
 SVT_DLLPUBLIC static SvStream& Out_Hex( SvStream&, sal_uInt32 nHex, 
sal_uInt8 nLen );
@@ -77,7 +77,7 @@ struct HTMLOutFuncs
 // by an entry that consists only of 0s
 SVT_DLLPUBLIC static SvStream& Out_Events( SvStream&, const 
SvxMacroTableDtor&,
 const HTMLOutEvent*, bool bOutStarBasic,
-OUString *pNonConvertableChars );
+OUString *pNonConvertableChars = nullptr );
 
 // 
 SVT_DLLPUBLIC static OString CreateTableDataOptionsValNum(
diff --git a/sd/source/filter/html/htmlex.cxx b/sd/source/filter/html/htmlex.cxx
index 9ceffc8a515a..e76925f82917 100644
--- a/sd/source/filter/html/htmlex.cxx
+++ b/sd/source/filter/html/htmlex.cxx
@@ -1062,11 +1062,8 @@ OUString HtmlExport::DocumentMetadata() const
 xDocProps.set(xDPS->getDocumentProperties());
 }
 
-OUString aNonConvertableCharacters;
-
 SfxFrameHTMLWriter::Out_DocInfo(aStream, maDocFileName, xDocProps,
-"  ",
-);
+"  ");
 
 const sal_uInt64 nLen = aStream.GetSize();
 OSL_ENSURE(nLen < o3tl::make_unsigned(SAL_MAX_INT32), "Stream can't fit in 
OString");
diff --git a/sw/source/filter/html/css1atr.cxx 
b/sw/source/filter/html/css1atr.cxx
index 731381f1a071..040914222d77 100644
--- a/sw/source/filter/html/css1atr.cxx
+++ b/sw/source/filter/html/css1atr.cxx
@@ -350,10 +350,9 @@ void SwHTMLWriter::OutCSS1_Property( const char *pProp,
 // for STYLE-Option encode string
 Strm().WriteOString( sOut.makeStringAndClear() );
 if( !sVal.empty() )
-HTMLOutFuncs::Out_String( Strm(), OUString::createFromAscii(sVal),
-  _aNonConvertableCharacters );
+HTMLOutFuncs::Out_String( Strm(), OUString::createFromAscii(sVal) 
);
 else if( pSVal )
-HTMLOutFuncs::Out_String( Strm(), *pSVal, 
_aNonConvertableCharacters );
+HTMLOutFuncs::Out_String( Strm(), *pSVal );
 }
 else
 {
diff --git a/sw/source/filter/html/htmlatr.cxx 
b/sw/source/filter/html/htmlatr.cxx
index 1467a92c3eb6..db17987ff468 100644
--- a/sw/source/filter/html/htmlatr.cxx
+++ b/sw/source/filter/html/htmlatr.cxx
@@ -895,8 +895,7 @@ static void OutHTML_SwFormat( Writer& rWrt, const SwFormat& 
rFormat,
 break;
 }
 }
-HTMLOutFuncs::Out_String( rWrt.Strm(), aClass,
-  _aNonConvertableCharacters );
+HTMLOutFuncs::Out_String( rWrt.Strm(), aClass );
 sOut += "\"";
 }
 rWrt.Strm().WriteOString( sOut );
@@ -2258,8 +2257,7 @@ Writer& OutHTML_SwTextNode( Writer& 

[Libreoffice-bugs] [Bug 148429] New: Link external data doesn't work anymore

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148429

Bug ID: 148429
   Summary: Link external data doesn't work anymore
   Product: LibreOffice
   Version: 7.3.2.2 release
  Hardware: x86-64 (AMD64)
OS: macOS (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: clebersa...@gmail.com

After upgrading to LibreOffice 7.3 my external data links does not update
anymore.

Some links are still updated, but some links like this one doesn't work anymore
URL: https://fundamentus.com.br/fii_resultado.php

Even if I create a new File and go to Link External Data it brings nothing for
the URL: https://fundamentus.com.br/fii_resultado.php

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: helpcontent2

[Alain Romedenne (via logerrit)]

 helpcontent2 |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 286ad6905bf5b773bf4cf7ab655e710434e6a35c
Author: Alain Romedenne 
AuthorDate: Wed Apr 6 19:00:17 2022 +0100
Commit: Gerrit Code Review 
CommitDate: Wed Apr 6 20:00:17 2022 +0200

Update git submodules

* Update helpcontent2 from branch 'master'
  to 4b68b8f837be5932a30a9ff3546afeeaea4f93a5
  - Some ScriptForge services lack a pre-requisite note 2/3:

- included pre-requisite note in SF help page
- created a Python biaised note for 'Basic' service
- will create a Basic biaised note for Basic oriented services in a 
subsequent patch

Change-Id: I0810602b527fde14e4a013857482fc892593ca7f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/132386
Tested-by: Jenkins
Reviewed-by: Alain Romedenne 

diff --git a/helpcontent2 b/helpcontent2
index a6304ba5dd0e..4b68b8f837be 16
--- a/helpcontent2
+++ b/helpcontent2
@@ -1 +1 @@
-Subproject commit a6304ba5dd0efe2d5e2a16254aa9e7d2e74f5660
+Subproject commit 4b68b8f837be5932a30a9ff3546afeeaea4f93a5

[Libreoffice-commits] help.git: source/text

[Alain Romedenne (via logerrit)]

 source/text/sbasic/shared/03/sf_basic.xhp |2 +-
 source/text/sbasic/shared/03/sf_dialog.xhp|3 +++
 source/text/sbasic/shared/03/sf_dialogcontrol.xhp |3 +++
 source/text/sbasic/shared/03/sf_l10n.xhp  |3 +++
 source/text/sbasic/shared/03/sf_menu.xhp  |3 +++
 source/text/sbasic/shared/03/sf_platform.xhp  |3 +++
 source/text/sbasic/shared/03/sf_popupmenu.xhp |3 +++
 source/text/sbasic/shared/03/sf_session.xhp   |3 +++
 source/text/sbasic/shared/03/sf_timer.xhp |3 +++
 source/text/sbasic/shared/03/sf_ui.xhp|3 +++
 10 files changed, 28 insertions(+), 1 deletion(-)

New commits:
commit 4b68b8f837be5932a30a9ff3546afeeaea4f93a5
Author: Alain Romedenne 
AuthorDate: Mon Apr 4 15:33:05 2022 +0100
Commit: Alain Romedenne 
CommitDate: Wed Apr 6 20:00:15 2022 +0200

Some ScriptForge services lack a pre-requisite note 2/3:

- included pre-requisite note in SF help page
- created a Python biaised note for 'Basic' service
- will create a Basic biaised note for Basic oriented services in a 
subsequent patch

Change-Id: I0810602b527fde14e4a013857482fc892593ca7f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/132386
Tested-by: Jenkins
Reviewed-by: Alain Romedenne 

diff --git a/source/text/sbasic/shared/03/sf_basic.xhp 
b/source/text/sbasic/shared/03/sf_basic.xhp
index a5d635202..300838e7b 100644
--- a/source/text/sbasic/shared/03/sf_basic.xhp
+++ b/source/text/sbasic/shared/03/sf_basic.xhp
@@ -31,7 +31,7 @@
   
   ScriptForge.Basic
 service is limited to Python scripts.
   Service invocation
-  Before using the 
Basic service, import the 
CreateScriptService() method from the 
scriptforge module:
+  Before using the Basic 
service, import the CreateScriptService() method from the 
scriptforge module:
   
 from 
scriptforge import CreateScriptService
 bas = 
CreateScriptService("Basic")
diff --git a/source/text/sbasic/shared/03/sf_dialog.xhp 
b/source/text/sbasic/shared/03/sf_dialog.xhp
index cc87748b0..8499434e7 100644
--- a/source/text/sbasic/shared/03/sf_dialog.xhp
+++ b/source/text/sbasic/shared/03/sf_dialog.xhp
@@ -31,6 +31,9 @@
   The 
SFDialogs.Dialog service is closely related to the 
SFDialogs.DialogControl service.
 
Service invocation and 
usage
+   Before using the 
Dialog service the ScriptForge library 
needs to be loaded or imported:
+   
+
The 
Dialog service is invoked through the 
CreateScriptService method. It requires three positional 
arguments to specify the dialog box to activate:
Container: "GlobalScope" for preinstalled libraries or 
a window name as defined by ScriptForge.UI service. Empty 
string "" default value stands for the current document.
Library: The case-sensitive name of a 
library contained in the container. Default value is "Standard".
diff --git a/source/text/sbasic/shared/03/sf_dialogcontrol.xhp 
b/source/text/sbasic/shared/03/sf_dialogcontrol.xhp
index eb97854d3..9f92015a7 100644
--- a/source/text/sbasic/shared/03/sf_dialogcontrol.xhp
+++ b/source/text/sbasic/shared/03/sf_dialogcontrol.xhp
@@ -31,6 +31,9 @@
 
   The 
SFDialogs.DialogControl service is closely related to the 
SFDialogs.Dialog service.
Service invocation
+   Before using the 
DialogControl service the ScriptForge 
library needs to be loaded or imported:
+   
+
The 
DialogControl service is invoked from an existing 
Dialog service instance through its 
Controls() method. The dialog must be initiated with the 
SFDialogs.Dialog service.

   Dim myDialog As Object, myControl As 
Object
diff --git a/source/text/sbasic/shared/03/sf_l10n.xhp 
b/source/text/sbasic/shared/03/sf_l10n.xhp
index 2a3dc712d..453fe345a 100644
--- a/source/text/sbasic/shared/03/sf_l10n.xhp
+++ b/source/text/sbasic/shared/03/sf_l10n.xhp
@@ -57,6 +57,9 @@
 Note that the first two methods are used 
to build a set of translatable strings and export them to a POT file. However, 
it is not mandatory to create POT files using these methods. Since they are 
text files, the programmer could have created them using any text editor.
 
 Service invocation
+Before using the 
L10N service the ScriptForge library 
needs to be loaded or imported:
+
+
 There are several 
ways to invoke the L10N service using up to five optional 
arguments that specify the folder where PO files are stored, the locale and 
encoding to be used, as well as a fallback PO file and its encoding.
 
 
diff --git a/source/text/sbasic/shared/03/sf_menu.xhp 
b/source/text/sbasic/shared/03/sf_menu.xhp
index 1798215ef..56ef1531d 100644
--- a/source/text/sbasic/shared/03/sf_menu.xhp
+++ b/source/text/sbasic/shared/03/sf_menu.xhp
@@ -36,6 +36,9 @@
   When OLE objects such as Math formulas 
or Calc charts are edited from within a document, %PRODUCTNAME reconfigures the 
menubar according to the object. When this happens, the menus created with the 
Menu service are removed and are 

[Libreoffice-bugs] [Bug 148383] UI: Fill Series dialog does not respect the number format of the source cell

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148383

m.a.riosv  changed:

   What|Removed |Added

 CC||miguelangelrv@libreoffice.o
   ||rg

--- Comment #1 from m.a.riosv  ---
Works for me:
Version: 7.2.7.0.0+ (x64) / LibreOffice Community
Build ID: 848ba18f3196a2fc64d08573eb9d1aeda074e758
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL
Version: 7.3.3.0.0+ (x64) / LibreOffice Community
Build ID: a45cfefc284b2e468ca2847e47102964c67d12c4
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-commits] core.git: sw/qa sw/source

[Michael Stahl (via logerrit)]

 sw/qa/extras/uiwriter/data/variable-field-table-row-split-header.fodt |  270 
++
 sw/qa/extras/uiwriter/uiwriter3.cxx   |   73 ++
 sw/source/core/doc/DocumentFieldsManager.cxx  |   25 
 sw/source/core/doc/docfld.cxx |   45 +
 sw/source/core/docnode/node2lay.cxx   |   77 ++
 sw/source/core/fields/expfld.cxx  |3 
 sw/source/core/inc/docfld.hxx |   11 
 sw/source/core/inc/node2lay.hxx   |6 
 8 files changed, 477 insertions(+), 33 deletions(-)

New commits:
commit 9dc6e2c9062725ef1f9d7e321cae5f4dbe8ca749
Author: Michael Stahl 
AuthorDate: Tue Apr 5 18:27:35 2022 +0200
Commit: Michael Stahl 
CommitDate: Wed Apr 6 19:51:19 2022 +0200

sw: fix expansion of SetGetExpField in headers with split table rows

The problem is that a get field in a header on page N may calculate and
show values that do not take into account a set field on page N-1.

This happens if a table row with multiple columns is split across the
pages: SwGetExpField::ChangeExpansion() calls GetBodyTextNode(), which
returns the first node in the first column that is on page N, but in the
SwNodes array this node is *before* any node in columns 2..M, any of
which may be on page N-1 in the layout.

So try to fix this by adding a page number to SetGetExpField and using
that as the highest priority in operator<().

This is a bit risky because some of the places that create
SetGetExpField don't have a frame to get the page number from; try to
adapt all that call into MakeFieldList(), while leaving unrelated ones
such as in MakeSetList() unchanged.

Change-Id: Ied2a897ad34f0faf1ef3d50baad07b23fafd49bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132641
Tested-by: Jenkins
Reviewed-by: Michael Stahl 

diff --git 
a/sw/qa/extras/uiwriter/data/variable-field-table-row-split-header.fodt 
b/sw/qa/extras/uiwriter/data/variable-field-table-row-split-header.fodt
new file mode 100644
index ..9d3668b6b2ee
--- /dev/null
+++ b/sw/qa/extras/uiwriter/data/variable-field-table-row-split-header.fodt
@@ -0,0 +1,270 @@
+
+http://openoffice.org/2009/office; 
xmlns:css3t="http://www.w3.org/TR/css3-text/; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:ooow="http://openoffice.org/2004/writer; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns
 :config:1.0" xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:ooo="http://openoffice.org/2004/office; 
xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="ur
 n:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:xforms="http://www.w3.org/2002/xforms; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ 
2022-04-06T17:07:05.9473620632022-04-06T17:17:45.832216066PT10M42S2LibreOfficeDev/7.4.0.0.alpha0$Linux_X86_64
 
LibreOffice_project/a5b31508f860f07ec86cda3cf992fcea2bee68ef
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+   
+   
+
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+  
+   
+  
+  
+   
+
+ 
+ 
+
+   
+  
+  
+   
+
+ 
+ 
+
+   
+  
+  
+   
+
+ 
+ 
+
+   
+  
+  
+   
+
+ 
+
+  

[Libreoffice-bugs] [Bug 148385] Textimport doesn't work correct

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=148385

m.a.riosv  changed:

   What|Removed |Added

 CC||miguelangelrv@libreoffice.o
   ||rg

--- Comment #4 from m.a.riosv  ---
Maybe I'm wrong, but it not looks as normalized csv file format.
https://en.wikipedia.org/wiki/Comma-separated_values

-- 
You are receiving this mail because:
You are the assignee for the bug.