[Bug 160280] Check-boxes will not be printed

[bugzilla-daemon]

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

raal  changed:

   What|Removed |Added

 CC||r...@post.cz

--- Comment #3 from raal  ---
I cannot confirm with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice
Community
Build ID: 2887ffbf240aa70330cb50bf810170cf9c896405
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded Jumbo

I can see checkboxes, but these checkboxes are not checked [X] in Evince.
Everything is correct in Firefox.

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

[Bug 124647] CRASH: after undoing deletion ( steps in comment 5 )

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

Crash report or|["SwHistoryBookmark::SetInD |["SwHistoryBookmark::SetInD
crash signature|oc(SwDoc *,bool)"]  |oc(SwDoc
   ||*,bool)","SwHistoryBookmark
   ||::SetInDoc(SwDoc*,
   ||bool)","SwHistoryBookmark::
   ||SetInDoc","SwNodeIndex::ope
   ||rator=(SwNode const
   ||&)","swlo.dll","libstdc++.s
   ||o.6"]
   Severity|normal  |critical
 CC||stephane.guillou@libreoffic
   ||e.org

--- Comment #11 from Stéphane Guillou (stragu) 
 ---
Reproduced as in comment 5 on Linux with LO 6.3, with signature
"SwHistoryBookmark::SetInDoc":
https://crashreport.libreoffice.org/stats/crash_details/df8f5281-b799-46bb-8a3e-84cecfa89408

Version: 6.3.0.4
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: CL

That signature was last seen in 7.1.7.2.

In 7.2, same steps lead to "SwHistoryBookmark::SetInDoc(SwDoc*, bool)"
signature.
https://crashreport.libreoffice.org/stats/crash_details/7dfde548-8b20-42dd-ab71-7b0f6eaca9fb

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL

That signature was last seen in 7.6.5.2.

With 7.6.5.2 and 24.2.1.1, I get "libstdc++.so.6":
https://crashreport.libreoffice.org/stats/crash_details/1010a85d-102f-43b8-b788-4687a8675154

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

If Ubuntu catches it, it reports "soffice.bin crashed with SIGSEGV in
SwContentIndex::ChgValue()".

24.2 Backtrace from Apport:

#0  0x7ae678282940 in SwContentIndex::ChgValue(SwContentIndex const&, int)
() at /opt/libreoffice24.2/program/../program/libswlo.so
#1  0x7ae6782ce19f in SwPosition::SwPosition(SwNode const&,
o3tl::strong_int) ()
at /opt/libreoffice24.2/program/../program/libswlo.so
#2  0x7ae6782cff9f in SwPaM::SwPaM(SwNode const&, int, SwPaM*) ()
at /opt/libreoffice24.2/program/../program/libswlo.so
#3  0x7ae6786b723b in  ()
at /opt/libreoffice24.2/program/../program/libswlo.so
#4  0x7ae678779850 in  ()
at /opt/libreoffice24.2/program/../program/libswlo.so
#5  0x7ae6bbf08b68 in  () at /opt/libreoffice24.2/program/libmergedlo.so
#6  0x7ae6bf12a20b in  () at /opt/libreoffice24.2/program/libuno_sal.so.3
#7  0x7ae6ba094ac3 in start_thread (arg=)
at ./nptl/pthread_create.c:442
#8  0x7ae6ba126850 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Still crashing in recent trunk build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

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

[Bug 160265] Undo of deleting conditional formatting with formula effecting multiple sheets deleted some data.

[bugzilla-daemon]

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

Alex K  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #3 from Alex K  ---
Thank you for all your help and diligence
Alex

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

[Bug 151238] Windows 11 Scroll bar arrows hidden when set visible

[bugzilla-daemon]

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

--- Comment #10 from Mike Kaganski  ---
(In reply to V Stuart Foote from comment #9)
> Would add that the Win11 WDM handles scrollbars oddly.

Note that there are *some* Windows apps that behave *properly* with regards to
"Always show scroll bars" setting (outside of contrast themes). E.g.: the
"Settings" app itself; and notepad.exe. So, our implementation of scrollbars
behavior wrt that setting must follow these apps' behavior.

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

[Bug 160098] Writer, incorrect jump to the File menu.

[bugzilla-daemon]

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

--- Comment #1 from Naresh  ---
Harald Berger,

Alt+D highlights the address bar in your web. Can you try Ctrl+S to save?

Thanks,

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

[Bug 147148] Paste in Writer loses Source Format

[bugzilla-daemon]

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

--- Comment #5 from measrasy  ---
Look at the path - it's on the user's disk
file:///C:/Users/korisnik/AppData/Local/Temp/Temp1_Moj+sretni+broj+1-1.zip/Moj%20sretni%20broj%201/zamjena_mjesta_pribrojnika.ppsx
https://bugs.documentfoundation.org/show_bug.cgi?id=147148#add_comment
https://geometrydashsubzero.net

As you can see even in temp and zip :) The path you can see also in the
hzperlink dialog (ctrl+k)

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

Re: VS 2022 version 17.9.1 has a bug preventing building cli_ure

[Mike Kaganski]

On 24.02.2024 21:50, Mike Kaganski wrote:
After upgrading my VS v.17.9.0 to v.17.9.1, building cli_ure started to 
fail like this:


LINK : error LNK2034: metadata inconsistent with COFF symbol table: 
symbol 
'?rtl_ustr_asciil_reverseEquals_WithLength@@$$J0YAEPEB_SPEBDJ@Z' 
(06000579) has inconsistent metadata with (0A000A1A) in climaker_emit.o
climaker_emit.o : error LNK2020: unresolved token (0A000A1A) "extern 
"C" unsigned char __cdecl 
rtl_ustr_asciil_reverseEquals_WithLength(char16_t const *,char const 
*,long)" (?rtl_ustr_asciil_reverseEquals_WithLength@@$$J0YAEPEB_SPEBDJ@Z)
C:\lo\build\instdir\sdk\bin\climaker.exe : fatal error LNK1120: 1 
unresolved externals


I have filed a bug to Microsoft:

https://developercommunity.visualstudio.com/t/LINK-:-error-LNK2034:-metadata-inconsis/10599604?port=1025=fdff4046-995a-4c06-8c64-1c14b9752c8f


This problem is fixed in VS 2022 version 17.9.4:
https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes#17.9.4

--
Best regards,
Mike Kaganski

[Bug 108057] Primary key should default to AutoValue=Yes when type is integer

[bugzilla-daemon]

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

Commit Notification  changed:

   What|Removed |Added

 Whiteboard||target:24.8.0

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

core.git: dbaccess/source

[Mike Kaganski (via logerrit)]

 dbaccess/source/ui/misc/UITools.cxx|   45 +
 dbaccess/source/ui/misc/WCopyTable.cxx |1 
 dbaccess/source/ui/tabledesign/TableController.cxx |4 -
 3 files changed, 31 insertions(+), 19 deletions(-)

New commits:
commit c07548447a564b2d142cc439a124b76e6a71dfbd
Author: Mike Kaganski 
AuthorDate: Tue Mar 19 16:48:19 2024 +0500
Commit: Mike Kaganski 
CommitDate: Wed Mar 20 05:45:24 2024 +0100

Related: tdf#108057 Use autoincrement for automatically added primary key

This partially undoes commit 24940e2c3717ad7b07d43db4f08cf7e09cfcc22f
(#100599# #95927# check if row is readonly and disable autoincrement
column for auto primarykey, 2002-06-27), enabling autoincrement again.

Make sure to use the largest type that supports autoincrement.

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

diff --git a/dbaccess/source/ui/misc/UITools.cxx 
b/dbaccess/source/ui/misc/UITools.cxx
index 55e7f709f7b2..088f91cb2ba5 100644
--- a/dbaccess/source/ui/misc/UITools.cxx
+++ b/dbaccess/source/ui/misc/UITools.cxx
@@ -1052,29 +1052,40 @@ void setEvalDateFormatForFormatter(Reference< 
css::util::XNumberFormatter > cons
 }
 }
 
+static bool TypeIsGreater(const TOTypeInfoSP& lhs, const TOTypeInfoSP& rhs)
+{
+assert(lhs);
+if (!rhs)
+return true;
+if (lhs->nNumPrecRadix == rhs->nNumPrecRadix)
+return lhs->nPrecision > rhs->nPrecision;
+if (lhs->nPrecision == rhs->nPrecision)
+return lhs->nNumPrecRadix > rhs->nNumPrecRadix;
+if ((lhs->nNumPrecRadix > rhs->nNumPrecRadix) == (lhs->nPrecision > 
rhs->nPrecision))
+return lhs->nPrecision > rhs->nPrecision;
+return std::pow(lhs->nNumPrecRadix, lhs->nPrecision)
+   > std::pow(rhs->nNumPrecRadix, rhs->nPrecision);
+}
+
 TOTypeInfoSP queryPrimaryKeyType(const OTypeInfoMap& _rTypeInfo)
 {
-TOTypeInfoSP pTypeInfo;
-// first we search for a type which supports autoIncrement
+TOTypeInfoSP pTypeInfo, pFallback;
+// first we search for a largest type which supports autoIncrement
 for (auto const& elem : _rTypeInfo)
 {
-// OJ: we don't want to set an autoincrement column to be key
-// because we don't have the possibility to know how to create
-// such auto increment column later on
-// so until we know how to do it, we create a column without 
autoincrement
-// therefore we have searched
-if ( elem.second->nType == DataType::INTEGER )
-{
-pTypeInfo = elem.second; // alternative
-break;
-}
-else if ( !pTypeInfo && elem.second->nType == DataType::DOUBLE )
-pTypeInfo = elem.second; // alternative
-else if ( !pTypeInfo && elem.second->nType == DataType::REAL )
-pTypeInfo = elem.second; // alternative
+if (elem.second->bAutoIncrement && TypeIsGreater(elem.second, 
pTypeInfo))
+pTypeInfo = elem.second;
+if (pTypeInfo)
+continue;
+if (elem.second->nType == DataType::INTEGER)
+pFallback = elem.second; // default alternative
+else if (!pFallback && elem.second->nType == DataType::DOUBLE)
+pFallback = elem.second; // alternative
+else if (!pFallback && elem.second->nType == DataType::REAL)
+pFallback = elem.second; // alternative
 }
 if ( !pTypeInfo ) // just a fallback
-pTypeInfo = queryTypeInfoByType(DataType::VARCHAR,_rTypeInfo);
+pTypeInfo = pFallback ? pFallback : 
queryTypeInfoByType(DataType::VARCHAR, _rTypeInfo);
 
 OSL_ENSURE(pTypeInfo,"checkColumns: can't find a type which is usable as a 
key!");
 return pTypeInfo;
diff --git a/dbaccess/source/ui/misc/WCopyTable.cxx 
b/dbaccess/source/ui/misc/WCopyTable.cxx
index 29be8774747b..a2737543c705 100644
--- a/dbaccess/source/ui/misc/WCopyTable.cxx
+++ b/dbaccess/source/ui/misc/WCopyTable.cxx
@@ -737,6 +737,7 @@ bool OCopyTableWizard::CheckColumns(sal_Int32& _rnBreakPos)
 OFieldDescription* pField = new OFieldDescription();
 pField->SetName(m_aKeyName);
 pField->FillFromTypeInfo(pTypeInfo,true,true);
+pField->SetAutoIncrement(pTypeInfo->bAutoIncrement);
 pField->SetPrimaryKey(true);
 m_bAddPKFirstTime = false;
 insertColumn(0,pField);
diff --git a/dbaccess/source/ui/tabledesign/TableController.cxx 
b/dbaccess/source/ui/tabledesign/TableController.cxx
index 7e13ba566bb2..fd53297cad00 100644
--- a/dbaccess/source/ui/tabledesign/TableController.cxx
+++ b/dbaccess/source/ui/tabledesign/TableController.cxx
@@ -903,15 +903,15 @@ bool OTableController::checkColumns(bool _bNew)
 {
 case RET_YES:
 {
-auto pNewRow = 

core.git: Branch 'distro/vector/vector-7.5.9' - embeddedobj/source

[Mike Kaganski (via logerrit)]

 embeddedobj/source/msole/oleembed.cxx |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

New commits:
commit d9051a918853b56305d2f894f2858b8246f4726b
Author: Mike Kaganski 
AuthorDate: Tue Mar 19 12:14:34 2024 +0500
Commit: Mike Kaganski 
CommitDate: Wed Mar 20 09:18:39 2024 +0500

Pass m_pOleComponent to lambda by copy

Both m_pOleComponent and the copy are rtl::Reference, so the copy
will ensure the lifetime of the object.
See 
https://gerrit.libreoffice.org/c/core/+/164986/2#message-5dd187741df3242f47d1037a1f9c9b0fd9bb1f8e

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

diff --git a/embeddedobj/source/msole/oleembed.cxx 
b/embeddedobj/source/msole/oleembed.cxx
index b946fed792c8..657d27710ca3 100644
--- a/embeddedobj/source/msole/oleembed.cxx
+++ b/embeddedobj/source/msole/oleembed.cxx
@@ -620,8 +620,10 @@ uno::Sequence< sal_Int32 > SAL_CALL 
OleEmbeddedObject::getReachableStates()
 
 // the list of states can only be guessed based on standard verbs,
 // since there is no way to detect what additional verbs do
+// Pass m_pOleComponent to the lambda by copy, to make sure it doesn't 
depend on possible
+// destruction of 'this', while the lock is unset
 return GetReachableStatesList_Impl(
-ExecUnlocked([this] { return m_pOleComponent->GetVerbList(); }, 
aGuard));
+ExecUnlocked([p = m_pOleComponent] { return p->GetVerbList(); }, 
aGuard));
 }
 else
 #endif

[Bug 160284] Big UI bug after update

[bugzilla-daemon]

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

--- Comment #2 from peterpr...@outlook.com ---
Created attachment 193209
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193209=edit
Normal desing

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

[Bug 160284] Big UI bug after update

[bugzilla-daemon]

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

--- Comment #1 from peterpr...@outlook.com ---
Created attachment 193208
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193208=edit
Image of the UI bug

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

[Bug 160284] New: Big UI bug after update

[bugzilla-daemon]

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

Bug ID: 160284
   Summary: Big UI bug after update
   Product: LibreOffice
   Version: 24.2.1.2 release
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: UI
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: peterpr...@outlook.com

Description:
After I updated to 24.2.1.2, I have an issue with the size of the buttons in
the UI. I use the system zoom at 125% but the look is too big for that setting.
It happens in Wayland and X11.
When I set the system zoom to 100%, it get solved but the other apps become too
little. My screen is a 1080p 15.6" screen.

Steps to Reproduce:
1.Set the system zoom to 125% and reboot the application
2.
3.

Actual Results:
The UI become too big

Expected Results:
Have the normal appearance


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: kf6 (cairo+wayland)
Locale: es-ES (es_ES.UTF-8); UI: es-ES
24.2.1-4
Calc: threaded

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

[Bug 104790] [META] Database connectivity interfaces (ODBC, JDBC..) and external databases

[bugzilla-daemon]

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

Bug 103068 Summary: New Database Wizard gets confused between ODBC and JDBC 
connection if you backup twice to step 1.
https://bugs.documentfoundation.org/show_bug.cgi?id=103068

   What|Removed |Added

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

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

core.git: dbaccess/source

[Mike Kaganski (via logerrit)]

 dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx |6 +++-
 dbaccess/source/ui/dlg/dbwizsetup.cxx |3 ++
 dbaccess/source/ui/dlg/generalpage.cxx|   32 ++
 3 files changed, 23 insertions(+), 18 deletions(-)

New commits:
commit 1e66905c840dbee0a67e444fca80bdacfcb6e6b2
Author: Mike Kaganski 
AuthorDate: Tue Mar 19 11:47:14 2024 +0500
Commit: Mike Kaganski 
CommitDate: Wed Mar 20 04:42:04 2024 +0100

tdf#103068: make sure to update and use current MySQL connection type

1. Don't set selection in OGeneralPageWizard::getEmbeddedDBName. The
method should only provide a name of an embedded database - either in
the passed set, or the default one; the activation of controls and
related actions will be done in the calling implInitControls. This
makes sure, that ODbTypeWizDialogSetup::m_sURL doesn't get rewritten
unnecessarily, keeping the current preference intact.

2. In ODbTypeWizDialogSetup::activateDatabasePath, do not use the
hardcoded MySQL URL from the control, if the current value of m_sURL
is already a MySQL one. This allows to keep the selected kind intact.

3. In OMySQLIntroPageSetup::implInitControls, do not assume that the
existing selection means that there's nothing to do. The page keeps
the selection, even when the wizard's active path was changed; and
so, the wizard's idea which page to show next may differ from the
selection. Just make sure to update the setup mode.

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

diff --git a/dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx 
b/dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx
index 22cdefdd6c31..ad81680ba421 100644
--- a/dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx
+++ b/dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx
@@ -239,9 +239,13 @@ using namespace ::com::sun::star;
 if ( bHasMySQLNative )
 m_xNATIVEDatabase->show();
 
-// if any of the options is checked, then there's nothing to do
+// tdf#103068: if any of the options is checked, then just update the 
selected kind:
+// it could happen that the selection and the wizard path are not in 
sync
 if ( m_xODBCDatabase->get_active() || m_xJDBCDatabase->get_active() || 
m_xNATIVEDatabase->get_active() )
+{
+maClickHdl.Call(this);
 return;
+}
 
 // prefer "native" or "JDBC"
 if ( bHasMySQLNative )
diff --git a/dbaccess/source/ui/dlg/dbwizsetup.cxx 
b/dbaccess/source/ui/dlg/dbwizsetup.cxx
index 720892e2a015..2fb260e18e75 100644
--- a/dbaccess/source/ui/dlg/dbwizsetup.cxx
+++ b/dbaccess/source/ui/dlg/dbwizsetup.cxx
@@ -312,6 +312,9 @@ void ODbTypeWizDialogSetup::activateDatabasePath()
 {
 OUString sOld = m_sURL;
 m_sURL = m_pGeneralPage->GetSelectedType();
+if (m_sURL.startsWith("sdbc:mysql:") && sOld.startsWith("sdbc:mysql:"))
+m_sURL = sOld; // The type of MySQL connection was already set 
elsewhere; just use it,
+   // instead of the hardcoded one from the selector
 DataSourceInfoConverter::convert(getORB(), 
m_pCollection,sOld,m_sURL,m_pImpl->getCurrentDataSource());
 ::dbaccess::DATASOURCE_TYPE eType = 
VerifyDataSourceType(m_pCollection->determineType(m_sURL));
 if (eType ==  ::dbaccess::DST_UNKNOWN)
diff --git a/dbaccess/source/ui/dlg/generalpage.cxx 
b/dbaccess/source/ui/dlg/generalpage.cxx
index a2a48158c56d..bb308845528e 100644
--- a/dbaccess/source/ui/dlg/generalpage.cxx
+++ b/dbaccess/source/ui/dlg/generalpage.cxx
@@ -226,31 +226,29 @@ namespace dbaui
 
 OUString OGeneralPageWizard::getEmbeddedDBName( const SfxItemSet& _rSet )
 {
+if (!m_pCollection)
+return {};
 // first check whether or not the selection is invalid or readonly 
(invalid implies readonly, but not vice versa)
 bool bValid, bReadonly;
 getFlags( _rSet, bValid, bReadonly );
-
-// if the selection is invalid, disable everything
-
-implSetCurrentType(  OUString() );
+if (!bValid)
+return {};
 
 // compare the DSN prefix with the registered ones
-OUString sDisplayName;
-
-if (m_pCollection && bValid)
-{
-implSetCurrentType( 
dbaccess::ODsnTypeCollection::getEmbeddedDatabase() );
-sDisplayName = m_pCollection->getTypeDisplayName( 
m_eCurrentSelection );
-onTypeSelected(m_eCurrentSelection);
-}
-
-// select the correct datasource type
-if  (  dbaccess::ODsnTypeCollection::isEmbeddedDatabase( 
m_eCurrentSelection )
-&& m_xEmbeddedDBType->find_text(sDisplayName) == -1 )
+OUString sDBURL;
+if (const SfxStringItem* pUrlItem = 
_rSet.GetItem(DSID_CONNECTURL))
+  

[Bug 113375] [META] Database wizard bugs and enhancements

[bugzilla-daemon]

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

Bug 103068 Summary: New Database Wizard gets confused between ODBC and JDBC 
connection if you backup twice to step 1.
https://bugs.documentfoundation.org/show_bug.cgi?id=103068

   What|Removed |Added

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

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

core.git: embeddedobj/source

[Mike Kaganski (via logerrit)]

 embeddedobj/source/msole/oleembed.cxx |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

New commits:
commit ec0e9bee23b5950c02abcbe27564b8188f9f789e
Author: Mike Kaganski 
AuthorDate: Tue Mar 19 12:14:34 2024 +0500
Commit: Mike Kaganski 
CommitDate: Wed Mar 20 04:41:36 2024 +0100

Pass m_pOleComponent to lambda by copy

Both m_pOleComponent and the copy are rtl::Reference, so the copy
will ensure the lifetime of the object.
See 
https://gerrit.libreoffice.org/c/core/+/164986/2#message-5dd187741df3242f47d1037a1f9c9b0fd9bb1f8e

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

diff --git a/embeddedobj/source/msole/oleembed.cxx 
b/embeddedobj/source/msole/oleembed.cxx
index 821cbae9b1c4..a7a2bf661d70 100644
--- a/embeddedobj/source/msole/oleembed.cxx
+++ b/embeddedobj/source/msole/oleembed.cxx
@@ -623,8 +623,10 @@ uno::Sequence< sal_Int32 > SAL_CALL 
OleEmbeddedObject::getReachableStates()
 
 // the list of states can only be guessed based on standard verbs,
 // since there is no way to detect what additional verbs do
+// Pass m_pOleComponent to the lambda by copy, to make sure it doesn't 
depend on possible
+// destruction of 'this', while the lock is unset
 return GetReachableStatesList_Impl(
-ExecUnlocked([this] { return m_pOleComponent->GetVerbList(); }, 
aGuard));
+ExecUnlocked([p = m_pOleComponent] { return p->GetVerbList(); }, 
aGuard));
 }
 else
 #endif

[Bug 160055] Installer for LibreOffice 24.2 bug

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Bug 160053] LibreOfficePortable 7.6 crashes after switching to another window and afterwards returning to LOP - FILESAVE

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Bug 160050] CONFIGURATION: In Writer, on theme format, adding a theme shows window with covered text/graphics

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Bug 90917] Table cell with border padding on left edge disappearing under text

[bugzilla-daemon]

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

--- Comment #11 from QA Administrators  ---
Dear Janusz,

To make sure we're focusing on the bugs that affect our users today,
LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed
bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this
bug report. During that time, it's possible that the bug has been fixed, or the
details of the problem have changed. We'd really appreciate your help in
getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice
from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information
from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to
RESOLVED-WORKSFORME and leave a comment that includes the information from Help
- About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular
meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a
REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your
bug pertains to a feature added after 3.3) from
https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat:
https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Bug 160035] duplicated help page for .uno:InsertFieldCtrl

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Bug 156844] FORMATTING carriage return at end of paragraph reverts applied custom paragraph style to text body

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

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

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

[Bug 160047] Writer - CLI search format / backquotes

[bugzilla-daemon]

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

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Bug 156844] FORMATTING carriage return at end of paragraph reverts applied custom paragraph style to text body

[bugzilla-daemon]

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

--- Comment #3 from QA Administrators  ---
Dear ronjenson,

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.

[Bug 157069] Calc formatting border options won't display correctly with Colibre icons on the side bar.

[bugzilla-daemon]

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

--- Comment #2 from QA Administrators  ---
Dear darkmetal262,

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.

[Bug 38727] FILEOPEN, EDITING: Cross-reference to bookmark on DDE data does not update on file open

[bugzilla-daemon]

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

--- Comment #10 from QA Administrators  ---
Dear trumpton9,

To make sure we're focusing on the bugs that affect our users today,
LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed
bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this
bug report. During that time, it's possible that the bug has been fixed, or the
details of the problem have changed. We'd really appreciate your help in
getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice
from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information
from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to
RESOLVED-WORKSFORME and leave a comment that includes the information from Help
- About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular
meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a
REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your
bug pertains to a feature added after 3.3) from
https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat:
https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Bug 160283] New: New possibilities for Japanese language education: The emergence of ChatGPT

[bugzilla-daemon]

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

Bug ID: 160283
   Summary: New possibilities for Japanese language education: The
emergence of ChatGPT
   Product: cppunit
   Version: 1.14
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: General
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: roberto.legend...@gmail.com
CC: markus.mohrh...@googlemail.com

In recent years, advances in technology have revolutionized the way we learn
languages. In particular, advances in artificial intelligence (AI) are opening
up new possibilities in the field of language education. Among these, the
emergence of a language generation model called ChatGPT is bringing about major
changes in the field of Japanese language education. In this article, I would
like to explore a new form of Japanese language education using ChatGPT To use
more free Chatgpt features, please visit the following website:
https://chatgptjp.ai/

1. What is ChatGPT?

ChatGPT is one of the language generation models developed by OpenAI. The model
is trained on large datasets and can generate natural human-like speech. When a
user types a sentence into ChatGPT, it automatically generates a response based
on the context and continues the conversation.

2. Japanese language education using ChatGPT

ChatGPT can play various roles in the field of Japanese language education. For
example, it can be used in the following ways.

- Japanese conversation practice
You can practice Japanese conversation using ChatGPT. When users ask ChatGPT
questions in Japanese, the model generates appropriate responses and allows
them to practice conversation. This makes it possible to simulate a living
language environment.

- Learning Japanese grammar and vocabulary
ChatGPT has the ability to generate natural Japanese, so users can learn
Japanese grammar and vocabulary from ChatGPT. For example, you can ask ChatGPT
for examples of how to use a particular grammar to understand how that grammar
is used.

- Understanding culture and history
ChatGPT can handle a variety of topics, so you can also answer questions about
Japanese culture and history. Users can deepen their understanding of Japanese
culture and history through ChatGPT.

3. Advantages of education using ChatGPT

Japanese language education using ChatGPT has the following advantages.

- Flexibility and accessibility
ChatGPT is available online and can be used anytime, anywhere. We can also
provide customized learning experiences to suit the level and needs of
individual learners.

- Natural conversation experience
ChatGPT has the ability to generate natural conversations, so it can simulate a
living language environment. This gives learners a more realistic conversation
experience.

- Reinforcement and retention of learning
Using the Japanese language with ChatGPT will enhance learning and retention.
By practicing conversation repeatedly, learners will be able to speak Japanese
with more confidence.

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

[Bug 160226] LibreOffice Math: Clicking on visual elements (i.e. fraction) completely destroys your formula structure

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

Version|24.2.1.2 release|24.2.0.0 alpha0+
 CC||xiscofa...@libreoffice.org

--- Comment #8 from Stéphane Guillou (stragu) 
 ---
Thanks, Khaled.
Xisco, what do you think?

- 2d47c824cd31294899fa24989b3d7bd4f98dcdee: Visual mode made default + option
to turn it off, in which Khaled did note: "If it turns to be a disaster, we can
flip the option and disable it by default."
- ee187f6ed7873f3ebc1f845a4384a84713be1e9c: Always insert using SmCursor.

Instead of reverting everything, we can default to Visual mode off but keep it
out of experimental, and this report can stay open.

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

[Bug 101155] FILEOPEN PDF text overlaps because text is split to many boxes, with duplicated characters

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

Summary|FILEOPEN PDF text overlaps  |FILEOPEN PDF text overlaps
   |because text is split to|because text is split to
   |many boxes which don't fit  |many boxes, with duplicated
   ||characters

--- Comment #10 from Stéphane Guillou (stragu) 
 ---
Other sample PDF with same splitting issue in attachment 193198 from bug
160277.

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

[Bug 99746] [META] PDF import filter in Draw

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Depends on|160277  |


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=160277
[Bug 160277] FORMATTING: PDF File text spans appear double struck in
Libreoffice Draw, letters duplicated in draw text boxes
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 160277] FORMATTING: PDF File text spans appear double struck in Libreoffice Draw, letters duplicated in draw text boxes

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 Blocks|99746   |
 CC||stephane.guillou@libreoffic
   ||e.org

--- Comment #6 from Stéphane Guillou (stragu) 
 ---
Same issue as in bug 101155.

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


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=99746
[Bug 99746] [META] PDF import filter in Draw
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 101155] FILEOPEN PDF text overlaps because text is split to many boxes which don't fit

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||zarifah...@outlook.com

--- Comment #9 from Stéphane Guillou (stragu) 
 ---
*** Bug 160277 has been marked as a duplicate of this bug. ***

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

[Bug 32249] Make it easier to edit text in imported PDFs

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

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

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

[Bug 101155] FILEOPEN PDF text overlaps because text is split to many boxes which don't fit

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=32
   ||249
 CC||stephane.guillou@libreoffic
   ||e.org
 OS|Linux (All) |All

--- Comment #8 from Stéphane Guillou (stragu) 
 ---
Same in recent trunk build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

And on Windows 11.

However, opening the PDF in Firefox and doing Shift + Arrow keyboard selection
of characters e.g. in the "Nome" text run jumps to the line below before
reaching the "e". As if the whole document is split into columns of characters.

Same file is handled better in e.g. Evince and Okular, in which it is possible
to select whole lines of text.

Wondering where that kind of splitting is coming from (i.e. if whatever created
the PDF is somehow at fault), and if it is possible to mimic the grouping that
some PDF readers manage?

In any case, very much related to bug 32249.

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

[Bug 159683] Crash on closing LibreOffice with certain content on the clipboard

[bugzilla-daemon]

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

Matt K  changed:

   What|Removed |Added

 OS|Windows (All)   |All

--- Comment #10 from Matt K  ---
(In reply to Stéphane Guillou (stragu) from comment #8)
> As Telesto said, let's keep it Windows-specific.

I was able to repro with:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 53c5d570cab036b23f4969b858a648c8f0c24f93
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Calc: threaded

So, not OS-specific.  Not sure how to solve it either.  Interesting lines of
output:

warn:sw.core:2542771:2542771:sw/source/core/attr/format.cxx:217: ~SwFormat:
format still has clients on death, but parent format is missing: Character
style
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client
of type: 18SwFormatCharFormat at 0x606000e6f258 still registered on type:
8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client
of type: 18SwFormatCharFormat at 0x606000e6f3d8 still registered on type:
8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client
of type: 18SwFormatCharFormat at 0x606000e92d18 still registered on type:
8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client
of type: 18SwFormatCharFormat at 0x606000e91f98 still registered on type:
8SwModify at 0x613000207c40.

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

[Bug 49885] sync custom breakiterator rules with icu originals

[bugzilla-daemon]

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

Jonah Janzen  changed:

   What|Removed |Added

   Assignee|jonah.jan...@gmail.com  |libreoffice-b...@lists.free
   ||desktop.org

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

[Bug 84032] Intersection of some polygons produces wrong result

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

Version|unspecified |Inherited From OOo
 OS|Windows (All)   |All
 CC||rb.hensc...@t-online.de
   Hardware|Other   |All

--- Comment #11 from Stéphane Guillou (stragu) 
 ---
Regina, do you have any insights regarding my comment 10? (In particular on
differences between object types, my knowledge is limited on the topic.)

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

[Bug 84032] Intersection of some polygons produces wrong result

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||stephane.guillou@libreoffic
   ||e.org

--- Comment #10 from Stéphane Guillou (stragu) 
 ---
Created attachment 193207
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193207=edit
Modified sample ODG illustrating how line thickness and Z-order matter

Still as described in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Same in OOo 3.3, so behaviour is inherited.

But to me it is not clear that this is a bug, or what the bug is:
- I understand the intersection to be "everything that is contained in all of
the objects simultaneously"[1], which for two overlapping circles, with a line
thickness of 0, would include a fill if it exists.
- If the line has a non-zero thickness, and there is no fill, then it makes
sense to use that ring for the intersection.
- In the sample file, the grey disc is a "Bézier curve", and the circle is
"polygon with 400 corners". I'm not sure why the object is presented as an
empty pink circle when its Line has "Style: none" and its area is filled with
pink.
- LO uses the object styling (area fill, line properties...) of the object that
is behind for the resulting intersection object. In the original sample, the
circle is at the front, so the styling used is the grey disc's. If the Z-order
is switched, the result is a pink disc.
- If the objects are copied, result is different: 0-corner polygon regardless
of Z-order.

See attached modified sample, with shape examples illustrating how Z-order and
line thickness matter.

IMO, the actual issues are:
* Display of original objects:
   - line visible even though it's set to "none", uses fill colour;
   - no fill visible even though it is set to solid colour;
* Intersection of copies results in 0-corner polygons.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

[1]: https://en.wikipedia.org/wiki/Intersection

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

[Bug 160137] Following hyperlink to calc spreadsheet results in lost row and column freeze

[bugzilla-daemon]

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

breadsath...@gmail.com changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||breadsath...@gmail.com
 Status|UNCONFIRMED |NEW

--- Comment #1 from breadsath...@gmail.com ---
Thank you for reporting the bug. I can confirm that the bug is present and
reproducible in calc.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e939685f9c6918830bd3097062790bfccbce937e
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

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

[Bug 152391] VIEWING, CONFIGURATION: No possibility to customize or disable the display of the new Moved track changes

[bugzilla-daemon]

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

--- Comment #3 from robert.funn...@mcgill.ca ---
This problem persists in version 24.2.1.2.
Sometimes the tracking of moves is very useful, but it is also often a
nuisance.
Sometimes trivial things are flagged as moves, as when deleting common words
like 'due to' and then later adding an unrelated occurrence of those words
somewhere else.
When revising a sentence, it is not very important to show that a few words
have been moved, especially when a word is modified (e.g., 'suspect something'
-> 'suspicion of something') and only part of the word is flagged as having
been moved and the rest is shown as having been added.
I think it would be valuable to be able to customize the settings for this new
feature, but even more important to be able to turn it on and off.

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

[Bug 92185] pdfimport: lines visible outside where they should be

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Depends on|86211   |


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=86211
[Bug 86211] PDF Import: clipping is not implemented
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 79043] Image cropping issue while importing a PDF document

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Depends on|86211   |


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=86211
[Bug 86211] PDF Import: clipping is not implemented
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 86211] PDF Import: clipping is not implemented

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Blocks|79043, 92185|


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=79043
[Bug 79043] Image cropping issue while importing a PDF document
https://bugs.documentfoundation.org/show_bug.cgi?id=92185
[Bug 92185] pdfimport: lines visible outside where they should be
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 157031] Character dialog opens with small but annoying lag (3 seconds) every time when opening (macOS)

[bugzilla-daemon]

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

--- Comment #6 from Stéphane Guillou (stragu) 
 ---
Duplicate bug 160281 suggests it's correlated to the number of fonts installed,
so if someone bibisects it, installing some extra fonts might help making the
delay more obvious.

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

[Bug 160281] UI - fontd churns every time a modal window opens

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||stephane.guillou@libreoffic
   ||e.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Stéphane Guillou (stragu) 
 ---
Thank you for the report.
I believe this is the same issue as bug 157031.
If you are up for it, a bibisect would be very helpful:
https://bibisect.libreoffice.org/

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

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

[Bug 157031] Character dialog opens with small but annoying lag (3 seconds) every time when opening (macOS)

[bugzilla-daemon]

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

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||sneakers-the-rat@protonmail
   ||.com

--- Comment #5 from Stéphane Guillou (stragu) 
 ---
*** Bug 160281 has been marked as a duplicate of this bug. ***

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

[Bug 160174] Impress/Draw internal link update sometimes erroneous depending on how slide/page order is changed

[bugzilla-daemon]

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

breadsath...@gmail.com changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||breadsath...@gmail.com
 Status|UNCONFIRMED |NEW

--- Comment #2 from breadsath...@gmail.com ---
Thank you for reporting the bug. I can confirm that the bug is present in
impress. Moreover, the link pointing to the target slide keeps increasing by 1
each time the process is repeated (goes to non-existent slides 5, 6, 7, etc.).

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e939685f9c6918830bd3097062790bfccbce937e
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

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

[Bug 160276] Writer comment: Author and Date info should use same padding as is used for comment text

[bugzilla-daemon]

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

steve  changed:

   What|Removed |Added

   Priority|medium  |low

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

[Bug 159530] In dark mode, Calc's page breaks' light-gray watermarks and dark-blue borders don't fit the theme

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

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

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

[Bug 38304] EDITING : Calc doesn't show colored borders on referenced cells when editing formula

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

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

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

[Bug 153293] [META] Dark Mode bugs and enhancements

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

 Depends on||160282


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=160282
[Bug 160282] Ranges references text colors for in-cell editing of formulas are
too dark for dark mode, causing low contrast
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 108253] [META] Calc cell formula bugs and enhancements

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

 Depends on||160282


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=160282
[Bug 160282] Ranges references text colors for in-cell editing of formulas are
too dark for dark mode, causing low contrast
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 160282] Ranges references text colors for in-cell editing of formulas are too dark for dark mode, causing low contrast

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=38
   ||304,
   ||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=15
   ||9530
   Keywords||accessibility
 Blocks||59284, 108253, 153293


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=59284
[Bug 59284] [META] Calc cell border related issues
https://bugs.documentfoundation.org/show_bug.cgi?id=108253
[Bug 108253] [META] Calc cell formula bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=153293
[Bug 153293] [META] Dark Mode bugs and enhancements
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 59284] [META] Calc cell border related issues

[bugzilla-daemon]

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

Jeff Fortin Tam  changed:

   What|Removed |Added

 Depends on||160282


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=160282
[Bug 160282] Ranges references text colors for in-cell editing of formulas are
too dark for dark mode, causing low contrast
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 160282] New: Ranges references text colors for in-cell editing of formulas are too dark for dark mode, causing low contrast

[bugzilla-daemon]

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

Bug ID: 160282
   Summary: Ranges references text colors for in-cell editing of
formulas are too dark for dark mode, causing low
contrast
   Product: LibreOffice
   Version: 24.2.0.3 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: nekoh...@gmail.com

Created attachment 193206
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193206=edit
Screenshot from LibreOffice Calc in dark mode

As you can see in the attached screenshot, most of the automatic cell border
colors for cells/ranges references in formulas, when you are editing a formula
"within the canvas/cell" by double-clicking a cell, are not appropriate for
LibreOffice's dark mode.

They should be lighter variants of those colors in order to ensure enough
contrast with the dark background.

--

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded

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

[Bug 148184] FORMATTING create a means to represent an integer as an IP Address

[bugzilla-daemon]

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

--- Comment #3 from Eyal Rozenberg  ---
I believe the best thing to implement would be OP's alternative suggestion:

> Alternatively, a means to create a personalized format representation with a
> module function would be also be a way to enhance the personalized format
> feature.

That really scratches the itch IMHO.

As for the main ask here - I weakly-support it, because:

1. IP addresses, while not a very common use cases, are not a tiny niche; and
tables of data involving IP addresses are often the result of event logging on
the Internet.

2. We already support a variety of number formatting types, in several
categories, and do not lack anything in the UI for enabling this support.

3. "Third-party" support requires either keeping every element of the IP in a
separate column (which many not even be possible with IPv6), or doing a lot of
string processing. Both are cumbersome to work with and I'm worried about
performance when using them.

4. Either MS Excel has it, in which case - competitor parity; or it doesn't
have it, in which case: one-upping the competition :-)

I realize that someone might argue "oh, but shall we now add another number
format option for any number of niche formats?" - and the answer to that is,
that AFAICT, there are extremely few, if any, other such requests, and I doubt
the adoption of IP formatting will change this.

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

[Bug 148184] FORMATTING create a means to represent an integer as an IP Address

[bugzilla-daemon]

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

--- Comment #3 from Eyal Rozenberg  ---
I believe the best thing to implement would be OP's alternative suggestion:

> Alternatively, a means to create a personalized format representation with a
> module function would be also be a way to enhance the personalized format
> feature.

That really scratches the itch IMHO.

As for the main ask here - I weakly-support it, because:

1. IP addresses, while not a very common use cases, are not a tiny niche; and
tables of data involving IP addresses are often the result of event logging on
the Internet.

2. We already support a variety of number formatting types, in several
categories, and do not lack anything in the UI for enabling this support.

3. "Third-party" support requires either keeping every element of the IP in a
separate column (which many not even be possible with IPv6), or doing a lot of
string processing. Both are cumbersome to work with and I'm worried about
performance when using them.

4. Either MS Excel has it, in which case - competitor parity; or it doesn't
have it, in which case: one-upping the competition :-)

I realize that someone might argue "oh, but shall we now add another number
format option for any number of niche formats?" - and the answer to that is,
that AFAICT, there are extremely few, if any, other such requests, and I doubt
the adoption of IP formatting will change this.

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

core.git: bin/oss-fuzz-setup.sh Repository.mk sc/source vcl/Executable_fods2xlsfuzzer.mk vcl/Module_vcl.mk vcl/workben

[Noel Grandin (via logerrit)]

 Repository.mk  |1 
 bin/oss-fuzz-setup.sh  |1 
 sc/source/filter/xml/xmlimprt.cxx  |   76 +
 vcl/Executable_fods2xlsfuzzer.mk   |   50 +++
 vcl/Module_vcl.mk  |1 
 vcl/workben/fftester.cxx   |   10 +++
 vcl/workben/fods2xlsfuzzer.cxx |   96 +
 vcl/workben/fods2xlsfuzzer.options |3 +
 8 files changed, 238 insertions(+)

New commits:
commit 53c5d570cab036b23f4969b858a648c8f0c24f93
Author: Noel Grandin 
AuthorDate: Tue Jan 30 13:47:03 2024 +0200
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 22:35:06 2024 +0100

fods2xls fuzzer

Change-Id: I095178b1b3c61829abf5c08b8b81cd7415e3e795
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162747
Tested-by: Caolán McNamara 
Reviewed-by: Caolán McNamara 

diff --git a/Repository.mk b/Repository.mk
index c0d86f868971..aa740fae6860 100644
--- a/Repository.mk
+++ b/Repository.mk
@@ -146,6 +146,7 @@ $(eval $(call 
gb_Helper_register_executables_for_install,OOO,brand, \
$(call gb_Helper_optional,FUZZERS,slkfuzzer) \
$(call gb_Helper_optional,FUZZERS,fodtfuzzer) \
$(call gb_Helper_optional,FUZZERS,fodt2pdffuzzer) \
+   $(call gb_Helper_optional,FUZZERS,fods2xlsfuzzer) \
$(call gb_Helper_optional,FUZZERS,fodsfuzzer) \
$(call gb_Helper_optional,FUZZERS,fodpfuzzer) \
$(call gb_Helper_optional,FUZZERS,xlsfuzzer) \
diff --git a/bin/oss-fuzz-setup.sh b/bin/oss-fuzz-setup.sh
index 5e7452640799..d8ad9f44f262 100755
--- a/bin/oss-fuzz-setup.sh
+++ b/bin/oss-fuzz-setup.sh
@@ -166,5 +166,6 @@ curl --no-progress-meter -S \
 -C - -O https://dev-www.libreoffice.org/corpus/htmlfuzzer_seed_corpus.zip \
 -C - -O https://dev-www.libreoffice.org/corpus/zipfuzzer_seed_corpus.zip
 cp fodtfuzzer_seed_corpus.zip fodt2pdffuzzer_seed_corpus.zip
+cp fodsfuzzer_seed_corpus.zip fods2xlsfuzzer_seed_corpus.zip
 
 echo end downloading dependencies at `date -u`
diff --git a/sc/source/filter/xml/xmlimprt.cxx 
b/sc/source/filter/xml/xmlimprt.cxx
index b94d1d44d8fa..dcd8229c77ad 100644
--- a/sc/source/filter/xml/xmlimprt.cxx
+++ b/sc/source/filter/xml/xmlimprt.cxx
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -83,6 +84,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1722,6 +1724,80 @@ extern "C" SAL_DLLPUBLIC_EXPORT bool 
TestImportFODS(SvStream )
 return ret;
 }
 
+extern "C" SAL_DLLPUBLIC_EXPORT bool TestFODSExportXLS(SvStream )
+{
+ScDLL::Init();
+
+SfxObjectShellLock xDocSh(new ScDocShell);
+xDocSh->DoInitNew();
+uno::Reference xModel(xDocSh->GetModel());
+
+uno::Reference 
xMultiServiceFactory(comphelper::getProcessServiceFactory());
+uno::Reference xStream(new 
::utl::OSeekableInputStreamWrapper(rStream));
+uno::Reference 
xInterface(xMultiServiceFactory->createInstance("com.sun.star.comp.Writer.XmlFilterAdaptor"),
 uno::UNO_SET_THROW);
+
+css::uno::Sequence aUserData
+{
+"com.sun.star.comp.filter.OdfFlatXml",
+"",
+"com.sun.star.comp.Calc.XMLOasisImporter",
+"com.sun.star.comp.Calc.XMLOasisExporter",
+"",
+"",
+"true"
+};
+uno::Sequence 
aAdaptorArgs(comphelper::InitPropertySequence(
+{
+{ "UserData", uno::Any(aUserData) },
+}));
+css::uno::Sequence aOuterArgs{ uno::Any(aAdaptorArgs) };
+
+uno::Reference xInit(xInterface, 
uno::UNO_QUERY_THROW);
+xInit->initialize(aOuterArgs);
+
+uno::Reference xImporter(xInterface, 
uno::UNO_QUERY_THROW);
+uno::Sequence aArgs(comphelper::InitPropertySequence(
+{
+{ "InputStream", uno::Any(xStream) },
+{ "URL", uno::Any(OUString("private:stream")) },
+}));
+xImporter->setTargetDocument(xModel);
+
+uno::Reference xFilter(xInterface, 
uno::UNO_QUERY_THROW);
+//SetLoading hack because the document properties will be re-initted
+//by the xml filter and during the init, while it's considered 
uninitialized,
+//setting a property will inform the document it's modified, which attempts
+//to update the properties, which throws cause the properties are 
uninitialized
+xDocSh->SetLoading(SfxLoadedFlags::NONE);
+bool ret = xFilter->filter(aArgs);
+xDocSh->SetLoading(SfxLoadedFlags::ALL);
+
+if (ret)
+{
+utl::TempFileFast aTempFile;
+
+uno::Reference xXLSFilter(
+
xMultiServiceFactory->createInstance("com.sun.star.comp.oox.xls.ExcelFilter"), 
uno::UNO_QUERY);
+uno::Reference xExporter(xXLSFilter, 
uno::UNO_QUERY);
+xExporter->setSourceDocument(xModel);
+
+uno::Reference xOutputStream(new 
utl::OStreamWrapper(*aTempFile.GetStream(StreamMode::READWRITE)));
+
+uno::Sequence 
aFilterData(comphelper::InitPropertySequence({
+}));
+uno::Sequence 

core.git: vcl/source

[Caolán McNamara (via logerrit)]

 vcl/source/filter/png/PngImageReader.cxx |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

New commits:
commit 3bec2d6a8a96102d5a6e93c339601347effa97d7
Author: Caolán McNamara 
AuthorDate: Tue Mar 19 08:41:13 2024 +
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 22:33:04 2024 +0100

ofz#67495 Out-of-memory

Change-Id: I9c0264b5f474e5448ecaea55e608001438654302
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165016
Tested-by: Jenkins
Reviewed-by: Caolán McNamara 

diff --git a/vcl/source/filter/png/PngImageReader.cxx 
b/vcl/source/filter/png/PngImageReader.cxx
index 2af433f9d555..0445aff40af9 100644
--- a/vcl/source/filter/png/PngImageReader.cxx
+++ b/vcl/source/filter/png/PngImageReader.cxx
@@ -885,9 +885,11 @@ bool PngImageReader::isAPng(SvStream& rStream)
 rStream.ReadUInt32(nChunkType);
 if (!rStream.good() || nChunkType != PNG_IHDR_SIGNATURE)
 return false;
-rStream.SeekRel(nChunkSize);
+if (!checkSeek(rStream, rStream.Tell() + nChunkSize))
+return false;
 // Skip IHDR CRC
-rStream.SeekRel(PNG_CRC_SIZE);
+if (!checkSeek(rStream, rStream.Tell() + PNG_CRC_SIZE))
+return false;
 // Look for acTL chunk that exists before the first IDAT chunk
 while (true)
 {

[Bug 160024] Tautological string in need of improvement

[bugzilla-daemon]

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

Adolfo Jayme Barrientos  changed:

   What|Removed |Added

Summary|Cacophonous string in need  |Tautological string in need
   |of improvement  |of improvement

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

[Bug 159373] Crash in: ScTable::HasAttrib(short,long,short,long,HasAttrFlags)

[bugzilla-daemon]

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

Adolfo Jayme Barrientos  changed:

   What|Removed |Added

 Whiteboard|target:24.8.0 target:24.2.3 |target:24.8.0
   |target:7.6.7 target:7.6.6   |target:24.2.2.2
   |target:24.2.2   |target:7.6.6.2

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

[Bug 159373] Crash in: ScTable::HasAttrib(short,long,short,long,HasAttrFlags)

[bugzilla-daemon]

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

--- Comment #18 from Commit Notification 
 ---
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-24-2-2":

https://git.libreoffice.org/core/commit/40f6e9a45edae06556e1d1a26237dc2ab12bc0ca

tdf#159373: band-aid for crash in: ScTable::HasAttrib

It will be available in 24.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

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

[Bug 159373] Crash in: ScTable::HasAttrib(short,long,short,long,HasAttrFlags)

[bugzilla-daemon]

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

Commit Notification  changed:

   What|Removed |Added

 Whiteboard|target:24.8.0 target:24.2.3 |target:24.8.0 target:24.2.3
   |target:7.6.7 target:7.6.6   |target:7.6.7 target:7.6.6
   ||target:24.2.2

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

core.git: Branch 'libreoffice-24-2-2' - sc/source

[Julien Nabet (via logerrit)]

 sc/source/ui/docshell/docsh3.cxx |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 40f6e9a45edae06556e1d1a26237dc2ab12bc0ca
Author: Julien Nabet 
AuthorDate: Mon Mar 4 13:21:06 2024 +0100
Commit: Adolfo Jayme Barrientos 
CommitDate: Tue Mar 19 22:22:45 2024 +0100

tdf#159373: band-aid for crash in: ScTable::HasAttrib

band-aid because as Eike indicated in 
https://bugs.documentfoundation.org/show_bug.cgi?id=159373#c8
"Question remains why this PostPaint() is called at all for an invalid 
range.."

Change-Id: Ie44378119202addd8ddb46f0be4b0124be9fd48b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164354
Tested-by: Jenkins
Reviewed-by: Julien Nabet 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164644
(cherry picked from commit 2bb8b6df61d3fd27d38a9ac1724295b885e5e919)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164627
Reviewed-by: Michael Weghorn 
Tested-by: Adolfo Jayme Barrientos 
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/sc/source/ui/docshell/docsh3.cxx b/sc/source/ui/docshell/docsh3.cxx
index 96546d11a5fe..4634c5cbf191 100644
--- a/sc/source/ui/docshell/docsh3.cxx
+++ b/sc/source/ui/docshell/docsh3.cxx
@@ -118,6 +118,9 @@ void ScDocShell::PostPaint( const ScRangeList& rRanges, 
PaintPartFlags nPart, sa
 SCROW nRow1 = rRange.aStart.Row(), nRow2 = rRange.aEnd.Row();
 SCTAB nTab1 = rRange.aStart.Tab(), nTab2 = std::min(nMaxTab, 
rRange.aEnd.Tab());
 
+if (nTab1 < 0 || nTab2 < 0)
+continue;
+
 if (!m_pDocument->ValidCol(nCol1)) nCol1 = m_pDocument->MaxCol();
 if (!m_pDocument->ValidRow(nRow1)) nRow1 = m_pDocument->MaxRow();
 if (!m_pDocument->ValidCol(nCol2)) nCol2 = m_pDocument->MaxCol();

core.git: Branch 'libreoffice-24-2' - sw/source

[Armin Le Grand (allotropia) (via logerrit)]

 sw/source/core/tox/tox.cxx|8 +++-
 sw/source/ui/index/swuiidxmrk.cxx |   37 -
 sw/source/uibase/index/toxmgr.cxx |3 ++-
 3 files changed, 29 insertions(+), 19 deletions(-)

New commits:
commit a48ee46a085abfa04779ece38c08dddb5bf017ea
Author: Armin Le Grand (allotropia) 
AuthorDate: Fri Jan 12 11:22:04 2024 +0100
Commit: Adolfo Jayme Barrientos 
CommitDate: Tue Mar 19 22:21:40 2024 +0100

tdf#158783 Correct compares of SwTOXMark Items

That item was never 'pooled', so operator== was not really
ever used. It just compared the 'type', so pretty many
instances were assumed to be equal, what is wrong.
We discussed to implement it (there is quite some content),
but we came to the point that it's only safe to say
instances are equal when same instance -> fallback to ptr
compare.
This came into play since I identified/changed many (160?)
places where SfxPoolItems were ptr-compared when doing that
paradigm change in Items. This leads to the two methods
'areSfxPoolItemPtrsEqual' which just makes ptr compare and
'SfxPoolItem::areSame' which also will use op==. For the
initial adaption I chose the wrong function adapting
places where SwTOXMark were involved.

Change-Id: I7df029ad4542719681b1455de17ed5990d248395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161963
Reviewed-by: Michael Stahl 
Tested-by: Armin Le Grand 
(cherry picked from commit d22a86089edfcadbef5231525a2947b954f4784e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164996
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/sw/source/core/tox/tox.cxx b/sw/source/core/tox/tox.cxx
index 04f43e5d41f8..b29bafde11f6 100644
--- a/sw/source/core/tox/tox.cxx
+++ b/sw/source/core/tox/tox.cxx
@@ -148,7 +148,13 @@ void SwTOXMark::RegisterToTOXType(SwTOXType& rType)
 bool SwTOXMark::operator==( const SfxPoolItem& rAttr ) const
 {
 assert(SfxPoolItem::operator==(rAttr));
-return m_pType == static_cast(rAttr).m_pType;
+// tdf#158783 this item was never 'pooled', so operator== was not really
+// ever used. We discussed to implement it (there is quite some
+// content), but we came to the point that it's only safe to say
+// instances are equal when same instance -> fallback to ptr compare.
+// NOTE: Do *not* use areSfxPoolItemPtrsEqual here, with DBG_UTIL
+//   active the contol/test code there would again call operator==
+return this == 
 }
 
 SwTOXMark* SwTOXMark::Clone( SfxItemPool* ) const
diff --git a/sw/source/ui/index/swuiidxmrk.cxx 
b/sw/source/ui/index/swuiidxmrk.cxx
index 39443f7e7b04..8a6f74b86ee8 100644
--- a/sw/source/ui/index/swuiidxmrk.cxx
+++ b/sw/source/ui/index/swuiidxmrk.cxx
@@ -287,19 +287,20 @@ void SwIndexMarkPane::InitControls()
 bool bShow = false;
 
 pMoveMark = _pSh->GotoTOXMark( *pMark, TOX_PRV );
-if (!SfxPoolItem::areSame( pMoveMark, pMark ))
+// tdf#158783 ptr compare OK for SwTOXMark (more below)
+if (!areSfxPoolItemPtrsEqual( pMoveMark, pMark ))
 {
 m_pSh->GotoTOXMark( *pMoveMark, TOX_NXT );
 bShow = true;
 }
-m_xPrevBT->set_sensitive(!SfxPoolItem::areSame(pMoveMark, pMark));
+m_xPrevBT->set_sensitive(!areSfxPoolItemPtrsEqual(pMoveMark, pMark));
 pMoveMark = _pSh->GotoTOXMark( *pMark, TOX_NXT );
-if (!SfxPoolItem::areSame( pMoveMark, pMark ))
+if (!areSfxPoolItemPtrsEqual( pMoveMark, pMark ))
 {
 m_pSh->GotoTOXMark( *pMoveMark, TOX_PRV );
 bShow = true;
 }
-m_xNextBT->set_sensitive(!SfxPoolItem::areSame(pMoveMark, pMark));
+m_xNextBT->set_sensitive(!areSfxPoolItemPtrsEqual(pMoveMark, pMark));
 if( bShow )
 {
 m_xPrevBT->show();
@@ -308,19 +309,19 @@ void SwIndexMarkPane::InitControls()
 }
 
 pMoveMark = _pSh->GotoTOXMark( *pMark, TOX_SAME_PRV );
-if (!SfxPoolItem::areSame( pMoveMark, pMark ))
+if (!areSfxPoolItemPtrsEqual( pMoveMark, pMark ))
 {
 m_pSh->GotoTOXMark( *pMoveMark, TOX_SAME_NXT );
 bShow = true;
 }
-m_xPrevSameBT->set_sensitive(!SfxPoolItem::areSame(pMoveMark, pMark));
+m_xPrevSameBT->set_sensitive(!areSfxPoolItemPtrsEqual(pMoveMark, 
pMark));
 pMoveMark = _pSh->GotoTOXMark( *pMark, TOX_SAME_NXT );
-if (!SfxPoolItem::areSame( pMoveMark, pMark ))
+if (!areSfxPoolItemPtrsEqual( pMoveMark, pMark ))
 {
 m_pSh->GotoTOXMark( *pMoveMark, TOX_SAME_PRV );
 bShow = true;
 }
-m_xNextSameBT->set_sensitive(!SfxPoolItem::areSame(pMoveMark, pMark));
+m_xNextSameBT->set_sensitive(!areSfxPoolItemPtrsEqual(pMoveMark, 
pMark));
 if( bShow )
 {
 m_xNextSameBT->show();
@@ -894,25 +895,26 @@ void 

[Bug 160057] Document Calc's separate Footer and Header tabs if "Same content on first page" is off

[bugzilla-daemon]

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

--- Comment #5 from Commit Notification 
 ---
Stéphane Guillou committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/help/commit/9bed20d260f9c0dfd5a43f62bba288aff829da85

related tdf#160057: replace ref to obsolete Footer Header page

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

[Bug 160057] Document Calc's separate Footer and Header tabs if "Same content on first page" is off

[bugzilla-daemon]

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

Commit Notification  changed:

   What|Removed |Added

 Whiteboard|target:24.8.0   |target:24.8.0 target:24.2.3

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

core.git: Branch 'libreoffice-24-2' - helpcontent2

[Stéphane Guillou (via logerrit)]

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

New commits:
commit 65ab35f21f18dc6048eeeb218a786ccf0a9584bc
Author: Stéphane Guillou 
AuthorDate: Tue Mar 19 22:19:08 2024 +0100
Commit: Gerrit Code Review 
CommitDate: Tue Mar 19 22:19:08 2024 +0100

Update git submodules

* Update helpcontent2 from branch 'libreoffice-24-2'
  to 9bed20d260f9c0dfd5a43f62bba288aff829da85
  - related tdf#160057: replace ref to obsolete Footer Header page

Change-Id: Ie6df598c42149ecc527a1a2eef35a7aba469c216
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/164387
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 
(cherry picked from commit 04dcd1b951689689f9449408fd6f512a9c87aa0d)
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/164991

diff --git a/helpcontent2 b/helpcontent2
index d25d6d02f061..9bed20d260f9 16
--- a/helpcontent2
+++ b/helpcontent2
@@ -1 +1 @@
-Subproject commit d25d6d02f06138274426492ef11f35409966e829
+Subproject commit 9bed20d260f9c0dfd5a43f62bba288aff829da85

help.git: Branch 'libreoffice-24-2' - helpers/unocmds.txt

[Stéphane Guillou (via logerrit)]

 helpers/unocmds.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 9bed20d260f9c0dfd5a43f62bba288aff829da85
Author: Stéphane Guillou 
AuthorDate: Wed Mar 6 12:23:37 2024 +0100
Commit: Adolfo Jayme Barrientos 
CommitDate: Tue Mar 19 22:19:08 2024 +0100

related tdf#160057: replace ref to obsolete Footer Header page

Change-Id: Ie6df598c42149ecc527a1a2eef35a7aba469c216
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/164387
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 
(cherry picked from commit 04dcd1b951689689f9449408fd6f512a9c87aa0d)
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/164991

diff --git a/helpers/unocmds.txt b/helpers/unocmds.txt
index e5ece05cf1..835c1f4817 100644
--- a/helpers/unocmds.txt
+++ b/helpers/unocmds.txt
@@ -338,7 +338,7 @@
 .uno:EditDoc;shared/02/0707.xhp
 .uno:EditFootnote;swriter/01/0215.xhp
 .uno:EditGlossary;swriter/01/0212.xhp
-.uno:EditHeaderAndFooter;scalc/01/0212.xhp
+.uno:EditHeaderAndFooter;scalc/01/02120100.xhp
 .uno:EditHyperlink;shared/02/0907.xhp
 .uno:EditLinks;shared/01/0218.xhp
 .uno:EditPrintArea;scalc/01/05080300.xhp

[Bug 160280] Check-boxes will not be printed

[bugzilla-daemon]

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

m_a_riosv  changed:

   What|Removed |Added

 CC||miguelangelrv@libreoffice.o
   ||rg

--- Comment #2 from m_a_riosv  ---
Created attachment 193205
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193205=edit
Screenshot option on exporting as PDF

With the options in the attached screenshot, works for me.
Version: 24.2.2.1 (X86_64) / LibreOffice Community
Build ID: bf759d854b5ab45b6ef0bfd22e51c6dc4fb8b882
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

If doesn't work for you, please test in safe mode, Menu/Help/Restart in Safe
Mode

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

[Bug 160271] Special characters are not rotated in TBRL oriented cell

[bugzilla-daemon]

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

--- Comment #7 from ⁨خالد حسني⁩  ---
(In reply to raal from comment #6)
> This seems to have begun at the below commit in bibisect repository/OS
> bibisect-linux-64-5.3.
> Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one?
> Thanks
>  a96fae002641d2e60ade68bbd315ce0078f3d5a4 is the first bad commit
> commit a96fae002641d2e60ade68bbd315ce0078f3d5a4
> Author: Jenkins Build User 
> Date:   Thu Nov 10 02:01:17 2016 +0100
> 
> source f26df72f6e424492d101f527deb81f550ff3c941
> 
> source f26df72f6e424492d101f527deb81f550ff3c941
> source 73b9b72cf1658208c2b2eb10cc0acfc3833dd875
> 
> https://git.libreoffice.org/core/+/f26df72f6e424492d101f527deb81f550ff3c941
> https://git.libreoffice.org/core/+/73b9b72cf1658208c2b2eb10cc0acfc3833dd875
> tdf#103718: Correctly set vertical direction

There is no bug here. The expected output is wrong. This is not rotated text,
but vertical text with embedded LTR text that gets rotated, “special”
characters, CJK, etc, don’t get rotated for vertical text.

The only bug here, as indicated in Comment 3, is that bottom to top text should
behave like top to bottom text, but I don’t know why it doesn’t.

Code in VCL checks for SalLayoutFlags::Vertical, so some code above it is not
setting this flag.

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

[Bug 160276] Writer comment: Author and Date info should use same padding as is used for comment text

[bugzilla-daemon]

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

m_a_riosv  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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

[Bug 160281] New: UI - fontd churns every time a modal window opens

[bugzilla-daemon]

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

Bug ID: 160281
   Summary: UI - fontd churns every time a modal window opens
   Product: LibreOffice
   Version: 24.2.1.2 release
  Hardware: x86-64 (AMD64)
OS: macOS (All)
Status: UNCONFIRMED
  Severity: minor
  Priority: medium
 Component: Writer
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: sneakers-the-...@protonmail.com

Description:
I have a lot of fonts, ok. i admit it. This is a problem in many programs,
illustrator hangs when i open the font menu the first time, so does MS word,
etc. 

LibreOffice seems to want to recompute the font cache every time i open a modal
window - this seems to only happen on modals that have some kind of font
setting like editing header/paragraph styles. LibreOffice will hang
unresponsive for ~45s and both fontd and libreoffice will spike to using a full
CPU core, making it seem like it is recomputing the fonts every time? would it
be possible to cache whatever is going on there? 

Resetting user profile did not help

LibreOffice 24.2.1.2 (x86_64)
https://git.libreoffice.org/core/+log/db4def46b0453cc22e2d0305797cf981b68ef5ac
MacOS 14.3.1

Steps to Reproduce:
1. Have a lot of fonts
2. Open any of the font editing modals
3. Wait!

Actual Results:
I had to wait a bunch!

Expected Results:
I should not have to wait a bunch! or at least i should only have to wait one
time while the font cache is built


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Thanks for everything you do!

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

[Bug 160226] LibreOffice Math: Clicking on visual elements (i.e. fraction) completely destroys your formula structure

[bugzilla-daemon]

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

--- Comment #7 from ⁨خالد حسني⁩  ---
At this point I think we should flip the default back to disable visual
editing. It seems to be more trouble than it is worth it without someone
invested in fixing these issues. I don’t have a working LO build setup, though,
so someone else has to do it.

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

[Bug 160277] FORMATTING: PDF File text spans appear double struck in Libreoffice Draw, letters duplicated in draw text boxes

[bugzilla-daemon]

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

V Stuart Foote  changed:

   What|Removed |Added

Summary|FORMATTING: PDF File|FORMATTING: PDF File text
   |renders incorrectly in  |spans appear double struck
   |Libreoffice Draw|in Libreoffice Draw,
   ||letters duplicated in draw
   ||text boxes
 CC||vsfo...@libreoffice.org

--- Comment #5 from V Stuart Foote  ---
Hmm, so how does the PDF look if you Insert as image, using the pdfium project
lib based filter?

We'll read the PDF, using poppler and write to a Cairo surface then
interpreting the PDF into a series of ODF draw objects.

If fonts are missing/mislabeled within the PDF, a font substitution occurs in
creating the draw text box objects. We don't necessarily use an embedded font
subset. Also, we depend on poppler to split the text spans--in this case looks
like we're getting a "double struck" affect bcz of some word bound issue.
Letters are being repeated between words of the text spans and then not lining
up when rendered as draw text boxes.

If you need fidelity to the source PDF, insert (currently need to split pages
of the PDF) as image.

If you just need the content of the PDF to work with as ODF draw objects, with
some loss of layout, then open the PDF.

LibreOffice is not a PDF editor.

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

[Bug 160011] Hidden columns should not prevent text from preceding columns from overflowing over their cells

[bugzilla-daemon]

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

--- Comment #14 from Eyal Rozenberg  ---
Created attachment 193204
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193204=edit
Calc document exhibiting the bug - column B is hidden

This document is the result of following the reproduction instructions in the
opening comment.

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

[Bug 160011] Hidden columns should not prevent text from preceding columns from overflowing over their cells

[bugzilla-daemon]

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

--- Comment #14 from Eyal Rozenberg  ---
Created attachment 193204
  --> https://bugs.documentfoundation.org/attachment.cgi?id=193204=edit
Calc document exhibiting the bug - column B is hidden

This document is the result of following the reproduction instructions in the
opening comment.

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

[Bug 160011] Hidden columns should not prevent text from preceding columns from overflowing over their cells

[bugzilla-daemon]

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

--- Comment #13 from Eyal Rozenberg  ---
I support the request change as per the bug title, because:

1. Hidden should mean hidden, i.e. the sheet presents as though the column did
not exist. Otherwise it's effectively width-0.

2. Like Heiko mentioned in comment #6, MSO parity

I am not worried about breakage, for two reasons:

1. Whoever uses hidden columns must expect users to sometimes unhide the
columns, and plan for how their sheet will display when that happens.

2. Whoever uses hidden columns should expect the file to also work in MS Excel,
where the behavior is different.

3. One can achieve the width-0 before with a literal width-0, non-hidden,
column, so the breakage can be rectified relatively easily.

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

[Bug 160011] Hidden columns should not prevent text from preceding columns from overflowing over their cells

[bugzilla-daemon]

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

--- Comment #13 from Eyal Rozenberg  ---
I support the request change as per the bug title, because:

1. Hidden should mean hidden, i.e. the sheet presents as though the column did
not exist. Otherwise it's effectively width-0.

2. Like Heiko mentioned in comment #6, MSO parity

I am not worried about breakage, for two reasons:

1. Whoever uses hidden columns must expect users to sometimes unhide the
columns, and plan for how their sheet will display when that happens.

2. Whoever uses hidden columns should expect the file to also work in MS Excel,
where the behavior is different.

3. One can achieve the width-0 before with a literal width-0, non-hidden,
column, so the breakage can be rectified relatively easily.

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

[Bug 104768] Poor linking to Macro documentation

[bugzilla-daemon]

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

--- Comment #9 from f...@bger.ch ---
(In reply to Mike Kaganski from comment #8)
>  huge list

an idea ...
https://documentation.libreoffice.org/de/documentation/

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

core.git: Branch 'libreoffice-24-2' - sw/source

[Michael Stahl (via logerrit)]

 sw/source/core/docnode/ndtbl.cxx |   36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

New commits:
commit df5bb0c4343b4a090de3343c7d454a93099989c0
Author: Michael Stahl 
AuthorDate: Wed Mar 13 18:57:21 2024 +0100
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 20:56:46 2024 +0100

tdf#157241 sw: fix crash on RTF paste or insert of nested tables

The problem is that there are tables with only empty cell frames in the
layout, which causes a crash in IsAllHiddenCell() added in commit
ab7893544dc6be6dc192dffefd57cd5ddd421c35.

This happens because first inner tables are created, with layout frames
because the layout already exists.

Then when SwNodes::TextToTable() is called for the outer table, it
deletes the SwTextFrames, but not the SwTabFrames/SwCellFrames, so they
remain uselessly in the layout.

Delete these too, they will be recreated when the frame for the outer
table is created.

Also the transfer of any existing break to the outer table was missing.

Change-Id: Idc2bc1d4c6572702510ae4355e4015c42770eb3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164788
Tested-by: Jenkins
Reviewed-by: Michael Stahl 
(cherry picked from commit 62cb3b8b8d6106c6aeb073b12d84973a107182ef)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164813
Reviewed-by: Caolán McNamara 

diff --git a/sw/source/core/docnode/ndtbl.cxx b/sw/source/core/docnode/ndtbl.cxx
index a7a2bee478da..d052ed7eda4b 100644
--- a/sw/source/core/docnode/ndtbl.cxx
+++ b/sw/source/core/docnode/ndtbl.cxx
@@ -888,6 +888,34 @@ const SwTable* SwDoc::TextToTable( const 
SwInsertTableOptions& rInsTableOpts,
 return 
 }
 
+static void lcl_RemoveBreaksTable(SwTableNode & rNode, SwTableFormat *const 
pTableFormat)
+{
+// delete old layout frames, new ones need to be created...
+rNode.DelFrames(nullptr);
+
+// remove PageBreaks/PageDesc/ColBreak
+SwFrameFormat & rFormat(*rNode.GetTable().GetFrameFormat());
+
+if (const SvxFormatBreakItem* pItem = rFormat.GetItemIfSet(RES_BREAK, 
false))
+{
+if (pTableFormat)
+{
+pTableFormat->SetFormatAttr(*pItem);
+}
+rFormat.ResetFormatAttr(RES_BREAK);
+}
+
+SwFormatPageDesc const*const 
pPageDescItem(rFormat.GetItemIfSet(RES_PAGEDESC, false));
+if (pPageDescItem && pPageDescItem->GetPageDesc())
+{
+if (pTableFormat)
+{
+pTableFormat->SetFormatAttr(*pPageDescItem);
+}
+rFormat.ResetFormatAttr(RES_PAGEDESC);
+}
+}
+
 static void lcl_RemoveBreaks(SwContentNode & rNode, SwTableFormat *const 
pTableFormat)
 {
 // delete old layout frames, new ones need to be created...
@@ -1386,7 +1414,13 @@ SwTableNode* SwNodes::TextToTable( const 
SwNodes::TableRanges_t & rTableNodes,
 for( nLines = 0; aNodeIndex <= rTableNodes.rbegin()->rbegin()->aEnd; 
++aNodeIndex,++nLines )
 {
 SwNode& rNode = aNodeIndex.GetNode();
-if( rNode.IsContentNode() )
+assert(!rNode.IsSectionNode()); // not possible in writerfilter import
+if (rNode.IsTableNode())
+{
+lcl_RemoveBreaksTable(static_cast(rNode),
+(0 == nLines) ? pTableFormat : nullptr);
+}
+else if (rNode.IsContentNode())
 {
 lcl_RemoveBreaks(static_cast(rNode),
 (0 == nLines) ? pTableFormat : nullptr);

core.git: Branch 'libreoffice-24-2' - 2 commits - ucb/source

[Michael Stahl (via logerrit)]

 ucb/source/ucp/webdav-curl/CurlSession.cxx |   32 +++--
 1 file changed, 13 insertions(+), 19 deletions(-)

New commits:
commit 84b5de0e000372e46d7243873859fc03e114bde8
Author: Michael Stahl 
AuthorDate: Thu Mar 14 15:47:28 2024 +0100
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 20:56:22 2024 +0100

ucb: webdav-curl: always set CURLOPT_NOBODY for HEAD

Otherwise there will be timeout that depends on when the server will
close the connection, which varies by server but can be several minutes;
getting a potential error document from the server for this one request
when logging is enabled is less important.

Change-Id: I505b014b148ba009c400d37d826c9edb8c3a6da2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164838
Tested-by: Jenkins
Reviewed-by: Michael Stahl 
(cherry picked from commit c8400f5acc36d2cf0c007260bdc94534a53bba90)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164822
Reviewed-by: Caolán McNamara 

diff --git a/ucb/source/ucp/webdav-curl/CurlSession.cxx 
b/ucb/source/ucp/webdav-curl/CurlSession.cxx
index 3b40d2c3082f..2f104d5388d7 100644
--- a/ucb/source/ucp/webdav-curl/CurlSession.cxx
+++ b/ucb/source/ucp/webdav-curl/CurlSession.cxx
@@ -166,15 +166,6 @@ struct CurlOption
 }
 };
 
-// NOBODY will prevent logging the response body in ProcessRequest() exception
-// handler, so only use it if logging is disabled
-const CurlOption g_NoBody{ CURLOPT_NOBODY,
-   sal_detail_log_report(SAL_DETAIL_LOG_LEVEL_INFO, 
"ucb.ucp.webdav.curl")
-   == SAL_DETAIL_LOG_ACTION_IGNORE
-   ? 1L
-   : 0L,
-   nullptr };
-
 /// combined guard class to ensure things are released in correct order,
 /// particularly in ProcessRequest() error handling
 class Guard
@@ -1829,7 +1820,11 @@ auto CurlSession::HEAD(OUString const& rURIReference, 
::std::vector co
 CurlUri const uri(CurlProcessor::URIReferenceToURI(*this, rURIReference));
 
 ::std::vector const options{
-g_NoBody, { CURLOPT_CUSTOMREQUEST, "HEAD", "CURLOPT_CUSTOMREQUEST" }
+// NOBODY will prevent logging the response body in ProcessRequest()
+// exception, but omitting it here results in a long timeout until the
+// server closes the connection, which is worse
+{ CURLOPT_NOBODY, 1L, nullptr },
+{ CURLOPT_CUSTOMREQUEST, "HEAD", "CURLOPT_CUSTOMREQUEST" }
 };
 
 ::std::pair<::std::vector const&, DAVResource&> const 
headers(rHeaderNames,
commit 372ee9e4c24e628ce73ec0c6a6fee91abd2e6b94
Author: Michael Stahl 
AuthorDate: Fri Mar 8 11:20:45 2024 +0100
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 20:56:14 2024 +0100

ucb: webdav-curl: only set CURLOPT_NOBODY for HEAD

Some testing with Apache httpd+mod_dav reveals that it usually sends a
body with a 401 status, which causes the CURLE_WEIRD_SERVER_REPLY error
code from curl.

So we should either ignore this error in case there's a HTTP status too,
or stop using CURLOPT_NOBODY.

The latter seems to have no downside, except for HEAD requests, where
strangely the server keeps the connection open and curl waits for 5
seconds for no body to arrive, blocking the UI, so continue to use
CURLOPT_NOBODY for HEAD.

The other methods don't seem to block.

It turns out that the SAL_LOG-dependent setting of g_NoBody turned HEAD
into GET anyway if logging is enabled, so explicitly set the method.

Change-Id: Ibe2eef8e7a827d4e356ba37c4b56bee0be3b9c13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164569
Tested-by: Jenkins
Reviewed-by: Michael Stahl 
(cherry picked from commit e0259d4c0951c4dd77c74d08b9d905728d4c8dfd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164507
Reviewed-by: Caolán McNamara 

diff --git a/ucb/source/ucp/webdav-curl/CurlSession.cxx 
b/ucb/source/ucp/webdav-curl/CurlSession.cxx
index 18bd7ab61e2b..3b40d2c3082f 100644
--- a/ucb/source/ucp/webdav-curl/CurlSession.cxx
+++ b/ucb/source/ucp/webdav-curl/CurlSession.cxx
@@ -1828,7 +1828,9 @@ auto CurlSession::HEAD(OUString const& rURIReference, 
::std::vector co
 
 CurlUri const uri(CurlProcessor::URIReferenceToURI(*this, rURIReference));
 
-::std::vector const options{ g_NoBody };
+::std::vector const options{
+g_NoBody, { CURLOPT_CUSTOMREQUEST, "HEAD", "CURLOPT_CUSTOMREQUEST" }
+};
 
 ::std::pair<::std::vector const&, DAVResource&> const 
headers(rHeaderNames,
 
io_rResource);
@@ -2063,9 +2065,8 @@ auto CurlSession::MKCOL(OUString const& rURIReference, 
DAVRequestEnvironment con
 
 CurlUri const uri(CurlProcessor::URIReferenceToURI(*this, rURIReference));
 
-::std::vector const options{
-g_NoBody, { CURLOPT_CUSTOMREQUEST, 

core.git: Branch 'libreoffice-24-2' - ucb/source

[Michael Stahl (via logerrit)]

 ucb/source/ucp/webdav-curl/CurlSession.cxx |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

New commits:
commit 7e5891a327889be3a052594efd7862ed5be13606
Author: Michael Stahl 
AuthorDate: Thu Mar 7 20:10:48 2024 +0100
Commit: Caolán McNamara 
CommitDate: Tue Mar 19 20:55:19 2024 +0100

ucb: webdav-curl: don't set CURLOPT_NOBODY for OPTIONS

The problem is that if the server does send a body, then curl returns
CURLE_WEIRD_SERVER_REPLY error code, which is translated to
DAVException; this looks unnecessary now because write_callback
will just return if there's no stream to write to anyway.

Change-Id: Iddaee9778ac7bbd538b64584f822f65ab0e395c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164550
Tested-by: Jenkins
Reviewed-by: Michael Stahl 
(cherry picked from commit 980ca3953084560806cd980d2ec16951d9e30c2b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164501
Reviewed-by: Caolán McNamara 

diff --git a/ucb/source/ucp/webdav-curl/CurlSession.cxx 
b/ucb/source/ucp/webdav-curl/CurlSession.cxx
index a54e9d1addfb..18bd7ab61e2b 100644
--- a/ucb/source/ucp/webdav-curl/CurlSession.cxx
+++ b/ucb/source/ucp/webdav-curl/CurlSession.cxx
@@ -1519,9 +1519,8 @@ auto CurlSession::OPTIONS(OUString const& rURIReference,
 DAVResource result;
 ::std::pair<::std::vector const&, DAVResource&> const 
headers(headerNames, result);
 
-::std::vector const options{
-g_NoBody, { CURLOPT_CUSTOMREQUEST, "OPTIONS", "CURLOPT_CUSTOMREQUEST" }
-};
+::std::vector const options{ { CURLOPT_CUSTOMREQUEST, 
"OPTIONS",
+   "CURLOPT_CUSTOMREQUEST" } };
 
 CurlProcessor::ProcessRequest(*this, uri, "OPTIONS", options, , 
nullptr, nullptr, nullptr,
   );

[Bug 160273] Writing direction with rotated text in cell is inconsistent

[bugzilla-daemon]

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

--- Comment #3 from Csábi Frigyes  ---
(In reply to V Stuart Foote from comment #2)
> You are mixing Table/Table Cell *text orientation* up with Character *text
> rotation*.
> 
> Different attributes!
> 
> Table layout BTLR is different to TBRL -- the 90 left rotation happens to
> match the layout of the BTLR orientation.  Simply put, the 270 right
> rotation does not match layout of TBRL orientation.
> 
> IMHO => NAB

Hmm, yes you are right, the 270 rotation is still left to right. My problem is,
that it is very hard to read. And if i try to change it to right to left (Ctrl
+ Shift + D in Windows) it messes up the text. Would you consider this as a
bug?

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

[Bug 45617] Make Impress Master Slides copyable

[bugzilla-daemon]

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

Ahmed Hamed  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

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

[Bug 45617] Make Impress Master Slides copyable

[bugzilla-daemon]

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

Ahmed Hamed  changed:

   What|Removed |Added

   Assignee|ahmedhamed3...@gmail.com|libreoffice-b...@lists.free
   ||desktop.org

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

[Bug 160172] A big ODT document still takes too long to open or save

[bugzilla-daemon]

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

--- Comment #6 from David García  ---
Thanks for your comment, Noel.

I've immediately tested LO 24.8.0.0.alpha 0 and, as you said, the problem seems
to be fixed:

- Time to open the file: 7 seconds.
- Time to save the file: 15 seconds.

This is great news, but I wonder if these changes could be backported to the
24.2 branch.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0c9f650136277b708912a86a6867ec91c8b384a5
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded

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

core.git: Branch 'libreoffice-24-2' - sc/source

[Caolán McNamara (via logerrit)]

 sc/source/filter/html/htmlpars.cxx |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

New commits:
commit b25a88677ce2d713b0f454ef2d4cf5a202a005a7
Author: Caolán McNamara 
AuthorDate: Mon Mar 18 17:06:33 2024 +
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:53:25 2024 +0100

calc html filter ScDocShell* deref for document properties

ScDocShell is optional in other parts of this filter

Change-Id: If219cfa6ef737a9695b85bf6db5d45e9750a7ed9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164974
Tested-by: Jenkins
Reviewed-by: Caolán McNamara 
(cherry picked from commit 1dc579ae9cd7fcf504016ef510a9484173c9392d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164994
Reviewed-by: Xisco Fauli 

diff --git a/sc/source/filter/html/htmlpars.cxx 
b/sc/source/filter/html/htmlpars.cxx
index c9d53d93bed7..e563ff60b8ea 100644
--- a/sc/source/filter/html/htmlpars.cxx
+++ b/sc/source/filter/html/htmlpars.cxx
@@ -1595,13 +1595,14 @@ void ScHTMLLayoutParser::ProcToken( HtmlImportInfo* 
pInfo )
 switch ( pInfo->nToken )
 {
 case HtmlTokenId::META:
+if (ScDocShell* pDocSh = mpDoc->GetDocumentShell())
 {
 HTMLParser* pParser = static_cast(pInfo->pParser);
 uno::Reference xDPS(
-
static_cast(mpDoc->GetDocumentShell()->GetModel()), 
uno::UNO_QUERY_THROW);
+static_cast(pDocSh->GetModel()), 
uno::UNO_QUERY_THROW);
 pParser->ParseMetaOptions(
 xDPS->getDocumentProperties(),
-mpDoc->GetDocumentShell()->GetHeaderAttributes() );
+pDocSh->GetHeaderAttributes() );
 }
 break;
 case HtmlTokenId::TITLE_ON:
@@ -1612,12 +1613,13 @@ void ScHTMLLayoutParser::ProcToken( HtmlImportInfo* 
pInfo )
 break;
 case HtmlTokenId::TITLE_OFF:
 {
-if ( bInTitle && !aString.isEmpty() )
+ScDocShell* pDocSh = mpDoc->GetDocumentShell();
+if ( bInTitle && !aString.isEmpty() && pDocSh )
 {
 // Remove blanks from line breaks
 aString = aString.trim();
 uno::Reference xDPS(
-
static_cast(mpDoc->GetDocumentShell()->GetModel()),
+static_cast(pDocSh->GetModel()),
 uno::UNO_QUERY_THROW);
 xDPS->getDocumentProperties()->setTitle(aString);
 }

core.git: Branch 'libreoffice-24-2-2' - sw/source

[Michael Stahl (via logerrit)]

 sw/source/core/layout/tabfrm.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 6a9feb0bba19bcff87e0e1a16fcd03ad3a390dfa
Author: Michael Stahl 
AuthorDate: Tue Mar 12 16:21:57 2024 +0100
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:51:46 2024 +0100

tdf#157241 sw: layout: inconsistent conditions in lcl_RecalcSplitLine()

A mistake, when checking before the condition is "if (pTab == )"
but when checking after it is "if (pTab)" - the latter is correct as the
former is checked *inside* the block, after resolving to top-level table.

This caused erroneously setting rIsFootnoteGrowth = true in
SwTabFrame::MakeAll() of tab 939 in the bugdoc, when in fact the footnote
container shrunk from 5 to 2 footnotes.

(regression from commit c303981cfd95ce1c3881366023d5495ae2edce97)

Change-Id: Ib4cad9fef0e500ebe7a3636c2371a4108b32fb5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164717
Tested-by: Jenkins
Reviewed-by: Michael Stahl 
(cherry picked from commit 7d3b439de357c8e97c0a73f6f63e67ec980e432d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164733
Reviewed-by: Xisco Fauli 
(cherry picked from commit 3ea0c848b490f5b6f5f3860a9036ce25754a1f17)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164740
Reviewed-by: Adolfo Jayme Barrientos 
Reviewed-by: Michael Weghorn 
Tested-by: Xisco Fauli 

diff --git a/sw/source/core/layout/tabfrm.cxx b/sw/source/core/layout/tabfrm.cxx
index 8c49106364dc..c4a742c0373d 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -667,7 +667,7 @@ static bool lcl_RecalcSplitLine( SwRowFrame& rLastLine, 
SwRowFrame& rFollowLine,
 {
 SwContentFrame const*const pAnchor = pFootnote->GetRef();
 SwTabFrame const* pTab = pAnchor->FindTabFrame();
-if (pTab == )
+if (pTab)
 {
 while (pTab->GetUpper()->IsInTab())
 {

core.git: Branch 'libreoffice-24-2-2' - sw/source

[Julien Nabet (via logerrit)]

 sw/source/core/edit/edsect.cxx |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 545179ee711381b641dd6a34e46722353f2b2488
Author: Julien Nabet 
AuthorDate: Fri Mar 8 17:35:00 2024 +0100
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:51:18 2024 +0100

tdf#160095: fix crash when using ALT+RETURN twice

Change-Id: Idc4c84039115c8d88418246a17e281c26fb49b70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164592
Tested-by: Jenkins
Reviewed-by: Julien Nabet 
(cherry picked from commit 82e6236cd6ba6f45aa913a3be606e6b00f81fe07)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164614
Reviewed-by: Xisco Fauli 
(cherry picked from commit ad5bd68124f5cd63c1ac9f2b92b25d6a02ecfb97)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164624
Reviewed-by: Michael Stahl 
Reviewed-by: Michael Weghorn 
Tested-by: Xisco Fauli 

diff --git a/sw/source/core/edit/edsect.cxx b/sw/source/core/edit/edsect.cxx
index daaa7296e81e..070a37a90d2f 100644
--- a/sw/source/core/edit/edsect.cxx
+++ b/sw/source/core/edit/edsect.cxx
@@ -316,6 +316,9 @@ static const SwNode* lcl_SpecialInsertNode(const 
SwPosition* pCurrentPos)
 // find the table/section which is close
 if( pTableNode == nullptr )
 {
+if( pSectionNode == nullptr )
+return nullptr;
+
 pInnermostNode = pSectionNode;
 pSection = _cast(pSectionNode)->GetSection();
 }

core.git: Branch 'libreoffice-24-2-2' - include/svx sd/qa sd/source

[Sarper Akdemir (via logerrit)]

 include/svx/sdrmasterpagedescriptor.hxx  |3 +-
 include/svx/sdrpageuser.hxx  |3 +-
 include/svx/svdpage.hxx  |1 
 sd/qa/unit/export-tests-ooxml4.cxx   |   45 +++
 sd/source/filter/eppt/pptx-epptooxml.cxx |   38 ++
 5 files changed, 82 insertions(+), 8 deletions(-)

New commits:
commit aa371949ae72e84379ae811e469d9ec34bab6ec5
Author: Sarper Akdemir 
AuthorDate: Wed Mar 6 13:48:14 2024 +0300
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:50:59 2024 +0100

tdf#159931: pptx export: export each used slide layout for a master

attempts to fix the slideLayout reference related regression
from Idb6b88ebe87a83818d8eb27a1fa087652a002c0c.

To correctly export the all used slideLayout instances for a
given master, iterate through sdr::PageUsers of that master
and figure out all used layouts.

Change-Id: I0f58befac1ba4d5ec01aeedbb5f611c83683dcf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164468
Tested-by: Jenkins
Reviewed-by: Balazs Varga 
Reviewed-by: Sarper Akdemir 
(cherry picked from commit a35831becee3781daf8628c48944660d31d84d8b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164495
(cherry picked from commit ebd9530b458cbc37a7b2b1da077435f2b33081ba)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164629
Reviewed-by: Michael Stahl 
Reviewed-by: Michael Weghorn 
Tested-by: Xisco Fauli 
Reviewed-by: Xisco Fauli 

diff --git a/include/svx/sdrmasterpagedescriptor.hxx 
b/include/svx/sdrmasterpagedescriptor.hxx
index d7eac22a1b5c..9be1e663bcff 100644
--- a/include/svx/sdrmasterpagedescriptor.hxx
+++ b/include/svx/sdrmasterpagedescriptor.hxx
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 class SdrPageProperties;
@@ -30,7 +31,7 @@ namespace sdr::contact { class ViewContact; }
 
 namespace sdr
 {
-class MasterPageDescriptor final : public sdr::PageUser
+class SVXCORE_DLLPUBLIC MasterPageDescriptor final : public sdr::PageUser
 {
 private:
 SdrPage&maOwnerPage;
diff --git a/include/svx/sdrpageuser.hxx b/include/svx/sdrpageuser.hxx
index 8c31a2936c7e..5557b2729777 100644
--- a/include/svx/sdrpageuser.hxx
+++ b/include/svx/sdrpageuser.hxx
@@ -21,6 +21,7 @@
 #define INCLUDED_SVX_SDRPAGEUSER_HXX
 
 #include 
+#include 
 
 class SdrPage;
 
@@ -30,7 +31,7 @@ class SdrPage;
 
 namespace sdr
 {
-class PageUser
+class SVXCORE_DLLPUBLIC PageUser
 {
 public:
 // this method is called from the destructor of the referenced page.
diff --git a/include/svx/svdpage.hxx b/include/svx/svdpage.hxx
index c70a2f1f4a2d..cb1e7f9f0b20 100644
--- a/include/svx/svdpage.hxx
+++ b/include/svx/svdpage.hxx
@@ -405,6 +405,7 @@ private:
 public:
 void AddPageUser(sdr::PageUser& rNewUser);
 void RemovePageUser(sdr::PageUser& rOldUser);
+const sdr::PageUserVector& GetPageUsers() const { return maPageUsers; };
 
 // SdrModel access on SdrPage level
 SdrModel& getSdrModelFromSdrPage() const { return mrSdrModelFromSdrPage; }
diff --git a/sd/qa/unit/export-tests-ooxml4.cxx 
b/sd/qa/unit/export-tests-ooxml4.cxx
index c4c061c50d2d..06cc2805d64d 100644
--- a/sd/qa/unit/export-tests-ooxml4.cxx
+++ b/sd/qa/unit/export-tests-ooxml4.cxx
@@ -1095,6 +1095,51 @@ CPPUNIT_TEST_FIXTURE(SdOOXMLExportTest4, 
testTdf157740_slideMasters)
 assertXPath(pXmlDocContent, 
"/p:sldMaster/p:sldLayoutIdLst/p:sldLayoutId"_ostr, 1);
 }
 
+CPPUNIT_TEST_FIXTURE(SdOOXMLExportTest4, testTdf159931_slideLayouts)
+{
+createSdImpressDoc("odp/repeatBitmapMode.odp");
+save("Impress Office Open XML");
+
+xmlDocUniquePtr pXmlDocRels1 = 
parseExport("ppt/slides/_rels/slide1.xml.rels");
+xmlDocUniquePtr pXmlDocRels2 = 
parseExport("ppt/slides/_rels/slide2.xml.rels");
+
+assertXPath(
+pXmlDocRels1,
+
"(/rels:Relationships/rels:Relationship[@Type='http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout'])"_ostr);
+
+// the relative target e.g. "../slideLayouts/slideLayout2.xml"
+OUString sRelativeLayoutPath1 = getXPathContent(
+pXmlDocRels1,
+
"(/rels:Relationships/rels:Relationship[@Type='http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout'])/@Target"_ostr);
+
+assertXPath(
+pXmlDocRels2,
+
"(/rels:Relationships/rels:Relationship[@Type='http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout'])"_ostr);
+
+// the relative target e.g. "../slideLayouts/slideLayout1.xml"
+OUString sRelativeLayoutPath2 = getXPathContent(
+pXmlDocRels2,
+
"(/rels:Relationships/rels:Relationship[@Type='http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout'])/@Target"_ostr);
+
+uno::Reference xNameAccess
+= 

[Bug 160151] sm Visual mode Formula Editing not handling "newline" element

[bugzilla-daemon]

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

--- Comment #3 from Chris Kirkland  ---
Trying to use "newline" from the elements sidebar in an inserted formula in
Writer. "Newline" still not working in 24.2.2.1
Fresh install using Seperate Install GUI.
Windows 11 64-bit.

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

core.git: Branch 'libreoffice-7-6' - vcl/qa writerfilter/source

[Xisco Fauli (via logerrit)]

 vcl/qa/cppunit/pdfexport/data/tdf142133.docx  |binary
 vcl/qa/cppunit/pdfexport/pdfexport.cxx|   35 ++
 writerfilter/source/dmapper/DomainMapper_Impl.cxx |   23 --
 writerfilter/source/dmapper/DomainMapper_Impl.hxx |3 +
 4 files changed, 52 insertions(+), 9 deletions(-)

New commits:
commit 5f025f9bab12d0f08c23cca08d12c15cca95e9ed
Author: Xisco Fauli 
AuthorDate: Fri Mar 8 14:23:08 2024 +0100
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:48:11 2024 +0100

tdf#142133: partially revert 576611895e5

if 'Internet Link' character style doens't exist then
apply the hyperlink style
This also reverts 023285158bde72dcd73b965ce205cf8550e7a5e2
"tdf#128504 save DOCX as ODT: don't color not highlighted hyperlinks"
which is no longer necessary

Change-Id: Id100af5fddb10745af9d56c0ba75cb2366ecbe55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164576
Tested-by: Jenkins
Reviewed-by: Xisco Fauli 
(cherry picked from commit 03ca7031f3bf4c2a3e841b18c8f9e4046098)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164509
Reviewed-by: Stéphane Guillou 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164711

diff --git a/vcl/qa/cppunit/pdfexport/data/tdf142133.docx 
b/vcl/qa/cppunit/pdfexport/data/tdf142133.docx
new file mode 100644
index ..fa1e155b873e
Binary files /dev/null and b/vcl/qa/cppunit/pdfexport/data/tdf142133.docx differ
diff --git a/vcl/qa/cppunit/pdfexport/pdfexport.cxx 
b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
index 4113e160f1e7..d6ae5f527ab8 100644
--- a/vcl/qa/cppunit/pdfexport/pdfexport.cxx
+++ b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
@@ -2706,6 +2706,41 @@ CPPUNIT_TEST_FIXTURE(PdfExportTest, testTdf157816Link)
 CPPUNIT_ASSERT_EQUAL(static_cast(4), 
pAnnots->GetElements().size());
 }
 
+CPPUNIT_TEST_FIXTURE(PdfExportTest, testTdf142133)
+{
+vcl::filter::PDFDocument aDocument;
+load(u"tdf142133.docx", aDocument);
+
+// The document has one page.
+std::vector aPages = aDocument.GetPages();
+CPPUNIT_ASSERT_EQUAL(static_cast(1), aPages.size());
+
+auto pAnnots = 
dynamic_cast(aPages[0]->Lookup("Annots"));
+CPPUNIT_ASSERT(pAnnots);
+
+// There should be one annotation
+CPPUNIT_ASSERT_EQUAL(static_cast(1), 
pAnnots->GetElements().size());
+auto pAnnotReference
+= 
dynamic_cast(pAnnots->GetElements()[0]);
+CPPUNIT_ASSERT(pAnnotReference);
+vcl::filter::PDFObjectElement* pAnnot = pAnnotReference->LookupObject();
+CPPUNIT_ASSERT(pAnnot);
+// We're expecting something like /Type /Annot /A << /Type /Action /S /URI 
/URI (path)
+CPPUNIT_ASSERT_EQUAL(
+OString("Annot"),
+
static_cast(pAnnot->Lookup("Type"))->GetValue());
+CPPUNIT_ASSERT_EQUAL(
+OString("Link"),
+
static_cast(pAnnot->Lookup("Subtype"))->GetValue());
+auto pAction = 
dynamic_cast(pAnnot->Lookup("A"));
+CPPUNIT_ASSERT(pAction);
+auto pURIElem
+= 
dynamic_cast(pAction->LookupElement("URI"));
+CPPUNIT_ASSERT(pURIElem);
+// Check it matches
+CPPUNIT_ASSERT_EQUAL(OString("https://google.com/;), pURIElem->GetValue());
+}
+
 CPPUNIT_TEST_FIXTURE(PdfExportTest, testTdf142806)
 {
 aMediaDescriptor["FilterName"] <<= OUString("writer_pdf_Export");
diff --git a/writerfilter/source/dmapper/DomainMapper_Impl.cxx 
b/writerfilter/source/dmapper/DomainMapper_Impl.cxx
index bbdbb117556b..8997fc72637d 100644
--- a/writerfilter/source/dmapper/DomainMapper_Impl.cxx
+++ b/writerfilter/source/dmapper/DomainMapper_Impl.cxx
@@ -3245,6 +3245,15 @@ void DomainMapper_Impl::applyToggleAttributes(const 
PropertyMapPtr& pPropertyMap
 }
 else
 {
+if (IsOpenField() && GetTopFieldContext()->GetFieldId() == 
FIELD_HYPERLINK)
+{
+// It is content of hyperlink field. We need to create and 
remember
+// character style for later applying to hyperlink
+PropertyValueVector_t aProps = 
comphelper::sequenceToContainer< PropertyValueVector_t 
>(GetTopContext()->GetPropertyValues());
+OUString sHyperlinkStyleName = 
GetStyleSheetTable()->getOrCreateCharStyle(aProps, /*bAlwaysCreate=*/false);
+
GetTopFieldContext()->SetHyperlinkStyle(sHyperlinkStyleName);
+}
+
 #if !defined(MACOSX) // TODO: check layout differences and support all 
platforms, if needed
 sal_Int32 nPos = 0;
 OUString sFontName;
@@ -8460,25 +8469,21 @@ void DomainMapper_Impl::PopFieldContext()
 
xCrsrProperties->setPropertyValue("VisitedCharStyleName",uno::Any(sDisplayName));
 
xCrsrProperties->setPropertyValue("UnvisitedCharStyleName",uno::Any(sDisplayName));
 }
-

core.git: Branch 'libreoffice-7-6' - chart2/source

[Julien Nabet (via logerrit)]

 chart2/source/controller/chartapiwrapper/TitleWrapper.cxx |7 +++
 1 file changed, 7 insertions(+)

New commits:
commit 2c11aa68477e957fb298605baca08ec48acffcd7
Author: Julien Nabet 
AuthorDate: Sun Mar 17 09:31:22 2024 +0100
Commit: Xisco Fauli 
CommitDate: Tue Mar 19 18:47:41 2024 +0100

tdf#160225, related tdf#92768: hide axis title not taken into account 
when...

duplicating sheet or when saving a file and reopen it.

When creating a title for an axis, "createTitle" is called.
Before tdf#92768 "support hiding title objects", when unchecking "axis 
title" in sidebar,
the title was removed (via "removeTitle")
But since tdf#92768, "hideTitle" is called instead.

The pb is "Visible" attribute wasn't registered in 
StaticTitleWrapperPropertyArray.
So when duplicating sheet after having created a title and hidden it,
when duplicating sheet, the new sheet had the title visible.
In the same way if, after having created a title and hidden it,
you save the file and reopen it, the title is displayed.

Change-Id: I980505ec02906e673dd60a60e4d9837928bf8876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164938
Reviewed-by: Noel Grandin 
Tested-by: Jenkins
Reviewed-by: Julien Nabet 
(cherry picked from commit 6aac5b2c96b42e8204a10def52df1b85ebebeb46)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164878
(cherry picked from commit b97348107831c5699e679dc8d2c36d626122ae0c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164995
Reviewed-by: Xisco Fauli 

diff --git a/chart2/source/controller/chartapiwrapper/TitleWrapper.cxx 
b/chart2/source/controller/chartapiwrapper/TitleWrapper.cxx
index 75d6c9e98f1f..9c802462ff09 100644
--- a/chart2/source/controller/chartapiwrapper/TitleWrapper.cxx
+++ b/chart2/source/controller/chartapiwrapper/TitleWrapper.cxx
@@ -127,6 +127,7 @@ namespace
 enum
 {
 PROP_TITLE_STRING,
+PROP_TITLE_VISIBLE,
 PROP_TITLE_TEXT_ROTATION,
 PROP_TITLE_TEXT_STACKED
 };
@@ -140,6 +141,12 @@ void lcl_AddPropertiesToVector(
   beans::PropertyAttribute::BOUND
   | beans::PropertyAttribute::MAYBEVOID );
 
+rOutProperties.emplace_back( "Visible",
+  PROP_TITLE_VISIBLE,
+  cppu::UnoType::get(),
+  beans::PropertyAttribute::BOUND
+  | beans::PropertyAttribute::MAYBEVOID );
+
 rOutProperties.emplace_back( "TextRotation",
   PROP_TITLE_TEXT_ROTATION,
   cppu::UnoType::get(),

[Bug 160033] soffice builds of pdf files are unreproducible

[bugzilla-daemon]

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

--- Comment #2 from Rene Engelhard  ---
But odt files stay the same (unless changed and re-saved of course) so are per
definition reproducible.

pdf files which are (in this and other cases in Debian) are rebuilt every time
on every package build from a .doc/.od? differ each time.

(Or, if one wants to go that route, the "source file" (od?) stays the same
anyway and the "binary" (pdf) changes. That's a possible analogy)

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

core.git: Branch 'libreoffice-24-2-2' - sal/osl

[Stephan Bergmann (via logerrit)]

 sal/osl/unx/file.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit c84f5898db8083fdc631a8871d0fef5eb4dd4197
Author: Stephan Bergmann 
AuthorDate: Fri Mar 8 08:38:44 2024 +0100
Commit: Adolfo Jayme Barrientos 
CommitDate: Tue Mar 19 18:40:40 2024 +0100

Blind fix for Linux 32-bit builds

...which, according to
 
"32
bit build failure (smb, narrowing)", started to fail with

> /<>/sal/osl/unx/file.cxx: In function ‘void 
osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’:
> /<>/sal/osl/unx/file.cxx:71:26: error: narrowing conversion 
of ‘4283649346’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
> 71 | #define CIFS_SUPER_MAGIC 0xFF534D42
>|  ^~
> /<>/sal/osl/unx/file.cxx:795:14: note: in expansion of macro 
‘CIFS_SUPER_MAGIC’
>795 | case CIFS_SUPER_MAGIC:
>|  ^~~~

etc.  My Fedora 39 "Linux man-pages 6.05" statfs(2) man page explains about 
the
struct statfs f_type field of __fsword_t type:  "The __fsword_t type used 
for
various fields in the statfs structure definition is a glibc internal type, 
not
intended for public use.  This leaves the programmer in a bit of a conundrum
when trying to copy or compare these fields to local variables in a program.
Using unsigned int for such variables suffices on most systems."  But the
underlying __FSWORD_T_TYPE looks like it is actually defined as a signed 
type in
/usr/include/bits/typesizes.h.

Change-Id: Ida3ae84031c4e48b0d6e69d76b66b4e4facfa1ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164561
Tested-by: René Engelhard 
Reviewed-by: René Engelhard 
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit 0f5dfaebd61b9cabbe9762865563c2296ebb0112)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164504
(cherry picked from commit 25c2c7abd2ce1d3067e2b8f95d0729f462a5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164611
Reviewed-by: Xisco Fauli 
Reviewed-by: Michael Weghorn 
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index 0ca8822016e1..ee7412dd1041 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -67,9 +67,9 @@
 #ifdef LINUX
 #include 
 // As documented by the kernel
-#define SMB_SUPER_MAGIC  0x517B
-#define CIFS_SUPER_MAGIC 0xFF534D42
-#define SMB2_SUPER_MAGIC 0xFE534D42
+#define SMB_SUPER_MAGIC  static_cast<__fsword_t>(0x517B)
+#define CIFS_SUPER_MAGIC static_cast<__fsword_t>(0xFF534D42)
+#define SMB2_SUPER_MAGIC static_cast<__fsword_t>(0xFE534D42)
 #endif
 
 namespace {

core.git: sw/qa

[Stephan Bergmann (via logerrit)]

 sw/qa/extras/uiwriter/uiwriter7.cxx |1 -
 1 file changed, 1 deletion(-)

New commits:
commit 6dd848baf87cbe48e2b8198104532d5eaf8b8ef2
Author: Stephan Bergmann 
AuthorDate: Tue Mar 19 14:31:04 2024 +0100
Commit: Stephan Bergmann 
CommitDate: Tue Mar 19 18:39:52 2024 +0100

-Werror,-Wunused-variable

(presumably a copy/paste leftover in test code newly introduced in
8b58007fc5a619012b58a1f8d8731a753bc1c40d "tdf#147583 sw find: fix backwards
search for emptyPara/endOfPara")

Change-Id: I50074a8c633a38818027156f915731eda05c49e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165030
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 

diff --git a/sw/qa/extras/uiwriter/uiwriter7.cxx 
b/sw/qa/extras/uiwriter/uiwriter7.cxx
index 898ed6dcd1b5..bf9a4ee1bd1c 100644
--- a/sw/qa/extras/uiwriter/uiwriter7.cxx
+++ b/sw/qa/extras/uiwriter/uiwriter7.cxx
@@ -363,7 +363,6 @@ CPPUNIT_TEST_FIXTURE(SwUiWriterTest7, 
testTdf147583_backwardSearch)
 createSwDoc("tdf147583_backwardSearch.odt");
 uno::Reference xSearch(mxComponent, uno::UNO_QUERY);
 uno::Reference xSearchDes = 
xSearch->createSearchDescriptor();
-uno::Reference xProp(xSearchDes, uno::UNO_QUERY);
 
 uno::Reference xIndex;
 const sal_Int32 nParas = getParagraphs();

[Bug 160184] allow to "Encrypt with GPG key" on save using public keys with unknown Ownertrust

[bugzilla-daemon]

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

--- Comment #10 from Patrick Luby (volunteer)  ---
(In reply to steve from comment #9)
> Command line gpg does ask the user how to proceed when the key is untrusted.
> 
> I am fine either way for LO, leaning towards allowing encryption without a
> warning. Current behavior certainly is not intended.

Maybe I can mimic the gpg command line behavior by using the existing code
(i.e. with the strictest trust model) and then, if it fails with this specific
error, I modify the code to display a "Yes/No" dialog that asks "The public key
is untrusted. Do you still want to encrypt with this key?". If yes, then the
code retries encrypting with either "tofu+pgp" or "always" as the trust model.

I am a bit busy this week, but if that seems like a reasonable approach, I'll
see if I can implement it when I have some spare time.

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

[Bug 160278] XTextRange.setString("휇") or any other 32-bit Unicode character breaks the range

[bugzilla-daemon]

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

--- Comment #4 from Mike Kaganski  ---
(In reply to Adomas Venčkauskas from comment #3)
> If you want me to look into this some more or produce a better test case

Yes please - the whole code + a text document, if needed. Thanks.

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