[Libreoffice-bugs] [Bug 125797] Sidebar: keyboard navigation does not skip over disabled tabs

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125797

Jim Raykowski  changed:

   What|Removed |Added

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

--- Comment #5 from Jim Raykowski  ---
Since this has been waiting to be fixed for a few years now and I've recently
been poking around this part of the code again, and the Managed Changes tab is
not disabled in read-only mode, I nominate myself to fix it :-)

Here is my proposed patch:
https://gerrit.libreoffice.org/c/core/+/155442

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

[Libreoffice-bugs] [Bug 156657] Exposing all Calc cells in accessibility tree is incompatible with AtspiCollection

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156657

Michael Weghorn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDINFO
 Ever confirmed|0   |1
 CC||cwendl...@hypra.fr,
   ||m.wegh...@posteo.de

--- Comment #2 from Michael Weghorn  ---
(In reply to Joanmarie Diggs from comment #0)
> Additional Info:
> I filed https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138 to ask
> Atspi to not descend ginormous tables.
> 
> As you will see in a later comment, I also suggested that Calc should
> consider doing what web app authors with giant grids do, namely only include
> a subset of the conceptual table in the DOM and use ARIA properties to
> expose stuff ATs should report to end users.
I'm not experienced with what web authors do, so have a few questions:

Are there any further information/best-practices on how that should work, i.e.
what you'd expect Calc to report, etc.?

I've found
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/table_role
but that doesn't really give too many details yet.

It has this example:

> The above is part of a table. While the full table has 81 entries, as 
> indicated
> by the aria-rowcount property, only four are currently visible. The columns 
> are
> sortable, but not currently sorted, as indicated by the aria-sort property on
> the column headers.
Does that mean that only what's visible on screen should be exposed?
IIRC, Colomban (CC'ed) mentioned that generally, documents should not only
expose what's on screen and e.g. tdf#96492 also suggests that off-screen
paragraphs in Writer should be part of the a11y tree.
Would we run into a similar problem with Writer when exposing all off-screen
pages/paragraphs in the a11y tree as well, e.g. if somebody opens a 1000 page
document with thousands of paragraphs?

>From what I have seen, the current handling of tables in LO wrt a11y is that
all cells are treated as children and the corresponding child index is used in
many places (for calculating row/col index,...), so changing that would
probably be a larger change.

Without knowing much about how this is handled elsewhere, limiting what
children to look into (iterate over?) on the client side (as the commit in
https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138 does) seems like a
good option to me, at least in the short run. (In particular for the status bar
example given here, descending into any children of objects with document roles
would seem unnecessary.)

I'm thankful for further input on how to address this in practice.

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

[Libreoffice-bugs] [Bug 156532] UI: Slide panel sizes changes width when applying a template style

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156532

Aaron  changed:

   What|Removed |Added

 CC||aaronth...@gmail.com

--- Comment #2 from Aaron  ---
Thank you for reporting the bug. I can not reproduce the bug in

Version: 7.5.5.2 (X86_64) / LibreOffice Community
Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: en-US
Calc: threaded

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

[Libreoffice-bugs] [Bug 156451] Search updates

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156451

Aaron  changed:

   What|Removed |Added

 CC||aaronth...@gmail.com
 Status|UNCONFIRMED |NEEDINFO
 Ever confirmed|0   |1

--- Comment #1 from Aaron  ---
Thank you for reporting the bug. 
Unfortunately without clear steps to reproduce it, we cannot track down the
origin of the problem. 
Please provide a clearer set of step-by-step instructions on how to reproduce
the problem.
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' once the requested information is provided.

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

[Libreoffice-bugs] [Bug 156418] Test failure in 7.6.0.1

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156418

QA Administrators  changed:

   What|Removed |Added

 Whiteboard| QA:needsComment|

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

[Libreoffice-bugs] [Bug 156442] Insert "Symbol" controller seems to be broken in master

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156442

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Libreoffice-bugs] [Bug 156438] Apply heuristic for choosing visible language group tab when opening dialog

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156438

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Libreoffice-bugs] [Bug 156451] Search updates

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156451

QA Administrators  changed:

   What|Removed |Added

 Whiteboard|| QA:needsComment

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

[Libreoffice-bugs] [Bug 152497] the automatic save option of writer does not work

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152497

QA Administrators  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 152926] Change in Font Size changes DISPLAYED Font itself completely!

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152926

QA Administrators  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 152926] Change in Font Size changes DISPLAYED Font itself completely!

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152926

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

Please read this message in its entirety before proceeding.

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

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

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

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

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

e) Read all comments and provide any requested information

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

a) respond via email 

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

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp

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

[Libreoffice-bugs] [Bug 152836] Sort date

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152836

--- Comment #4 from QA Administrators  ---
Dear ibuy1261,

Please read this message in its entirety before proceeding.

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

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

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

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

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

e) Read all comments and provide any requested information

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

a) respond via email 

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

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp

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

[Libreoffice-bugs] [Bug 152836] Sort date

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152836

QA Administrators  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 152497] the automatic save option of writer does not work

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152497

--- Comment #7 from QA Administrators  ---
Dear ksso,

Please read this message in its entirety before proceeding.

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

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

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

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

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

e) Read all comments and provide any requested information

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

a) respond via email 

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

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp

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

[Libreoffice-bugs] [Bug 143748] Redo of pattern fill to a sphere isn't working

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=143748

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

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

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

If you have time, please do the following:

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

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

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

Please DO NOT

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


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

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


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

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

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Libreoffice-bugs] [Bug 134015] LibreOffice Write crashes when I open docx containing tables exported by Cafetran Espresso ( with languagetool installed )

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=134015

--- Comment #10 from QA Administrators  ---
Dear Nicolas Gambardella,

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

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

If you have time, please do the following:

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

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

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

Please DO NOT

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


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

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


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

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

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Libreoffice-bugs] [Bug 137664] Can't change slide.Background.FillBitmapMode with Macro (Basic or python PyUno)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=137664

--- Comment #6 from QA Administrators  ---
Dear Pablo,

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

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

If you have time, please do the following:

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

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

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

Please DO NOT

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


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

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


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

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

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Libreoffice-bugs] [Bug 128277] Slow response when typing inside a textbox containing a large amount of text without OpenGL

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=128277

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

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

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

If you have time, please do the following:

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

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

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

Please DO NOT

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


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

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


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

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

Warm Regards,
QA Team

MassPing-UntouchedBug

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

[Libreoffice-bugs] [Bug 156662] New: Always using direct connection to api.languagetool.org

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156662

Bug ID: 156662
   Summary: Always using direct connection to api.languagetool.org
   Product: LibreOffice
   Version: 7.5.5.2 release
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: nor...@sainet.or.jp

api.languagetool.org is always using direct connection even if Proxy was set
and not use LanguageTools.

Option | Language Setting | LanguageTools Server | [ ] Enable LanguageTools
Option | Internet | Proxy | Proxy Server [Manual]
  (Once changed to [None] or [Manual], you can not set to [System] at
ver.7.5.5.2)

If api.languagetool.org to 127.0.0.1 by HOSTS file, it takes few seconds to
open Calc Workbook with contains one Line shape.

If BaseURL to invalid (https://api.languagetool.org/v2 to
https://DISABLED-api.languagetool.org/v2), opens fine.

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

[Libreoffice-bugs] [Bug 156621] In 7.6 rc the style "Block Quotation" is wrongly translated in Dutch (regression)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156621

--- Comment #4 from Cor Blom  ---
Checking progress I saw that there was a comment made about my suggestion what
the motivation is. I could not find how to respond to that, but reference to
this bug would be the answer. The Dutch translation is wrong. I don't even
understand what the meaning of the current translation is.

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

[Libreoffice-bugs] [Bug 145606] feature request: be able to set "always recover and always finish"

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=145606

Justin L  changed:

   What|Removed |Added

 CC||jl...@mail.com
Version|7.2.2.2 release |unspecified

--- Comment #4 from Justin L  ---
In my opinion, this is now fixed as much as it should be.

The same recovery dialog is used for 3 different kinds of recovery. SessionSave
could arguably restore without requiring a "start" button press. However,
EmergencySave (soft error recovery) and AutoRecovery (hard error recovery) both
deal with buggy situations, and thus I don't think that recovery should begin
without the user knowing or being informed.

A single click "start recovery" is not very difficult or time consuming, so I
have no intention of changing that - not even for SessionSave.

I agree that if everything is completely successful, that there is no need for
the "finish" button - the patch removes that. However, if there is any other
status I think the dialog should continue to display that to the user and wait
for a "finish" command.

So I consider this bug fixed, but I'll leave it open since the patch doesn't do
everything that was requested.

P.S. Bug 57414 should have reduced the number of times that AutoRecovery has
documents that it asks to recover.

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

[Libreoffice-bugs] [Bug 112970] [META] Document recovery bugs and enhancements

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=112970
Bug 112970 depends on bug 57414, which changed state.

Bug 57414 Summary: File Recovery: Don't save read-only and empty files for 
recovery
https://bugs.documentfoundation.org/show_bug.cgi?id=57414

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 77999] [META] Autosave/Autorecovery/Backup copy issues

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=77999
Bug 77999 depends on bug 57414, which changed state.

Bug 57414 Summary: File Recovery: Don't save read-only and empty files for 
recovery
https://bugs.documentfoundation.org/show_bug.cgi?id=57414

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 77999] [META] Autosave/Autorecovery/Backup copy issues

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=77999
Bug 77999 depends on bug 144512, which changed state.

Bug 144512 Summary: Please make timing of auto-save a per-document action
https://bugs.documentfoundation.org/show_bug.cgi?id=144512

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Libreoffice-bugs] [Bug 144512] Please make timing of auto-save a per-document action

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=144512

Justin L  changed:

   What|Removed |Added

   Assignee|libreoffice-b...@lists.free |mikekagan...@hotmail.com
   |desktop.org |

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

Week #9 report - GSoC 2023 - APNG support

2023-08-07 Thread Paris Oplopoios
Hello!

This week I pushed my APNG support patch along with a unit test. I also
found a regression caused by a different patch (not mine) on master and
opened a bug report for it.

Thanks!


[Libreoffice-bugs] [Bug 156646] When using fonts other than pure English fonts, the font height appears to be an unintended height

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156646

--- Comment #1 from LeroyG  ---
ask.libreoffice related question:
https://ask.libreoffice.org/t/there-is-no-margin-above-below-a-specific-font-or-it-is-expressed-narrowly/94266

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

[Libreoffice-commits] core.git: connectivity/source

2023-08-07 Thread jucasaca (via logerrit)
 connectivity/source/parse/sqlbison.y |   21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

New commits:
commit 42364fbfafaa95773c073cc080142b64ec1786fb
Author: jucasaca 
AuthorDate: Fri Jul 28 19:20:14 2023 +0200
Commit: Julien Nabet 
CommitDate: Mon Aug 7 23:38:50 2023 +0200

tdf#104918 Add Firebird's DATEDIFF syntax to the sql parser

Add one of the Firebird's DATEDIFF syntax to the parser so now it is 
possible to execute DATEDIFF(unit, datetime, datetime) in the
Base Query designer and don't need to execute it in SQL direct anymore

Change-Id: I0514542785c47a2a4693cba26de1815c96ee1b9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155027
Tested-by: Julien Nabet 
Reviewed-by: Julien Nabet 

diff --git a/connectivity/source/parse/sqlbison.y 
b/connectivity/source/parse/sqlbison.y
index eef20bd56b4a..fe3b32b79ef6 100644
--- a/connectivity/source/parse/sqlbison.y
+++ b/connectivity/source/parse/sqlbison.y
@@ -218,7 +218,7 @@ using namespace connectivity;
 %type  like_predicate opt_escape test_for_null 
null_predicate_part_2 in_predicate in_predicate_part_2 
character_like_predicate_part_2 other_like_predicate_part_2
 %type  all_or_any_predicate any_all_some existence_test subquery 
quantified_comparison_predicate_part_2
 %type  scalar_exp_commalist parameter_ref literal 
parenthesized_boolean_value_expression
-%type  column_ref data_type column cursor parameter range_variable 
user /*like_check*/
+%type  column_ref data_type column cursor parameter range_variable 
user /*like_check*/ datetime_unit
 /* new rules at OJ */
 %type  derived_column as_clause table_name num_primary term 
num_value_exp
 %type  value_exp_primary num_value_fct unsigned_value_spec 
cast_spec set_fct_spec  scalar_subquery
@@ -2966,6 +2966,18 @@ non_second_datetime_field:
|   SQL_TOKEN_MINUTE
|   SQL_TOKEN_MILLISECOND
;
+
+datetime_unit:
+   SQL_TOKEN_YEAR
+   |   SQL_TOKEN_MONTH
+   |   SQL_TOKEN_WEEK
+   |   SQL_TOKEN_DAY
+   |   SQL_TOKEN_HOUR
+   |   SQL_TOKEN_MINUTE
+   |   SQL_TOKEN_SECOND
+   |   SQL_TOKEN_MILLISECOND
+   ;
+
 start_field:
non_second_datetime_field opt_paren_precision
{
@@ -3097,6 +3109,13 @@ function_args_commalist:
else
YYERROR;
}
+   |   datetime_unit ',' function_arg ',' function_arg
+{
+$$ = SQL_NEW_COMMALISTRULE;
+$$->append($1);
+$$->append($3);
+$$->append($5);
+}
;
 
 value_exp:


[Libreoffice-commits] core.git: svl/source

2023-08-07 Thread Andrea Gelmini (via logerrit)
 svl/source/items/itemset.cxx |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

New commits:
commit 616c1da0cc8b345e13bec14b4794e7bab7e1d046
Author: Andrea Gelmini 
AuthorDate: Mon Aug 7 19:47:29 2023 +0200
Commit: Julien Nabet 
CommitDate: Mon Aug 7 23:38:03 2023 +0200

Fix typos

Change-Id: If6cdd69d4508cc938ee90f286b2a6103f24a917b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155430
Tested-by: Jenkins
Reviewed-by: Julien Nabet 

diff --git a/svl/source/items/itemset.cxx b/svl/source/items/itemset.cxx
index bfc8f74b2010..8529efbbef03 100644
--- a/svl/source/items/itemset.cxx
+++ b/svl/source/items/itemset.cxx
@@ -351,7 +351,7 @@ SfxItemState SfxItemSet::GetItemState_ForWhichID( 
SfxItemState eState, sal_uInt1
 
 SfxItemState SfxItemSet::GetItemState_ForOffset( sal_uInt16 nOffset, const 
SfxPoolItem **ppItem) const
 {
-// check and assert fr iinvaliid offset. The caller is responsible for
+// check and assert from invalid offset. The caller is responsible for
 // ensuring a valid offset (see callers, all checked & safe)
 assert(nOffset < TotalCount());
 SfxPoolItem const** pFoundOne = m_ppItems + nOffset;
@@ -1520,7 +1520,7 @@ sal_uInt16 
WhichRangesContainer::getOffsetFromWhich(sal_uInt16 nWhich) const
 return INVALID_WHICHPAIR_OFFSET;
 }
 
-// check if nWhich is inside last sucessfully used WhichPair
+// check if nWhich is inside last successfully used WhichPair
 if (INVALID_WHICHPAIR_OFFSET != m_aLastWhichPairOffset
 && m_aLastWhichPairFirst <= nWhich
 && nWhich <= m_aLastWhichPairSecond)
@@ -1579,7 +1579,7 @@ sal_uInt16 
WhichRangesContainer::getWhichFromOffset(sal_uInt16 nOffset) const
 return 0;
 }
 
-// check if nWhich is inside last sucessfully used WhichPair
+// check if nWhich is inside last successfully used WhichPair
 if (INVALID_WHICHPAIR_OFFSET != m_aLastWhichPairOffset)
 {
 // only try if we are beyond or at m_aLastWhichPairOffset to
@@ -1604,7 +1604,7 @@ sal_uInt16 
WhichRangesContainer::getWhichFromOffset(sal_uInt16 nOffset) const
 
 // Iterate over WhichPairs in WhichRangesContainer
 // Do not update buffered last hit (m_aLastWhichPair*), these calls
-// are potetially more rare than getOffsetFromWhich calls. Still,
+// are potentially more rare than getOffsetFromWhich calls. Still,
 // it could also be done here
 for( auto const & pPtr : *this )
 {


[Libreoffice-bugs] [Bug 107497] top border padding produces additional top margin if paragraph is first in section

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=107497

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 77484] Writer: Tabstopps applied wrong if page margins and frameborder are set.

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=77484

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 153407] Inconsistent "Merge with next paragraph" border behaviour

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=153407

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 125804] PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125804

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=77
   ||484,
   ||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=15
   ||3407,
   ||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=10
   ||7497

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

[Libreoffice-bugs] [Bug 119727] [META] Paragraph borders bugs and enhancements

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=119727

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Depends on|154133  |


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=154133
[Bug 154133] Writer: Erroneous handling of initial tab in hanging indent
paragraphs with border
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 125804] PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125804

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||page74010...@yahoo.fr

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

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

[Libreoffice-bugs] [Bug 154133] Writer: Erroneous handling of initial tab in hanging indent paragraphs with border

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=154133

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Severity|enhancement |normal
 Status|NEW |RESOLVED
 Blocks|119727  |

--- Comment #7 from Stéphane Guillou (stragu) 
 ---
OK, with Heiko and Regina agreeing, I'll mark as duplicate.
Will add the related reports there.

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


Referenced Bugs:

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

[Libreoffice-bugs] [Bug 156623] - Android Viewer can't open any office files and crashed

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156623

--- Comment #13 from Michael Weghorn  ---
(In reply to eric li from comment #12)
> so ,,pls let me know if I only use git pull,,we are behind chinese
> GFW,,using git pull is very painful..however I will download current version
> ,,it is https://github.com/Libreoffice/core...is that OK for you to know
> which current commit/version ?

As long as you make sure, you have the status of current git master, that
should be fine, whatever way you retrieve that.

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

[Libreoffice-bugs] [Bug 146379] Libreoffice 7.2.4.1: error loading libswlo.so

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=146379

Dieter  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDINFO
 Ever confirmed|0   |1
 CC||dgp-m...@gmx.de

--- Comment #3 from Dieter  ---
Vova, could you please retest, if the bug is still present in actual version of
LO (LO 7.5 or 7.6)? If yes, please provide some steps to reproduce.  Thank you.
=> NEEDINFO

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

[Libreoffice-bugs] [Bug 154133] Writer: Erroneous handling of initial tab in hanging indent paragraphs with border

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=154133

Regina Henschel  changed:

   What|Removed |Added

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

--- Comment #6 from Regina Henschel  ---
I consider this to be not an enhancement but a bug, and it is duplicate to bug
125804.

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

[Libreoffice-bugs] [Bug 156655] Long text in merged cells not painted

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156655

Telesto  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Telesto  ---
Confirm
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b3053b63c65372627c5fb4df6b4ddcd5e12e16f7
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

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

[Libreoffice-bugs] [Bug 156661] UI: Drop down dialog of the Insert Special Character to showing the favorites is very tiny

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156661

--- Comment #1 from Telesto  ---
Created attachment 188838
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188838=edit
Screenshot

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

[Libreoffice-bugs] [Bug 156661] New: UI: Drop down dialog of the Insert Special Character to showing the favorites is very tiny

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156661

Bug ID: 156661
   Summary: UI: Drop down dialog of the Insert Special Character
to showing the favorites is very tiny
   Product: LibreOffice
   Version: 24.2.0.0 alpha0+ Master
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: UI
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: tele...@surfxs.nl

Description:
UI: Drop down dialog of the Insert Special Character to showing the favorites
is very tiny

Steps to Reproduce:
1. Open Writer
2. Expand the Special Character favorites by pressing the arrow

Actual Results:
Tiny (see screenshot)

Expected Results:
Normal size


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b3053b63c65372627c5fb4df6b4ddcd5e12e16f7
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

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

[Libreoffice-bugs] [Bug 152240] tabStops should not change with the BeforeText

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=152240

Regina Henschel  changed:

   What|Removed |Added

 CC||rb.hensc...@t-online.de
   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=76
   ||005

--- Comment #7 from Regina Henschel  ---
In ODF 1.4 there will be a new attribute for the default paragraph style
instead of the TabsRelativeToIndent setting.

The problem of tab stops being relative to right edge of paragraph margin was
earlier reported in but 82234. So this is likely duplicate.

The request for having a UI for the setting is in bug 76005.

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

[Libreoffice-bugs] [Bug 76005] UI missing to set document properties: "TabsRelativeToIndent", "TabOverMargin"

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=76005

Regina Henschel  changed:

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 46429] Inertial scrolling switches to zoom if you start pressing a new shortcut key (cmd)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=46429

--- Comment #28 from Wojtek  ---
Is there any motion on fixing this? I spend some time (luckily not 100% my work
time) in Calc and usually doing scrolling and copy/pasting (thus cmd+c/v) and I
feel like I'm in some bizarre place with LO constantly switching zoom...

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

[Libreoffice-bugs] [Bug 108273] FORMATING: Tabstops behave strange when paragraph is right or middle aligned

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108273

Regina Henschel  changed:

   What|Removed |Added

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

--- Comment #8 from Regina Henschel  ---
I see the bug still in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice
Community
Build ID: b3053b63c65372627c5fb4df6b4ddcd5e12e16f7
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded

When fixing the bug, make sure that the behavior is correct for right-to-left
writing mode too. It might be that the current behavior was introduced for RTL
documents.

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

[Libreoffice-bugs] [Bug 82234] EDITING: Indent size shouldn't effect the tab stop position values

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=82234

Regina Henschel  changed:

   What|Removed |Added

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

--- Comment #15 from Regina Henschel  ---
The fact whether the tab position is relative to the indent is determined by
the setting TabsRelativeToIndent in the subdocument settings.xml. For documents
originally created in LibreOffice its default value is "true", for documents
imported from docx the value is "false". There is currently no UI for this
setting. You need a macro or edit the markup in the file source to change it.

In ODF 1.4 this setting will belong to the paragraph style.

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

[Libreoffice-bugs] [Bug 125804] PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125804

--- Comment #11 from Regina Henschel  ---
The problem is not in the tab stop itself. The tab stop with fill character
which belongs to the paragraph style is correctly set. Depending on the global
setting "TabsRelativeToIndent" it is 3.0cm from the left edge of the paragraph
margin or 3.0cm from the right edge of the paragraph margin.

In the example document it is "TabsRelataiveToIndent = true", so the tab-stop
is at position 3cm (from paragraph margin) + 5.6cm (the tabstop itself), which
results in the 8.6cm you see in the dialog. When you insert a vertical line you
see, that the tabstop position is the same for Paragraph 1 and Paragraph 2.

The problem is the automatic pseudo-tabstop, which LibreOffice introduces in
case of negative first line indent. That tabstop should be at the same position
as the left edge of the paragraph content area, that is the position where the
text of the second and followings lines start.

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

[Libreoffice-bugs] [Bug 54908] printing when a selection is active should take in account it and activate the "print selection" radio button

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=54908

--- Comment #36 from Telesto  ---
Not so font of the suggestions proposed in bug 139164 comment 21 (also posted
here under comment 35)

I'm more in favor the suggestion in comment 26, more specific: split print/PDF
button in toolbar "print selection". The split button might also be a 'swap'
'toggle button'. So if select 'print selection' the button will be defaulted to
'selection', until you switch it back. If you want to export/print selections
repeatedly (or wanting it to be the 'default')

The same system is already present for the shapes and highlight/character color
button in toolbar. You pick a different shape/color, and the shape/color will
be default..

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

[Libreoffice-bugs] [Bug 54908] printing when a selection is active should take in account it and activate the "print selection" radio button

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=54908

--- Comment #35 from Telesto  ---
>From bug 139164 comment 21
We discussed this topic in the design meeting.

Printing or exporting a selection is sometimes desired and sometimes
accidentally. The preselection is a convenience feature and at least for
printing easy to spot. 

However, the large number of tickets and discussion around this topic
contradicts this view. And there are a number of possible solutions:

1. Show a confirmation dialog (bug 54908 comment 26)
This might be annoying if users intentionally want to print selections. It
might be solved by
1.a a checkbox "[x] Ask for confirmation" that could be missing in the next
session when printing a selection is not the goal, and
1.b [x] Ask for confirmation during the session" could solve it by saving this
answer for the session only

2. Use a highlighting color for automatically selected options, eg. show
"Selection" in red
It has some drawbacks on special themes, is not a11y conform, and might not be
clear enough

3. Add an extra command for "Export Selection to PDF"
Easy to understand and to realize but bloats the menu. 
3.a As an improvement it could be on the context menu only (and print/export
would always be for the whole document)
3.b Another idea is to rename the command conditionally if a selection is
active

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

[Libreoffice-bugs] [Bug 156656] Option to suppress --convert-to results to screen

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156656

Xisco Faulí  changed:

   What|Removed |Added

 CC||xiscofa...@libreoffice.org

--- Comment #2 from Xisco Faulí  ---
you should use --headless along with --convert-to

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

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

2023-08-07 Thread Xisco Fauli (via logerrit)
 sc/qa/unit/ucalc_formula2.cxx |   16 
 1 file changed, 16 insertions(+)

New commits:
commit 5eca134cf91307f0e7ffc89e9074b37d26fcac99
Author: Xisco Fauli 
AuthorDate: Mon Aug 7 17:06:00 2023 +0200
Commit: Xisco Fauli 
CommitDate: Mon Aug 7 20:53:06 2023 +0200

tdf#127334: sc_ucalc_formula2: Add unittest

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

diff --git a/sc/qa/unit/ucalc_formula2.cxx b/sc/qa/unit/ucalc_formula2.cxx
index 87f858ff4dc9..14f0001f943d 100644
--- a/sc/qa/unit/ucalc_formula2.cxx
+++ b/sc/qa/unit/ucalc_formula2.cxx
@@ -3754,6 +3754,22 @@ CPPUNIT_TEST_FIXTURE(TestFormula2, testTdf132519)
 m_pDoc->DeleteTab(0);
 }
 
+CPPUNIT_TEST_FIXTURE(TestFormula2, testTdf127334)
+{
+CPPUNIT_ASSERT(m_pDoc->InsertTab(0, "Sheet1"));
+
+m_pDoc->SetString(
+0, 0, 0,
+"= (((DATE(2019;9;17) + TIME(0;0;1)) - DATE(2019;9;17)) - 
TIME(0;0;1))/TIME(0;0;1)");
+
+// Without the fix in place, this test would have failed with
+// - Expected: 0
+// - Actual  : 2.32e-07
+CPPUNIT_ASSERT_EQUAL(0.0, m_pDoc->GetValue(0, 0, 0));
+
+m_pDoc->DeleteTab(0);
+}
+
 CPPUNIT_TEST_FIXTURE(TestFormula2, testTdf100818)
 {
 CPPUNIT_ASSERT(m_pDoc->InsertTab(0, "Sheet1"));


[Libreoffice-bugs] [Bug 156660] Implement "Step Chart" in Calc

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156660

--- Comment #1 from Rafael Lima  ---
Created attachment 188837
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188837=edit
Example of step chart

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

[Libreoffice-bugs] [Bug 156660] New: Implement "Step Chart" in Calc

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156660

Bug ID: 156660
   Summary: Implement "Step Chart" in Calc
   Product: LibreOffice
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: enhancement
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: rafael.palma.l...@gmail.com

The "step chart" is a common variation of the line chart that we currently do
not offer in LO Calc. For example, in quality management the p-control chart
draws the control limits using step lines (see attached example).

There are many other data visualization cases (in academia as well as in
companies) where the step chart is useful.

For comparison, MS Excel still does not offer this chart by default, and it is
very hacky to get a step chart in Excel. See for instance:
https://trumpexcel.com/step-chart-in-excel/

However, I could not make the same hack work in LibreOffice.

Given the usefulness of this chart, we should offer it as a variation of the
"Line chart" in the chart wizard.

As for customization options for this chart, I suggest using PyPlot's "step"
chart as inspiration.
https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.step.html

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

[Libreoffice-ux-advise] [Bug 156659] Find All should not move to the first occurrence

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156659

Rafael Lima  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
   Keywords||needsUXEval

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

[Libreoffice-bugs] [Bug 156659] Find All should not move to the first occurrence

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156659

Rafael Lima  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
   Keywords||needsUXEval

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

[Libreoffice-bugs] [Bug 156659] New: Find All should not move to the first occurrence

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156659

Bug ID: 156659
   Summary: Find All should not move to the first occurrence
   Product: LibreOffice
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Writer
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: rafael.palma.l...@gmail.com

Created attachment 188836
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188836=edit
Sample document to reproduce the problem

In Writer, when you click "Find All" in the Find toolbar, the focus should not
automatically move to the first occurrence of the search term. Instead, the
focus should move to the first occurrence after the cursor position.

This is a problem in long documents... suppose you have a 200-page
dissertation, and you are currently reading page 150. Then you look up some
frequent term and as soon as you click "Find All", the cursor moves to the
first occurrence, which will likely be in the beginning of the document.

The expected behavior would be to have the focus moving to the first occurrence
after the current cursor position.

Steps to reproduce
1) Open attached sample document (it has 10 pages)
2) Go to the 5th page in the document
3) Press Ctrl+F to open the Find toolbar
4) Enter the "TEST" term (this word exists multiple times in the document, in
all pages)
5) Click "Find All"

Observed result:
The focus will move to the first paragraph in page 1, which is the first
occurrence of "TEST"

Expected result:
The focus should move to the occurrence right after the current cursor position

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

[Libreoffice-bugs] [Bug 156658] Problem with one embedded Calc table in writer documents

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156658

birqu...@web.de changed:

   What|Removed |Added

 CC||birqu...@web.de

--- Comment #1 from birqu...@web.de ---
Created attachment 188835
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188835=edit
An picture of the distortion

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

[Libreoffice-bugs] [Bug 156658] New: Problem with one embedded Calc table in writer documents

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156658

Bug ID: 156658
   Summary: Problem with one embedded Calc table in writer
documents
   Product: LibreOffice
   Version: 7.4.7.2 release
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Writer
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: birqu...@web.de

Created attachment 188834
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188834=edit
The document with the embedded Calc table

The update to LO 7.4.7.2 makes it impossible to work with one special embedded
Calc table in Writer documents. The same error shows up with LO 7.5.5. I could
reproduce the behaviour on my old Laptop (Win10-64 Pro) with LO 7.4.7.2 and a
plain install without any Add-ons. Any table with random inputs behaves
normally. So it must be the identified one wich I created a few years ago. Over
the time some changes were done in the content of some of the cells. If I
double-click the table to change the displayed data by scrolling down to the
needed date the opened frame shows up distorted in some way, so it gets very
difficult to work with it as far as I don't get the usual WYSIWYG.

I added the whole file since it contains only open data.

For the moment I got back to LO 7.4.6.2 where everything is working as
intended. 

I don't know how to describe the odd behaviour better - my English may be not
good enough.

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

[Libreoffice-bugs] [Bug 61743] Wrongly Absolute Path Referencing to named Ranges Across Documents

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=61743

Eike Rathke  changed:

   What|Removed |Added

 OS|Windows (All)   |All
Version|3.6.4.3 release |Inherited From OOo
   Hardware|Other   |All

--- Comment #21 from Eike Rathke  ---
(In reply to Richard Jelinek from comment #19)
> I'd consider the importance of this as critical, as for now it makes it
> impossible to work on the same set of cross-linked files on different
> computers.
Certainly not, if you actually let links getting saved as relative and use cell
ranges. Affected here are external named expressions and ranges, as I explained
in comment 12 already. Linking to external data by cell ranges works.


(In reply to Wolfgang Jäger from comment #20)
> As there weren't many users coming to this bug discussion and claiming
> urgency I wouldn't expect immediate action if you change the importance.
> But: Simply try.
Right, upping importance won't change much because you'd have to find someone
to actually implement that feature.

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

[Libreoffice-bugs] [Bug 156657] Exposing all Calc cells in accessibility tree is incompatible with AtspiCollection

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156657

Joanmarie Diggs  changed:

   What|Removed |Added

 Blocks||36549


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=36549
[Bug 36549] [META] ACCESSIBILITY: Tracking bug for issues affecting a11y ATK
and GNOME Orca screen reader support
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 36549] [META] ACCESSIBILITY: Tracking bug for issues affecting a11y ATK and GNOME Orca screen reader support

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=36549

Joanmarie Diggs  changed:

   What|Removed |Added

 Depends on||156657


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=156657
[Bug 156657] Exposing all Calc cells in accessibility tree is incompatible with
AtspiCollection
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 156657] Exposing all Calc cells in accessibility tree is incompatible with AtspiCollection

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156657

--- Comment #1 from Joanmarie Diggs  ---
Created attachment 188833
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188833=edit
tool to make calc unresponsive

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

[Libreoffice-bugs] [Bug 156657] New: Exposing all Calc cells in accessibility tree is incompatible with AtspiCollection

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156657

Bug ID: 156657
   Summary: Exposing all Calc cells in accessibility tree is
incompatible with AtspiCollection
   Product: LibreOffice
   Version: 7.5.5.2 release
  Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: jdi...@igalia.com

Description:
The AtspiCollection interface, while originally created for web content, works
on all ATK implementations and is a much more performant (sometimes 10x faster)
way for Orca to locate objects of interest compared to iterating recursively
through the accessibility tree. As a result, I (Orca maintainer) am slowly but
surely migrating over to preferring AtspiCollection.

Unfortunately, the fact that Calc exposes all cells in the accessibility tree
means Orca can not apply this to at least Calc and possible not to LibreOffice
at all (just to be safe). See steps and attached python tool which makes Calc
completely unresponsive.

Steps to Reproduce:
1. Launch Writer
2. Launch Calc
3. Launch the to-be-attached python tool in a terminal
4. Click on the Writer window
5. Click on the Calc window

Actual Results:
Each time a window is activated, the script goes looking for a single status
bar using AtspiCollection. It succeeds with Writer and errors out with Calc and
exits. But even though the tool has exited, Calc is non-responsive.

Here's the output from the tool:

==
Searching in Untitled 1 - LibreOffice Writer frame
Found  status bar


Searching in Untitled 2 - LibreOffice Calc frame

EXCEPTION: atspi_error: timeout from dbind (1)
Traceback (most recent call last):
  File "/home/jd/Desktop/./listener.py", line 35, in on_event
if not objs:
   
UnboundLocalError: cannot access local variable 'objs' where it is not
associated with a value
==

Expected Results:
Calc wouldn't become completely unresponsive.


Reproducible: Always


User Profile Reset: No

Additional Info:
I filed https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138 to ask Atspi
to not descend ginormous tables.

As you will see in a later comment, I also suggested that Calc should consider
doing what web app authors with giant grids do, namely only include a subset of
the conceptual table in the DOM and use ARIA properties to expose stuff ATs
should report to end users.

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

[Libreoffice-bugs] [Bug 156656] Option to suppress --convert-to results to screen

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156656

Julien Nabet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDINFO
 Ever confirmed|0   |1
 CC||serval2...@yahoo.fr

--- Comment #1 from Julien Nabet  ---
Did you try something like:
soffice --convert-to ods test.csv &> /dev/null
?

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

[Libreoffice-bugs] [Bug 156634] REPORTBUILDER: Crash in: rptxml::ORptExport::exportSectionAutoStyle(com::sun::star::uno::Reference const &)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156634

Julien Nabet  changed:

   What|Removed |Added

 CC|serval2...@yahoo.fr |

--- Comment #6 from Julien Nabet  ---
The last crash record is similar to previous.
Without a way to reproduce this, I don't know how to help but maybe some people
will know.
Can't do anything here=>uncc myself.

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

[Libreoffice-bugs] [Bug 156630] Regression: Opaque parts of APNGs don't seem to be drawn

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156630

Patrick Luby  changed:

   What|Removed |Added

   Assignee|libreoffice-b...@lists.free |plub...@neooffice.org
   |desktop.org |
 Status|NEW |ASSIGNED

--- Comment #17 from Patrick Luby  ---
Update: I think that I have fixed some of the bugs seen so far:

https://gerrit.libreoffice.org/c/core/+/155429

This patch fixes the following:

- Eliminates the opaque background when opening
https://bugs.documentfoundation.org/attachment.cgi?id=188792 in Draw or in
Impress
- I may have fixed the Windows GDI rendering problems described in
https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c12

Still todo before I commit the patch:

- Fix opaqueness surrounding image when running a slideshow
- Add native accessibility check described in
https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c6
- Fix the macOS-only Skia window scaling problems described in
https://bugs.documentfoundation.org/show_bug.cgi?id=156629#c10
- Fix random drawing of black alpha mask when exporting to PDF with Skia/Metal
when image is opened in Draw and the document background is set to an opaque
color. This may be related to the macOS-only Skia window scaling problems.

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

[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

New commits:
commit ceeb48b33b374dfcd970d4fdd194ce0301bbb65a
Author: Justin Luth 
AuthorDate: Wed Aug 2 15:28:44 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 18:15:47 2023 +0200

tdf#57414 autorecovery: ignoreClosing during Emergency/SessionSave

Unmodified documents were losing the enties from RecoveryList
when implts_deregisterDocument was triggered,
which prevented the Session recovery from being able to reload them.

Change-Id: I991a9821105aca81ec596b28341ef4335b817439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155380
Reviewed-by: Justin Luth 
Tested-by: Jenkins

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index 657d8c12106c..dbf0c803aab6 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -2896,12 +2896,17 @@ AutoRecovery::ETimerType AutoRecovery::implts_saveDocs( 
  boolbAllow
 if ((aInfo.DocumentState & DocState::Handled) == DocState::Handled)
 continue;
 
+// don't allow implts_deregisterDocument to remove from RecoveryList 
during shutdown jobs
+if (m_eJob & (Job::EmergencySave | Job::SessionSave))
+aInfo.IgnoreClosing = true;
+
 // Not modified documents are not saved.
-// We safe an information about the URL only!
+// We save information about the URL only!
 Reference< XDocumentRecovery > xDocRecover( aInfo.Document, 
UNO_QUERY_THROW );
 if ( !xDocRecover->wasModifiedSinceLastSave() )
 {
 aInfo.DocumentState |= DocState::Handled;
+*pIt = aInfo;
 continue;
 }
 


[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #10 from Patrick Luby  ---
(In reply to Noel Grandin from comment #9)
> (In reply to Patrick Luby from comment #8)
> > Are you not seeing this behavior on Windows or Linux with Skia/Vulcan?
> 
> I do not see rendering artifacts on Windows, cannot test Linux.
> 
> > Also,
> > are you not seeing
> > https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15?
> 
> On Windows, I see rendering artifacts near the tail.

I now think that this is a macOS-only bug. If the bug was occurring on Windows,
you would see the 2x scale gray outline of the elephant in the bottom half of
the animated image like in
https://bugs.documentfoundation.org/attachment.cgi?id=188832.

I forced the native and Skia window scale to always be 1.0f in
getWindowScaling() in vcl/skia/osx/gdiimpl.cxx and this Skia/Raster scaling
behavior no longer occurs for this bug or for
https://bugs.documentfoundation.org/show_bug.cgi?id=156630 so I suspect that
Skia's window scale is diverging from the native window scale.

I'll investigate that and submit a separate Gerrit change when I have a fix.

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

[Libreoffice-bugs] [Bug 156630] Regression: Opaque parts of APNGs don't seem to be drawn

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156630

--- Comment #16 from Patrick Luby  ---
Created attachment 188832
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188832=edit
Animation with Skia/Raster on macOS. Note the gray outline in the bottom half
which is 2x scaled.

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

[Libreoffice-bugs] [Bug 126084] DOCX/OOXML support of SVG images via Office Drawing extension and fallback (published schema)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=126084

--- Comment #8 from Johannes Weberhofer  ---
We are currently testing embedding images with Apache poi producing xlsx files
and see the same behavior.

When we leave out the fallback-raster-grapic completely, LO shows nothing.

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

[Libreoffice-commits] core.git: include/svl svl/source svx/source sw/source

2023-08-07 Thread Armin Le Grand (allotropia) (via logerrit)
 include/svl/itemset.hxx   |   24 
 include/svl/whichranges.hxx   |   21 
 svl/source/items/itemiter.cxx |   21 
 svl/source/items/itemset.cxx  |  673 +++---
 svl/source/items/whiter.cxx   |   25 
 svx/source/dialog/srchdlg.cxx |2 
 sw/source/core/crsr/findattr.cxx  |8 
 sw/source/core/doc/DocumentRedlineManager.cxx |2 
 sw/source/core/txtnode/ndtxt.cxx  |2 
 sw/source/core/undo/undobj1.cxx   |2 
 sw/source/filter/ww8/writerhelper.cxx |2 
 sw/source/uibase/app/docstyle.cxx |2 
 sw/source/uibase/uiview/srcview.cxx   |2 
 13 files changed, 472 insertions(+), 314 deletions(-)

New commits:
commit bd6c6d46e82eb5cf5839a5b99e4838471250e959
Author: Armin Le Grand (allotropia) 
AuthorDate: Mon Jul 31 13:12:48 2023 +0200
Commit: Armin Le Grand 
CommitDate: Mon Aug 7 17:53:53 2023 +0200

ITEM: speedup WhichRanges access by buffering

I checked for was to speedup SfxItemSet stuff, so had
(besides other things) a look at WhichRangesContainer
and it's usage(s). Problem with the WhichRanges is that
a WhichID which you try to find is usually inside that
range, so binary search is no option. You have to detect
in which range the WhichID is hosted and can the directly
calculate the index into the array of Items at the
SfxtemSet.
Currently when needing to transform a WhichID to an index
into the array of Items in SfxItemSet the array of the
WhichRangesContainer is searched linearly from the start
every time.
This can be a little bit speed up by buffering the last
successful 'hit' and trying to re-use it. Also the
special case of a single WhichPair (e.g. UI stuff) is
worth having a look.
All acesses to that transformation are changed to use
the tooling method getOffsetFromWhich() at the
WhichRangesContainer which does the transformation.
This also needed cleanup of ItemOffsetHint instances
& stuff around it. It does not more than before but
also profits from the single entry buffer.
I added some DBG_UTIL-based stuff to watch the hit/miss
ratio, which is heavily changing from app to app & usage,
but varies around 1.5 to 3.5, also saw 6.5 and more at
document import.
NOTE: I already checked if sorting the WhichPair(s) in
WhichRangesContainer by their 'width' (highest WhichID
mnius lowest WhichID helps. The idea was when the Items
would be used in a regular manner that when having the
widest WhichPairs at the start, the buffer would even
be better used - but doing tests in all apps shows
nearly no gain, so I left that out.
NOTE: Not too much speedup, but faster...

Had to deep-debug due to CppunitTest_sw_odfexport failing,
found a slight diff between GetItemState impls, corrected.
Also added more changes, e.g. TotalCount is now a member
to not always have to calculate it from the
WhichRangesContainer.
Extended GetWhichByPos to 1st try to find a set Item, else
iterate over WhichRangesContainer.
This is due to SfxItemIter's implementations of
GetItemState and ClearItem which both up to now just
accessed the SfxPoolItem array of the SfxItemSet, ignoring
that no Item (nullptr) or state DONTCARE (-1) may have been
set there (no item is prevented by ite Iterator, but better
be careful).

Added WhichRangesContainer::getWhichFromOffset and made
SfxItemSet::GetWhichByOffset use it. Addedd optimizations
there for single-entry WhichPair and using the buffer at
WhichRangesContainer which is possible.
Removed debug comparing stuff (had a test that used the
former adapted GetItemStateImpl method in
SfxItemSet::GetItemState and compared with the changed
GetItemState_ForWhichID).
Added some comments and assertions where useful.
Made ClearSingleItem_ForOffset work without handing
over WhichID, that makes calls using it simpler and
avoids calculating the WhichID just for that call.

Change-Id: I54de552368b654f00f115978715f8241eb603752
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155316
Tested-by: Jenkins
Reviewed-by: Armin Le Grand 

diff --git a/include/svl/itemset.hxx b/include/svl/itemset.hxx
index 52966ecc96d6..468893557b5e 100644
--- a/include/svl/itemset.hxx
+++ b/include/svl/itemset.hxx
@@ -40,9 +40,10 @@ class SAL_WARN_UNUSED SVL_DLLPUBLIC SfxItemSet
 
 SfxItemPool*  m_pPool; ///< pool that stores the items
 const SfxItemSet* m_pParent;   ///< derivation
+sal_uInt16m_nCount;///< number of items
+sal_uInt16m_nTotalCount;   ///< number of WhichIDs, also size of 
m_ppItems array
 SfxPoolItem const** m_ppItems; ///< pointer to array of items, we 
allocate and free this unless 

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #9 from Noel Grandin  ---
(In reply to Patrick Luby from comment #8)
> Are you not seeing this behavior on Windows or Linux with Skia/Vulcan?

I do not see rendering artifacts on Windows, cannot test Linux.

> Also,
> are you not seeing
> https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15?

On Windows, I see rendering artifacts near the tail.

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

[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

New commits:
commit 63bb760acc8aa50c352f3349e8adf3db381b4911
Author: Justin Luth 
AuthorDate: Tue Aug 1 16:00:33 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 17:43:54 2023 +0200

tdf#57414 autorecovery: avoid unnecessary storeToRecoveryFile

With a successful UserAutoBackup, the document is fully saved,
and the recoveryInfo entry is removed.

So just avoid the recovery that would just be deleted anyway.

Change-Id: I3cc9fe2730640df48f450f900f33afc2df7f020a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155273
Tested-by: Jenkins
Reviewed-by: Justin Luth 

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index 816e4f7253a3..657d8c12106c 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -3073,6 +3073,7 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 // Note that we must do it *before* calling storeToRecoveryFile, so in 
case of failure here
 // we won't remain with the modified flag set to true, even though the 
autorecovery save succeeded.
 const bool bEmergencySave(m_eJob & Job::EmergencySave);
+bool bUserAutoSaved = false;
 try
 {
 // We must check here for an empty URL to avoid a "This operation is 
not supported on this operating system."
@@ -3081,6 +3082,7 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 {
 Reference< XStorable > xDocSave(rInfo.Document, 
css::uno::UNO_QUERY_THROW);
 xDocSave->store();
+bUserAutoSaved = true;
 }
 }
 catch(const css::uno::Exception&)
@@ -3098,7 +3100,7 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 
 // If it is no longer modified, it is the same as on disk, and can be 
removed from RecoveryList.
 const bool bRemoveIt
-= xModify.is() && !xModify->isModified() && !bEmergencySave && 
!(m_eJob & Job::SessionSave);
+= xModify.is() && !xModify->isModified() && bUserAutoSaved && !(m_eJob 
& Job::SessionSave);
 
 sal_Int32 nRetry = RETRY_STORE_ON_FULL_DISC_FOREVER;
 bool  bError = false;
@@ -3106,7 +3108,10 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 {
 try
 {
-xDocRecover->storeToRecoveryFile( rInfo.NewTempURL, 
lNewArgs.getAsConstPropertyValueList() );
+// skip recovery if it will be removed anyway.
+if (!bRemoveIt)
+xDocRecover->storeToRecoveryFile(rInfo.NewTempURL,
+ 
lNewArgs.getAsConstPropertyValueList());
 
 #ifdef TRIGGER_FULL_DISC_CHECK
 throw css::uno::Exception("trigger full disk check");


[Libreoffice-bugs] [Bug 133092] [META] Crash bugs

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=133092
Bug 133092 depends on bug 150137, which changed state.

Bug 150137 Summary: Crash when parsing an XML with undeclared namespace
https://bugs.documentfoundation.org/show_bug.cgi?id=150137

   What|Removed |Added

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

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

[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

New commits:
commit f5d6888bd1b945596684cb643118e0e07477d3fa
Author: Justin Luth 
AuthorDate: Mon Jul 31 15:23:11 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 17:43:10 2023 +0200

tdf#57414 autorecovery: don't store unmodified docs in RecoveryList

When a document is successfully saved (manually),
it is removed from RecoveryList (implts_markDocumentAsSaved)
and all of the temporary recovery files are removed
from the user's backup folder.

If the document is automatically saved (UserAutoSave)
successfully, it doesn't need to remain in the RecoveryList either.

storeToRecoveryFile can benefit from knowing if it will be removed,
so determine whether to bRemoveIt just prior to that call.

Change-Id: I2cb30b426e600cfe34987a091acaf8826316ede5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155272
Tested-by: Jenkins
Reviewed-by: Justin Luth 

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index 1071423da954..816e4f7253a3 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -3096,6 +3096,10 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 else if (xModify.is())
 rInfo.DocumentState &= ~DocState::Modified;
 
+// If it is no longer modified, it is the same as on disk, and can be 
removed from RecoveryList.
+const bool bRemoveIt
+= xModify.is() && !xModify->isModified() && !bEmergencySave && 
!(m_eJob & Job::SessionSave);
+
 sal_Int32 nRetry = RETRY_STORE_ON_FULL_DISC_FOREVER;
 bool  bError = false;
 do
@@ -3184,7 +3188,8 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 rInfo.OldTempURL = rInfo.NewTempURL;
 rInfo.NewTempURL.clear();
 
-implts_flushConfigItem(rInfo);
+// If it is modified, a recovery file has just been created, so add to 
RecoveryList.
+implts_flushConfigItem(rInfo, bRemoveIt, /*bAllowAdd=*/bModified);
 
 // We must know if the user modifies the document again ...
 implts_startModifyListeningOnDoc(rInfo);


[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

New commits:
commit 9fffac201136dc4f0a128171c17b0fd38836c043
Author: Justin Luth 
AuthorDate: Mon Jul 31 18:10:29 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 17:41:36 2023 +0200

tdf#57414 autorecovery: not in RecoveryList? always delete tmp files

In all but one case, the storeToRecoveryFiles were deleted
when the entry was removed from the RecoveryList
(and likely it should have been removed in that case as well,
 since the program could not open that file anyway).

So, move that function into the flushConfig function
to ensure that recovery files are not orphaned
in the backup folder.

If the URLs are not cleared, and the recovery tries to load
the non-existing file, then LO will assert (or maybe crash).

(For implts_markDocumentAsSaved,
it does the deletefiles/flushCOnfig outside of the SAFE area,
but updates m_lDocCache with *pIt = aInfo inside the SAFE area,
so those deletefiles/clears cannot be cleaned up.)

(implts_cleanUpWorkingEntry and implts_deregisterDocument
both remove the m_lDocCache entry competely, so it was not
necessary to clear the URLs in those two cases.)

Change-Id: I765f3a815f28082495a7f286a8b28b977e0cad75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155118
Reviewed-by: Justin Luth 
Tested-by: Jenkins

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index f0affa0cf7f3..1071423da954 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -575,7 +575,7 @@ private:
 void implts_readAutoSaveConfig();
 
 // TODO document me
-void implts_flushConfigItem(const AutoRecovery::TDocumentInfo& rInfo, bool 
bRemoveIt = false,
+void implts_flushConfigItem(AutoRecovery::TDocumentInfo& rInfo, bool 
bRemoveIt = false,
 bool bAllowAdd = true);
 
 // TODO document me
@@ -1981,7 +1981,7 @@ void AutoRecovery::implts_persistAllActiveViewNames()
 }
 }
 
-void AutoRecovery::implts_flushConfigItem(const AutoRecovery::TDocumentInfo& 
rInfo, bool bRemoveIt,
+void AutoRecovery::implts_flushConfigItem(AutoRecovery::TDocumentInfo& rInfo, 
bool bRemoveIt,
   bool bAllowAdd)
 {
 std::shared_ptr batch(
@@ -2007,6 +2007,11 @@ void AutoRecovery::implts_flushConfigItem(const 
AutoRecovery::TDocumentInfo& rIn
 // DO IT!
 try
 {
+osl::File::remove(rInfo.OldTempURL);
+osl::File::remove(rInfo.NewTempURL);
+rInfo.OldTempURL.clear();
+rInfo.NewTempURL.clear();
+
 xModify->removeByName(sID);
 }
 catch(const css::container::NoSuchElementException&)
@@ -2540,8 +2545,6 @@ void AutoRecovery::implts_deregisterDocument(const 
css::uno::Reference< css::fra
 if (bStopListening)
 implts_stopModifyListeningOnDoc(aInfo);
 
-AutoRecovery::st_impl_removeFile(aInfo.OldTempURL);
-AutoRecovery::st_impl_removeFile(aInfo.NewTempURL);
 implts_flushConfigItem(aInfo, true); // sal_True => remove it from config
 }
 
@@ -3323,7 +3326,8 @@ AutoRecovery::ETimerType 
AutoRecovery::implts_openDocs(const DispatchParams& aPa
 info.DocumentState |=  DocState::Damaged;
 }
 
-implts_flushConfigItem(info, true);
+implts_flushConfigItem(info, /*bRemoveIt=*/true);
+
 implts_informListener(eJob,
 AutoRecovery::implst_createFeatureStateEvent(eJob, 
OPERATION_UPDATE, ));
 
@@ -3898,8 +3902,6 @@ void AutoRecovery::implts_cleanUpWorkingEntry(const 
DispatchParams& aParams)
 if (pIt != m_lDocCache.end())
 {
 AutoRecovery::TDocumentInfo& rInfo = *pIt;
-AutoRecovery::st_impl_removeFile(rInfo.OldTempURL);
-AutoRecovery::st_impl_removeFile(rInfo.NewTempURL);
 implts_flushConfigItem(rInfo, true); // sal_True => remove it from xml 
config!
 
 m_lDocCache.erase(pIt);


[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |   23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

New commits:
commit 9e0f13b2c4d31537162434b5b932b265c62349e0
Author: Justin Luth 
AuthorDate: Thu Jul 20 16:29:41 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 17:40:06 2023 +0200

tdf#57414 autorecovery: don't always add every file to RecoveryList

There is no need to recover documents that are not modified,
and certainly not if there is no storeToRecoveryFile.
This specifically is nice for read-only files, new files,
or e-mailed files that have just been opened for viewing.

registerDocument: A just opened file has nothing to recover,
so wait until it has storeToRecoveryFile'd.
  - Emergency and Session pre-register all documents
via implts_persistAllActiveViewNames, so no problem here.

resetHandleStates: shouldn't add, just update the existing states

saveOneDoc: shouldn't add before storeToRecoveryFile, only after.

Change-Id: I4a935ee325af6469b25c5bf3d2860c4065d9130d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154490
Tested-by: Jenkins
Reviewed-by: Justin Luth 

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index 1bef7e6f3980..f0affa0cf7f3 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -575,8 +575,8 @@ private:
 void implts_readAutoSaveConfig();
 
 // TODO document me
-void implts_flushConfigItem(const AutoRecovery::TDocumentInfo& rInfo   
 ,
-  bool bRemoveIt = 
false);
+void implts_flushConfigItem(const AutoRecovery::TDocumentInfo& rInfo, bool 
bRemoveIt = false,
+bool bAllowAdd = true);
 
 // TODO document me
 void implts_startListening();
@@ -1981,7 +1981,8 @@ void AutoRecovery::implts_persistAllActiveViewNames()
 }
 }
 
-void AutoRecovery::implts_flushConfigItem(const AutoRecovery::TDocumentInfo& 
rInfo, bool bRemoveIt)
+void AutoRecovery::implts_flushConfigItem(const AutoRecovery::TDocumentInfo& 
rInfo, bool bRemoveIt,
+  bool bAllowAdd)
 {
 std::shared_ptr batch(
 comphelper::ConfigurationChanges::create());
@@ -2019,7 +2020,12 @@ void AutoRecovery::implts_flushConfigItem(const 
AutoRecovery::TDocumentInfo& rIn
 css::uno::Reference< css::beans::XPropertySet > xSet;
 boolbNew = 
!xCheck->hasByName(sID);
 if (bNew)
+{
+if (!bAllowAdd)
+return; // no change made, just exit
+
 xSet.set(xCreate->createInstance(), css::uno::UNO_QUERY_THROW);
+}
 else
 xCheck->getByName(sID) >>= xSet;
 
@@ -2485,7 +2491,8 @@ void AutoRecovery::implts_registerDocument(const 
css::uno::Reference< css::frame
 
 } /* SAFE */
 
-implts_flushConfigItem(aInfo);
+// Even if the document is modified, we don't know if we have anything to 
recover, so don't add.
+implts_flushConfigItem(aInfo, /*bRemoveIt=*/false, /*bAllowAdd=*/false);
 implts_startModifyListeningOnDoc(aInfo);
 
 aCacheLock.unlock();
@@ -3053,10 +3060,11 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 // Because the last temp file is too old and does not include all changes.
 Reference< XDocumentRecovery > xDocRecover(rInfo.Document, 
css::uno::UNO_QUERY_THROW);
 
-// safe the state about "trying to save"
+// save the state about "trying to save"
 // ... we need it for recovery if e.g. a crash occurs inside next line!
 rInfo.DocumentState |= DocState::TrySave;
-implts_flushConfigItem(rInfo);
+// just update existing info: don't add any recovery record until recovery 
file created.
+implts_flushConfigItem(rInfo, /*bRemoveIt=*/false, /*bAllowAdd=*/false);
 
 // If userautosave is enabled, first try to save the original file.
 // Note that we must do it *before* calling storeToRecoveryFile, so in 
case of failure here
@@ -3667,7 +3675,8 @@ void AutoRecovery::implts_resetHandleStates()
 
 // } /* SAFE */
 g.clear();
-implts_flushConfigItem(info);
+// just update existing records.
+implts_flushConfigItem(info, /*bRemoveIt=*/false, /*bAllowAdd=*/false);
 g.reset();
 // /* SAFE */ {
 }


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

2023-08-07 Thread Aron Budea (via logerrit)
 basic/qa/basic_coverage/test_tdf150137_parse_fail.bas |   37 ++
 sax/source/fastparser/fastparser.cxx  |8 ++-
 2 files changed, 42 insertions(+), 3 deletions(-)

New commits:
commit c9e863801509fb37b125a8fb07358fb1b235496d
Author: Aron Budea 
AuthorDate: Sun Aug 6 05:08:23 2023 +0200
Commit: Aron Budea 
CommitDate: Mon Aug 7 17:38:30 2023 +0200

tdf#150137 fastparser: don't crash on undeclared namespace

Change-Id: Icc8bbb391c7e34754b7274d67d73ff509827a3d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155381
Tested-by: Aron Budea 
Reviewed-by: Aron Budea 

diff --git a/basic/qa/basic_coverage/test_tdf150137_parse_fail.bas 
b/basic/qa/basic_coverage/test_tdf150137_parse_fail.bas
new file mode 100644
index ..fdf9f1e9948e
--- /dev/null
+++ b/basic/qa/basic_coverage/test_tdf150137_parse_fail.bas
@@ -0,0 +1,37 @@
+'
+' This file is part of the LibreOffice project.
+'
+' This Source Code Form is subject to the terms of the Mozilla Public
+' License, v. 2.0. If a copy of the MPL was not distributed with this
+' file, You can obtain one at http://mozilla.org/MPL/2.0/.
+'
+
+Option Explicit
+
+Function doUnitTest() As String
+On Error GoTo ErrorHandler ' Set up error handler
+
+Dim Xml As String
+Dim XmlLen As Long
+' Not namespace-well-formed XML, parse is expected to fail
+Xml = ""
+XmlLen = Len(Xml)
+Dim XmlByte(1 To XmlLen) As Byte
+Dim Index As Integer
+For Index = 1 To XmlLen
+XmlByte(Index) = Asc(Mid(Xml, Index, 1))
+Next
+Dim source As Object
+source = CreateUnoStruct("com.sun.star.xml.sax.InputSource")
+source.aInputStream = 
com.sun.star.io.SequenceInputStream.createStreamFromSequence(XmlByte)
+Dim parser As Object
+parser = CreateUnoService("com.sun.star.xml.sax.FastParser")
+' Parse crashed before the fix
+parser.ParseStream(source)
+
+' Shouldn't end up here
+doUnitTest = "FAIL"
+Exit Function
+ErrorHandler:
+doUnitTest = "OK"
+End Function
diff --git a/sax/source/fastparser/fastparser.cxx 
b/sax/source/fastparser/fastparser.cxx
index fd1b147f044e..3c67010ad1cb 100644
--- a/sax/source/fastparser/fastparser.cxx
+++ b/sax/source/fastparser/fastparser.cxx
@@ -1264,12 +1264,14 @@ void FastSaxParserImpl::callbackStartElement(const 
xmlChar *localName , const xm
 OUString aElementPrefix;
 if( prefix != nullptr )
 {
-if ( !m_bIgnoreMissingNSDecl || URI != nullptr )
+aElementPrefix = OUString( XML_CAST( prefix ), strlen( 
XML_CAST( prefix )), RTL_TEXTENCODING_UTF8 );
+if ( URI != nullptr )
 sNamespace = OUString( XML_CAST( URI ), strlen( XML_CAST( 
URI )), RTL_TEXTENCODING_UTF8 );
-else
+else if ( m_bIgnoreMissingNSDecl )
 sNamespace.clear();
+else
+throw SAXException("No namespace defined for " + 
aElementPrefix, {}, {});
 nNamespaceToken = GetNamespaceToken( sNamespace );
-aElementPrefix = OUString( XML_CAST( prefix ), strlen( 
XML_CAST( prefix )), RTL_TEXTENCODING_UTF8 );
 }
 OUString aElementLocalName( XML_CAST( localName ), strlen( 
XML_CAST( localName )), RTL_TEXTENCODING_UTF8 );
 rEvent.msNamespace = sNamespace;


[Libreoffice-bugs] [Bug 156634] REPORTBUILDER: Crash in: rptxml::ORptExport::exportSectionAutoStyle(com::sun::star::uno::Reference const &)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156634

Michael  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|NEEDINFO|UNCONFIRMED

--- Comment #5 from Michael  ---
A similar crash has occurred a second time, see
https://crashreport.libreoffice.org/stats/crash_details/959dc5a6-f66b-4c13-805f-70d64ba5ed6c

I both cases, a database report was open for editing. The report was changed at
various places. It has not been saved before I pressed 'Execute Report'. 
The actual state of the database and actual definition of the report was lost
due to the crash. 

I'm sorry I can't provide more details. I hoped the crash reports would provide
the necessary details.

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

[Libreoffice-bugs] [Bug 88278] [META] SVG import image filter (all modules)

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=88278
Bug 88278 depends on bug 143991, which changed state.

Bug 143991 Summary: The imported text in the SVG image is partially invisible.
https://bugs.documentfoundation.org/show_bug.cgi?id=143991

   What|Removed |Added

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

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

[Libreoffice-bugs] [Bug 143991] The imported text in the SVG image is partially invisible.

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=143991

Xisco Faulí  changed:

   What|Removed |Added

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

--- Comment #5 from Xisco Faulí  ---
This issue is fixed by
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9d60497954ed25bd802e66b5de0f375b301c79eb
Closing as duplicated of bug 153092

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

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

[Libreoffice-commits] core.git: framework/source

2023-08-07 Thread Justin Luth (via logerrit)
 framework/source/services/autorecovery.cxx |9 +
 1 file changed, 9 insertions(+)

New commits:
commit db9fa6da9d57853e0089a063ec372e11ce6046a9
Author: Justin Luth 
AuthorDate: Thu Jul 20 13:25:57 2023 -0400
Commit: Justin Luth 
CommitDate: Mon Aug 7 17:17:47 2023 +0200

related tdf#57414 autosave: try harder to know when !IsModified

The cache that holds document status did:
-saveDocs: for each cached document status:
  -creates a copy of the cached status
  -call saveOneDoc: given the copy
  [-updateModifiedState should get called, updating the cache itself]
  -saveOneDoc: flushConfig writes copy to RecoveryList (as modified)
  -cache is updated with the results from saveOneDoc (*pIt = aInfo)

Now, it is easily possible that saveOneDoc changed the status from
modified, to not modified, wouldn't you think (if UserAutoSave)?
But since the copy was never updated, it reported as modified still!

storeToRecoveryFile can benefit from knowing the real modified status,
so do the update just prior to that call.

Change-Id: Iee1ddd0bf7bee25d5ba3e7abb1ac6713295906af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154683
Reviewed-by: Justin Luth 
Tested-by: Jenkins

diff --git a/framework/source/services/autorecovery.cxx 
b/framework/source/services/autorecovery.cxx
index 4eb7000afeac..1bef7e6f3980 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -3076,6 +3076,15 @@ void AutoRecovery::implts_saveOneDoc(const OUString&
 {
 }
 
+// DocState::Modified status cannot be trusted to be accurate, but at 
least attempt to be so,
+// since this rInfo will eventually get assigned to m_lDocCache as the 
authoritative status.
+const Reference xModify(rInfo.Document, UNO_QUERY);
+const bool bModified = xModify.is() && xModify->isModified();
+if (bModified)
+rInfo.DocumentState |= DocState::Modified;
+else if (xModify.is())
+rInfo.DocumentState &= ~DocState::Modified;
+
 sal_Int32 nRetry = RETRY_STORE_ON_FULL_DISC_FOREVER;
 bool  bError = false;
 do


[Libreoffice-bugs] [Bug 156656] New: Option to suppress --convert-to results to screen

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156656

Bug ID: 156656
   Summary: Option to suppress --convert-to results to screen
   Product: LibreOffice
   Version: 7.5.5.2 release
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: LibreOffice
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: r...@scotsgeek.com

After running the following on the command line:
soffice --convert-to ods test.csv

It displays the results:
convert /redacted/test.csv -> /redacted/test.ods using filter : calc8

I would like to suppress this message, and any other text.  I don't see any
option for this.

Thank you for your response.

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

[Libreoffice-bugs] [Bug 156322] Provide better PDF export settings in Calc

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156322

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
   Keywords||needsUXEval

--- Comment #7 from Stéphane Guillou (stragu) 
 ---
UX/design team, what do you think?

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

[Libreoffice-ux-advise] [Bug 156322] Provide better PDF export settings in Calc

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156322

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
   Keywords||needsUXEval

--- Comment #7 from Stéphane Guillou (stragu) 
 ---
UX/design team, what do you think?

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #8 from Patrick Luby  ---
(In reply to Noel Grandin from comment #7)
> (In reply to Patrick Luby from comment #5)
> > Created attachment 188831 [details]
> > Scaling of font icons with Skia/Metal on macOS
> 
> That looks like either
> 
> (a) the icon is being scaled too large
> 
> or
> 
> (b) the icon is scaled, but is then drawn back to the output buffer at the
> wrong size

What I find difficult to debug is that the scaling only happens with one Skia
setting and not the other and worse, in these two case its one or the other but
never both.

Last night I went through the vcl code and flipped all the RenderRaster
conditionals that I could find to debug
https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15 but so no
change. I repeatedly this flipping this morning and no change for this bug
either.

Are you not seeing this behavior on Windows or Linux with Skia/Vulcan? Also,
are you not seeing
https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15?

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

[Libreoffice-bugs] [Bug 54908] printing when a selection is active should take in account it and activate the "print selection" radio button

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=54908

--- Comment #34 from Mike Kaganski  ---
(In reply to Mike Kaganski from comment #33)
> And please note comment 25.
Err, I meant comment 26.

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

[Libreoffice-bugs] [Bug 54908] printing when a selection is active should take in account it and activate the "print selection" radio button

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=54908

--- Comment #33 from Mike Kaganski  ---
And please note comment 25. Remember that the actual problem was the removal of
the *dialog* asking if the current selection should be printed, or the whole
document. I suppose that the reasonably sane solution would be restoring that
dialog, and have a "don't show again (remember my choice)" in it. Or a separate
command to pring selection.

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #7 from Noel Grandin  ---
(In reply to Patrick Luby from comment #5)
> Created attachment 188831 [details]
> Scaling of font icons with Skia/Metal on macOS

That looks like either

(a) the icon is being scaled too large

or

(b) the icon is scaled, but is then drawn back to the output buffer at the
wrong size

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #6 from Patrick Luby  ---
(In reply to Patrick Luby from comment #5)
> Created attachment 188831 [details]
> Scaling of font icons with Skia/Metal on macOS

I just built master with the commit on macOS and the bug is fixed with
Skia/Raster and Skia disabled.

However, with Skia/Metal, the icon's bitmap is getting scaled significantly
larger.

This scaling is very similar to the scaling I am seeing with only Skia/Raster
in https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15.

Is anyone else seeing this scaling? Or is this a macOS bug that I have found?

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #5 from Patrick Luby  ---
Created attachment 188831
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188831=edit
Scaling of font icons with Skia/Metal on macOS

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

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

2023-08-07 Thread Stephan Bergmann (via logerrit)
 solenv/flatpak-manifest.in |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 96df79630b936c4b908c57c76bac5ee58e2db5ad
Author: Stephan Bergmann 
AuthorDate: Mon Aug 7 08:32:58 2023 +0200
Commit: Stephan Bergmann 
CommitDate: Mon Aug 7 16:04:10 2023 +0200

Sync flatpak-manifest.in with Flathub

...including


"Update gvfs-1.50.5.tar.xz to 1.50.6"

Change-Id: I5b3095d5496c2e9ea0aa428516ee889cb0e7327b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155411
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit 100074948831cc1d26e45d2119aafd58fd8eae3b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155393
Reviewed-by: Michael Stahl 

diff --git a/solenv/flatpak-manifest.in b/solenv/flatpak-manifest.in
index 8839a550548d..d46b98a80882 100644
--- a/solenv/flatpak-manifest.in
+++ b/solenv/flatpak-manifest.in
@@ -49,8 +49,8 @@
 "sources": [
 {
 "type": "archive",
-"url": 
"https://download.gnome.org/sources/gvfs/1.50/gvfs-1.50.5.tar.xz;,
-"sha256": 
"b86f09b7331c8642ecebf46a3cda0692f5eb26086f132326a5483c2ebf86a4cb",
+"url": 
"https://download.gnome.org/sources/gvfs/1.50/gvfs-1.50.6.tar.xz;,
+"sha256": 
"c4f6e11fc4eaa9933f4db8c7a34475e0668cead2bffed96867d061be3d39dda5",
 "x-checker-data": {
 "type": "gnome",
 "name": "gvfs",


[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

Noel Grandin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

Commit Notification  changed:

   What|Removed |Added

 Whiteboard||target:24.2.0

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

[Libreoffice-bugs] [Bug 156629] Font and highlighting color buttons in sidebar have white background after transparency -> alpha change

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=156629

--- Comment #4 from Commit Notification 
 ---
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f69a98d1175720db3b1ce5f5ae2c7fc0fc35a2b2

tdf#156629 Font,highlighting color buttons in sidebar have white background...

It will be available in 24.2.0.

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

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

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

[Libreoffice-commits] core.git: svx/source

2023-08-07 Thread Noel Grandin (via logerrit)
 svx/source/tbxctrls/tbxcolorupdate.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit f69a98d1175720db3b1ce5f5ae2c7fc0fc35a2b2
Author: Noel Grandin 
AuthorDate: Mon Aug 7 14:18:16 2023 +0200
Commit: Noel Grandin 
CommitDate: Mon Aug 7 15:49:24 2023 +0200

tdf#156629 Font,highlighting color buttons in sidebar have white 
background...

..after transparency -> alpha change

regression from
commit 81994cb2b8b32453a92bcb011830fcb884f22ff3
Author: Noel Grandin
Date:   Fri Apr 16 20:33:10 2021 +0200
Convert internal vcl bitmap formats transparency->alpha (II)

Change-Id: Id1a578fcd30a9315fd5910ccdbff5d759cba77fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155425
Tested-by: Jenkins
Reviewed-by: Noel Grandin 

diff --git a/svx/source/tbxctrls/tbxcolorupdate.cxx 
b/svx/source/tbxctrls/tbxcolorupdate.cxx
index edd835736268..970fa40181af 100644
--- a/svx/source/tbxctrls/tbxcolorupdate.cxx
+++ b/svx/source/tbxctrls/tbxcolorupdate.cxx
@@ -213,7 +213,7 @@ namespace svx
 return;
 
 ScopedVclPtr pVirDev(CreateVirtualDevice());
-pVirDev->SetOutputSizePixel(aItemSize);
+pVirDev->SetOutputSizePixel(aItemSize, /*bErase*/true, 
/*bAlphaMaskTransparent*/true);
 maBmpSize = aItemSize;
 
 std::unique_ptr xMetaFile;


[Libreoffice-bugs] [Bug 31480] Find/replace non-printing characters easily

2023-08-07 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=31480

himajin100...@gmail.com changed:

   What|Removed |Added

URL|https://totoghost.com   |

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

[Libreoffice-commits] core.git: Branch 'libreoffice-7-6-0' - download.lst

2023-08-07 Thread Taichi Haradaguchi (via logerrit)
 download.lst |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit bab60c3de24b1952034f51d6155be3ee233ddf6f
Author: Taichi Haradaguchi <20001...@ymail.ne.jp>
AuthorDate: Sun Aug 6 01:57:31 2023 +0900
Commit: Christian Lohmaier 
CommitDate: Mon Aug 7 15:22:06 2023 +0200

openssl: upgrade to release 3.0.10

Change-Id: Iee5716bdd111e2f30cb38d48a86104da52872dd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155382
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001...@ymail.ne.jp>
(cherry picked from commit 72f28e12b15823197e42265af1f8dda21224c90a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155392
Reviewed-by: Xisco Fauli 
(cherry picked from commit 72c058e25bd034645efa1900dc898f065d8175dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155398
Reviewed-by: Michael Stahl 
Tested-by: Christian Lohmaier 
Reviewed-by: Christian Lohmaier 

diff --git a/download.lst b/download.lst
index cd4f75c9d2e4..b9ed3b6e69ef 100644
--- a/download.lst
+++ b/download.lst
@@ -423,8 +423,8 @@ OPENLDAP_TARBALL := openldap-2.6.4.tgz
 # three static lines
 # so that git cherry-pick
 # will not run into conflicts
-OPENSSL_SHA256SUM := 
eb1ab04781474360f77c318ab89d8c5a03abc38e63d65a603cabbf1b00a1dc90
-OPENSSL_TARBALL := openssl-3.0.9.tar.gz
+OPENSSL_SHA256SUM := 
1761d4f5b13a1028b9b6f3d4b8e17feb0cedc9370f6afe61d7193d2cdce83323
+OPENSSL_TARBALL := openssl-3.0.10.tar.gz
 # three static lines
 # so that git cherry-pick
 # will not run into conflicts


[Libreoffice-commits] core.git: Branch 'libreoffice-7-6-0' - bridges/source

2023-08-07 Thread Stephan Bergmann (via logerrit)
 bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit ec30dc5985db4c36a17dd4fa83db3d3aff2c8a20
Author: Stephan Bergmann 
AuthorDate: Thu Aug 3 13:21:44 2023 +0200
Commit: Christian Lohmaier 
CommitDate: Mon Aug 7 15:21:32 2023 +0200

Fix handling of float vs. double values

...which had been broken ever since f424e55b4e66ffbee5b34f45ef5ea18d77c4d15c
"INTEGRATION: CWS sixtyfour11 (1.7.22); FILE MERGED" had merged the
typelib_TypeClass_FLOAT case into the typelib_TypeClass_DOUBLE case, and 
which
caused

> ==612573==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on 
address 0x7fff4e6b0700 at pc 0x7f45a9d77d9e bp 0x7fff4e6af3f0 sp 0x7fff4e6af3e8
> WRITE of size 8 at 0x7fff4e6b0700 thread T0
>  #0 in gcc3::callVirtualMethod(void*, unsigned int, void*, 
_typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, 
unsigned long*, double*) at 
bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:155:51 
(instdir/program/libgcc3_uno.so +0x118d9d)
>  #1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, 
bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, 
_typelib_MethodParameter*, void*, void**, _uno_Any**) at 
bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233:13 
(instdir/program/libgcc3_uno.so +0x112c1e)
>  #2 in unoInterfaceProxyDispatch at 
bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:330:13 
(instdir/program/libgcc3_uno.so +0x10e333)
>  #3 in stoc_corefl::(anonymous 
namespace)::IdlAttributeFieldImpl::get(com::sun::star::uno::Any const&) at 
stoc/source/corereflection/criface.cxx:141:9 
(instdir/program/libreflectionlo.so +0x1f89e0)
>  #4 in non-virtual thunk to stoc_corefl::(anonymous 
namespace)::IdlAttributeFieldImpl::get(com::sun::star::uno::Any const&) at 
stoc/source/corereflection/criface.cxx (instdir/program/libreflectionlo.so 
+0x1fc5fb)
>  #5 in 
cppu::PropertySetMixinImpl::Impl::getProperty(com::sun::star::uno::Reference
 const&, rtl::OUString const&, com::sun::star::beans::PropertyState*) const at 
cppuhelper/source/propertysetmixin.cxx:563:24 
(instdir/program/libuno_cppuhelpergcc3.so.3 +0x7d5059)
>  #6 in cppu::PropertySetMixinImpl::getPropertyValue(rtl::OUString const&) 
at cppuhelper/source/propertysetmixin.cxx:994:20 
(instdir/program/libuno_cppuhelpergcc3.so.3 +0x7e462f)
>  #7 in reportdesign::OFixedText::getPropertyValue(rtl::OUString const&) 
at reportdesign/source/core/api/FixedText.cxx:143:34 
(instdir/program/../program/librptlo.so +0x7452ad)
>  #8 in non-virtual thunk to 
reportdesign::OFixedText::getPropertyValue(rtl::OUString const&) at 
reportdesign/source/core/api/FixedText.cxx 
(instdir/program/../program/librptlo.so +0x7452eb)
>  #9 in 
rptui::OPropertyMediator::OPropertyMediator(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference 
const&, std::__debug::map>, std::less, 
std::allocator&&, bool) at 
reportdesign/source/core/sdr/PropertyForward.cxx:68:119 
(instdir/program/../program/librptlo.so +0xbbbdb7)
>  #10 in rptui::OUnoObject::CreateMediator(bool) at 
reportdesign/source/core/sdr/RptObject.cxx:878:31 
(instdir/program/../program/librptlo.so +0xc16451)
>
> Address 0x7fff4e6b0700 is located in stack of thread T0 at offset 4288 in 
frame
>  #0 in gcc3::callVirtualMethod(void*, unsigned int, void*, 
_typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, 
unsigned long*, double*) at 
bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:50 
(instdir/program/libgcc3_uno.so +0x1181d7)
>
>   This frame has 3 object(s):
> [32, 104) 'data' (line 53)
> [144, 160) 'longs' (line 162)
> [176, 192) 'doubles' (line 166) <== Memory access at offset 4288 
overflows this variable
> HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism, swapcontext or vfork
>   (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:155:51 in 
gcc3::callVirtualMethod(void*, unsigned int, void*, 
_typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, 
unsigned long*, double*)
> Shadow bytes around the buggy address:
>   0x7fff4e6b0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7fff4e6b0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7fff4e6b0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7fff4e6b0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7fff4e6b0680: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
> =>0x7fff4e6b0700:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
>   0x7fff4e6b0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7fff4e6b0800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   

  1   2   >