[Libreoffice-bugs] [Bug 127176] 'Noto Nastaliq Urdu' font does not render correctly when justified.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127176

Nasir  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 109530] [META] File opening issues

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=109530
Bug 109530 depends on bug 122291, which changed state.

Bug 122291 Summary: Issue with files with Persian name
https://bugs.documentfoundation.org/show_bug.cgi?id=122291

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 112810] [META] Arabic language-specific RTL issues

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=112810
Bug 112810 depends on bug 122291, which changed state.

Bug 122291 Summary: Issue with files with Persian name
https://bugs.documentfoundation.org/show_bug.cgi?id=122291

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 122291] Issue with files with Persian name

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=122291

ahangarha  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEEDINFO|RESOLVED

--- Comment #4 from ahangarha  ---
As per my experiment on version: 6.2.6.2, this issue is resolved

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 118991] EDITING. 100% CPU usage after a few minutes with certain documents.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=118991

--- Comment #32 from laur...@norbit.no ---
When the 100% core usage (In reply to laurens from comment #31)
> Created attachment 153833 [details]
> Sample screenshot showing time in function calls when 100% CPU

When the 100% usage occurs, then:

Tools -> Update -> Update All 

Seems to fix it for a while (View -> Web also prevents it from happening, but
is not a solution for general use)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127336] Line wrapping disagreement between LibreOffice and OpenOffice

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127336

V Stuart Foote  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||vstuart.fo...@utsa.edu

--- Comment #4 from V Stuart Foote  ---
Apache OepnOffice through 4.1.6 release has built up a lot of technical debt in
its VCL rendering, one area that is especially true is in it font handling.
Since the 5.3 releases LibreOffice has refactored text layout to use Harfbuzz
and DirectWrite based rendering with OpenGL, with additional rework of GDI
rendering and corrected handling of font metrics.

Even in current LibreOffice--there are differences between OpenGL rendering and
default GDI only rendering (with HA or just CPU) and we have open issues to
improve both rendering modes.

Also, Apache OpenOffice does not support OpenGL rendering in any sense, so
comparing a 6.2.5 release of LibreOFfice in OpenGL mode, to a 4.1.6 release of
AOO is never going to produce matching layouts. You would need to test against
a 5.2.6 release, or earlier, of LibreOffice with default rendering to even
attempt a comparison. And if an issue were identified it would likely be a
WONTFIX, those builds are EOL.

The issue as presented with STR are invalid.

IMHO => INVALID

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] core.git: sw/uiconfig

2019-09-04 Thread Aron Budea (via logerrit)
 sw/uiconfig/swriter/menubar/mscompatibleformsmenu.xml |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

New commits:
commit 0f3fb26e7622f99560c6514f4b3ae663636025c9
Author: Aron Budea 
AuthorDate: Thu Sep 5 04:12:21 2019 +0200
Commit: Aron Budea 
CommitDate: Thu Sep 5 05:31:03 2019 +0200

MSForms: Reorder categories in menu

so it matches MSO's order: content controls,
 legacy form controls, ActiveX controls

Change-Id: I348e49fe9118c397c18812a79c23aa89ab635a70
Reviewed-on: https://gerrit.libreoffice.org/78619
Tested-by: Jenkins
Reviewed-by: Aron Budea 

diff --git a/sw/uiconfig/swriter/menubar/mscompatibleformsmenu.xml 
b/sw/uiconfig/swriter/menubar/mscompatibleformsmenu.xml
index c9f2c0884754..6be7228ded4d 100644
--- a/sw/uiconfig/swriter/menubar/mscompatibleformsmenu.xml
+++ b/sw/uiconfig/swriter/menubar/mscompatibleformsmenu.xml
@@ -13,14 +13,9 @@
   
   
   
-  
+  
 
-  
-  
-  
-  
-  
-  
+  
 
   
   
@@ -30,9 +25,14 @@
   
 
   
-  
+  
 
-  
+  
+  
+  
+  
+  
+  
 
   
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-bugs] [Bug 125610] More Characters button is unreadable on macOS

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125610

Adolfo Jayme  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|libreoffice-b...@lists.free |xiscofa...@libreoffice.org
   |desktop.org |
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 108660] [META] Formula bar (input line) bugs and enhancements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108660
Bug 108660 depends on bug 127066, which changed state.

Bug 127066 Summary: UI: Font size in input line (formular bar) larger than in 
other UI elements
https://bugs.documentfoundation.org/show_bug.cgi?id=127066

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127066

Adolfo Jayme  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127066

--- Comment #10 from Commit Notification 
 ---
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/e757a88f5141a2816d6c69bff5234c9f8802c79a%5E%21

tdf#127066 Font size of Calc input bar aligned to UI font size

It will be available in 6.4.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 on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127066

Commit Notification  changed:

   What|Removed |Added

 Whiteboard||target:6.4.0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

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

2019-09-04 Thread Thorsten Wagner (via logerrit)
 sc/source/ui/app/inputwin.cxx |3 ---
 1 file changed, 3 deletions(-)

New commits:
commit e757a88f5141a2816d6c69bff5234c9f8802c79a
Author: Thorsten Wagner 
AuthorDate: Mon Aug 26 15:18:51 2019 +0200
Commit: Adolfo Jayme Barrientos 
CommitDate: Thu Sep 5 05:14:26 2019 +0200

tdf#127066 Font size of Calc input bar aligned to UI font size

Change-Id: I1f1aa4195c4b4be8987b0686d3f157ecea3fecce
Reviewed-on: https://gerrit.libreoffice.org/78140
Tested-by: Jenkins
Reviewed-by: Heiko Tietze 
Tested-by: Heiko Tietze 

diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index 3d0f598d902f..3d77c561468e 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -75,7 +75,6 @@ namespace com::sun::star::accessibility { class XAccessible; }
 
 const long THESIZE = 100;// Should be more than enough!
 const long INPUTLINE_INSET_MARGIN = 2;   // Space between border and interior 
widgets of input line
-const long MIN_FONT_SIZE = 16;   // Minimum font size of input line in 
pixels
 const long LEFT_OFFSET = 5;  // Left offset of input line
 const long BUTTON_OFFSET = 2;// Space between input line and 
button to expand/collapse
 const long MULTILINE_BUTTON_WIDTH = 20;  // Width of the button which opens 
multiline dropdown
@@ -1440,8 +1439,6 @@ ScTextWnd::ScTextWnd(ScTextWndGroup* pParent, 
ScTabViewShell* pViewSh)
 vcl::Font aAppFont = GetFont();
 aTextFont = aAppFont;
 Size aFontSize = aAppFont.GetFontSize();
-if (aFontSize.Height() < MIN_FONT_SIZE)
-aFontSize.setHeight(MIN_FONT_SIZE);
 aTextFont.SetFontSize(PixelToLogic(aFontSize, MapMode(MapUnit::MapTwip)));
 
 const StyleSettings& rStyleSettings = 
Application::GetSettings().GetStyleSettings();
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-bugs] [Bug 125610] More Characters button is unreadable on macOS

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125610

Commit Notification  changed:

   What|Removed |Added

 Whiteboard|target:6.4.0|target:6.4.0 target:6.3.2

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 125610] More Characters button is unreadable on macOS

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125610

--- Comment #7 from Commit Notification 
 ---
Xisco Faulí committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/ab5da884b16aa54aab8e9773a6e8dbf24e752c36%5E%21

tdf#125610: Revert "tdf#125088 Make button text white for blue buttons on
macOS"

It will be available in 6.3.2.

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

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] core.git: Branch 'libreoffice-6-3' - vcl/source

2019-09-04 Thread Xisco Faulí (via logerrit)
 vcl/source/control/button.cxx |   10 --
 1 file changed, 10 deletions(-)

New commits:
commit ab5da884b16aa54aab8e9773a6e8dbf24e752c36
Author: Xisco Faulí 
AuthorDate: Wed Sep 4 16:22:10 2019 +0200
Commit: Adolfo Jayme Barrientos 
CommitDate: Thu Sep 5 05:08:43 2019 +0200

tdf#125610: Revert "tdf#125088 Make button text white for blue buttons on 
macOS"

This reverts commit 89775fd396e413daaf0e71710211075450bdc0ed.

Change-Id: I0ddbd454e53bcd442fdf2330661136e041c7d260
Reviewed-on: https://gerrit.libreoffice.org/78611
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/vcl/source/control/button.cxx b/vcl/source/control/button.cxx
index 15f80be207b6..146b6402a7f4 100644
--- a/vcl/source/control/button.cxx
+++ b/vcl/source/control/button.cxx
@@ -812,16 +812,6 @@ void PushButton::ImplDrawPushButtonContent(OutputDevice* 
pDev, DrawFlags nDrawFl
 
 if ( nDrawFlags & DrawFlags::Mono )
 aColor = COL_BLACK;
-#ifdef MACOSX
-else if ((nButtonFlags & DrawButtonFlags::Default) && !(GetStyle() & 
WB_FLATBUTTON))
-{
-// Make text color white if the button is a default control on macOS.
-// Without this you get a button with a blue background and blue text
-// which stands out as not looking right on macOS where default buttons
-// have white text and a blue background.
-aColor = COL_WHITE;
-}
-#endif
 else if( (nButtonFlags & DrawButtonFlags::Highlight) && 
IsNativeControlSupported(ControlType::Pushbutton, ControlPart::Entire) )
 {
 if (nButtonFlags & DrawButtonFlags::Pressed)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

2019-09-04 Thread Xisco Faulí (via logerrit)
 vcl/source/control/button.cxx |   10 --
 1 file changed, 10 deletions(-)

New commits:
commit ebd7af9aebb5b76255aa299dd8047cb4266215a4
Author: Xisco Faulí 
AuthorDate: Wed Sep 4 16:22:10 2019 +0200
Commit: Adolfo Jayme Barrientos 
CommitDate: Thu Sep 5 05:02:52 2019 +0200

tdf#125610: Revert "tdf#125088 Make button text white for blue buttons on 
macOS"

This reverts commit 89775fd396e413daaf0e71710211075450bdc0ed.

Change-Id: I0ddbd454e53bcd442fdf2330661136e041c7d260
Reviewed-on: https://gerrit.libreoffice.org/78605
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/vcl/source/control/button.cxx b/vcl/source/control/button.cxx
index 4c18207e0844..91141d35cc4e 100644
--- a/vcl/source/control/button.cxx
+++ b/vcl/source/control/button.cxx
@@ -795,16 +795,6 @@ void PushButton::ImplDrawPushButtonContent(OutputDevice* 
pDev, DrawFlags nDrawFl
 
 if ( nDrawFlags & DrawFlags::Mono )
 aColor = COL_BLACK;
-#ifdef MACOSX
-else if ((nButtonFlags & DrawButtonFlags::Default) && !(GetStyle() & 
WB_FLATBUTTON))
-{
-// Make text color white if the button is a default control on macOS.
-// Without this you get a button with a blue background and blue text
-// which stands out as not looking right on macOS where default buttons
-// have white text and a blue background.
-aColor = COL_WHITE;
-}
-#endif
 else if( (nButtonFlags & DrawButtonFlags::Highlight) && 
IsNativeControlSupported(ControlType::Pushbutton, ControlPart::Entire) )
 {
 if (nButtonFlags & DrawButtonFlags::Pressed)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-bugs] [Bug 125610] More Characters button is unreadable on macOS

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125610

--- Comment #6 from Commit Notification 
 ---
Xisco Faulí committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/ebd7af9aebb5b76255aa299dd8047cb4266215a4%5E%21

tdf#125610: Revert "tdf#125088 Make button text white for blue buttons on
macOS"

It will be available in 6.4.0.

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

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 125610] More Characters button is unreadable on macOS

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125610

Commit Notification  changed:

   What|Removed |Added

 Whiteboard||target:6.4.0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127351] New: Example python script not execute

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127351

Bug ID: 127351
   Summary: Example python script not execute
   Product: LibreOffice
   Version: 6.3.1.1 rc
  Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
  Severity: minor
  Priority: medium
 Component: Documentation
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: pub...@elmau.net
CC: olivier.hal...@libreoffice.org

Description:
The example:
https://help.libreoffice.org/6.3/en-US/text/sbasic/python/python_shell.html?=BASIC=UNIX

Only work if LibreOffice is installed manuality, but not, if used the version
of the distribution, because generally this versions used the Python Core the
system, for this case:

import subprocess

def interpreter_console():
subprocess.Popen('python')  
return

Steps to Reproduce:
Only if used LibreOffice of the distribution

1. Copy and paste script
2. Execute

Actual Results:
Error: FileNOtFoundError

Expected Results:
Show interpreter console


Reproducible: Always


User Profile Reset: No



Additional Info:
Example:
https://help.libreoffice.org/6.3/en-US/text/sbasic/python/python_shell.html?=BASIC=UNIX

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127241] date format not saved properly

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127241

--- Comment #12 from tor...@yahoo.com ---
Created attachment 153888
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153888=edit
file with date mm/dd/

The behaviour is the same whether the date is 'fixed' or not.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127307] odt document bookmarks disappear if saved as HTML

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127307

--- Comment #4 from kevin seslar  ---
OK, I have to install LOv3 on a different computer because I can't get my main
machines oos with v3 - so this will take awhile.  It's going to take 4 files,
the before and after picture i.e. before odt file and after html file; that is
one of each from v2.6 and one of each from v3.  Let me work on it.  Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127350] New: An improvement by adding a Calc File menu item 'Save and Close'.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127350

Bug ID: 127350
   Summary: An improvement by adding a Calc File menu item 'Save
and Close'.
   Product: LibreOffice
   Version: 6.3.0.4 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: enhancement
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: dominicjos...@gmail.com

Description:
Add a File menu item to Calc (and all apps) called 'Save and Close'.  This
would save a step every time one closes a file, as currently it is a 2 step
process, IE 'Save' then 'Close'.

Actual Results:
Will save and close in one step.

Expected Results:
Will save and close in one step.


Reproducible: Always


User Profile Reset: No



Additional Info:

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 122370] Style Heading 1 is not applied to content nor option Numeric with all sublevels is applied to Headings whose levels are superior to level 1.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=122370

--- Comment #11 from Emersson Augusto Suarez Ortiz  ---
Please don't give attention, I'm so naive, forget the 9 and 10 entries.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 65321] EDITING: Excess drawing area interferes with OLE importing of drawings into other docs

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=65321

--- Comment #14 from Jim Avera  ---
Problem still there in master as of Sept. 3, 2019

ersion: 6.4.0.0.alpha0+
Build ID: 4a63d78ded7b11c7b820d2c941a0c9aed18326fc
CPU threads: 12; OS: Linux 5.0; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time:
2019-09-03_04:42:45
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] core.git: Changes to 'refs/tags/cib-6.1-4'

2019-09-04 Thread Thorsten Behrens (via logerrit)
Tag 'cib-6.1-4' created by Thorsten Behrens  at 
2019-09-04 23:01 +

Release LibreOffice powered by CIB 6.1-4
-BEGIN PGP SIGNATURE-

iQKTBAABCgB9FiEEHp/al2IcD3tw8LrPZ7OyyFo1BNkFAl1wQjlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFF
OUZEQTk3NjIxQzBGN0I3MEYwQkFDRjY3QjNCMkM4NUEzNTA0RDkACgkQZ7OyyFo1
BNkrLA/+O91X9/jqg0IUqaJH6SPPxspYrzUmnyC4qzCv5OH4hHjhYaVaFIu3ZN3t
V0f6M3cq3ctXHsQtx4E8TvflRXvcqrUDA7pqoorLfSusZKUjAtgL9LA8/8J1/k2w
Ckf4+gT4FdTZDMk/Y8akivJdm+qZTYbEPzmBOBu6svGwSa8K6Ovsnk5NqYM5/03k
tK+LEKg4QE6kwD85x29Co2ABfBbHdz04VUoWQNp6ls2r6D9chIV0FjeKZMjQgylc
A3ws55Q4vHnyUGH5P6M3QLGsQrdDNQoGzbOlMriB3Wyr8P7UFCPhejdGJPJIaNbU
0X/C2nHddiNzuZRr6kHzTFaAp/x5EkEWom2znIOV6Os80ddac2OR7ICSSgmvWVTX
YVIDeyfYK2kG/VElUD8hro4karKY68Zu2d3/90LXzPy4RMMj7xzmzuSLDSmAGgIU
ZLC+9x9D/nbDaeKOumeiwzaNhCe0zarNf+lQOcXTRBeY5/ZzOLLY3kzn3P+ErGl/
vR0ffGcFlkZd/8O1IPivNGmh0k1L/rfTbUf+fxMYzqM5gezFSYNo3ZRnNJNLJ9m6
UvzerMpWPqzmEi0DuI0PfvgZAC9k4qAe6zQak5eCfzUCKsu4ofU+uVA+Vx1drd8R
fMZIWtcT0rf0k7oJ77O/okA/PIbOGahOcSb0Cx3XSEmxRWSK7n4=
=ZCSk
-END PGP SIGNATURE-

Changes since cib-6.1-3-3:
---
 0 files changed
---
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: Branch 'distro/cib/libreoffice-6-1' - configure.ac

2019-09-04 Thread Thorsten Behrens (via logerrit)
 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 1e4f39b3053314da8df368fa677526bda02eeba4
Author: Thorsten Behrens 
AuthorDate: Thu Sep 5 00:57:21 2019 +0200
Commit: Thorsten Behrens 
CommitDate: Thu Sep 5 00:57:57 2019 +0200

Bump version to 6.1.7.4

Change-Id: I786ad16e362edf2546c0783b64188f4ffb4c997e

diff --git a/configure.ac b/configure.ac
index 93e280a19074..0b3c2f61b7b4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,7 +9,7 @@ dnl in order to create a configure script.
 # several non-alphanumeric characters, those are split off and used only for 
the
 # ABOUTBOXPRODUCTVERSIONSUFFIX in openoffice.lst. Why that is necessary, no 
idea.
 
-AC_INIT([LibreOffice powered by 
CIB],[6.1.7.3],[],[],[https://libreoffice.cib.eu/])
+AC_INIT([LibreOffice powered by 
CIB],[6.1.7.4],[],[],[https://libreoffice.cib.eu/])
 
 AC_PREREQ([2.59])
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-bugs] [Bug 127348] New: Improve use of line dash definitions with rounded dots/dashes

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127348

Bug ID: 127348
   Summary: Improve use of line dash definitions with rounded
dots/dashes
   Product: LibreOffice
   Version: 6.4.0.0.alpha0+ Master
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
  Keywords: needsUXEval
  Severity: enhancement
  Priority: medium
 Component: LibreOffice
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: rb.hensc...@t-online.de

I write this as issue, because first the goal has to be clear before any
changes in code are down.


The ODF standard defines the element . This has the
attributes: name, display-name, style, dots1, dots1-length, dots2,
dots2-length, distance. For the attribute 'style' the values 'round' and 'rect'
are possible. The lengths can be absolute or a percentage relative to the line
width. The line dash definitions in a foo.sod palette are written using the ODF
standard.

This would fit perfectly to our API structure 'LineDash'. This has the
components Style, Dots, DotLen, Dashes, DashLen, Distance where Style is a
com::sun::star::drawing::DashStyle. This is an enum with the values RECT,
ROUND, RECTRELATIVE, ROUNDRELATIVE.

But LibreOfffice determines whether a dash is rounded or square/flat not from
DashStyle, but from the LineCap line property. LibreOffice is not alone in
this, but OOXML and SVG also act in this way. Nevertheless the core works with
the structure 'LineDash'.

This leads to the following problems:

A) If the user applies a line dash definition that contains style="round" from
a palette, the dashes are not rounded. That prevents to provide a line style
with round points in the sidebar, for example. The sidebar has no section to
set the line cap.

B) If in a file only the stroke-dash definition contains the attribute
draw:style="round", but the object does not have the line property
svg:stroke-linecap="round", then the dashes are not rounded (tdf#53276).

C) If an object has the line property cap="round", but the stroke-dash
definition in the current palette has draw:style="rect", the palette entry is
not found and is not available in the dialogs, even if all other properties
fit. Exception is our own palette standard.sod.

How can the two concepts LineCap vs LineDash.Style be brought together?

My ideas to improve the situation:

If the user assigns a dash definition with draw:style="round" to an object via
sidebar, the line property linecap="round" is automatically set. The preview in
the sidebar shows the style as if linecap="round" is already set.

The line style dialog is changed, so that it sets the linecap to "round", if a
definition with draw:style="round" is selected, and disables the linecap
drop-down for such definitions. That would not effect our standard.sod palette,
because it has only definitions with draw:style="rect".

Keep the possibility to set a round cap for styles in standard.sod, although
our standard.sod has only draw:style="rect" definitions. But an author of a
custom palette has to provide all definitions in a "rect" and in a "round"
version, so that they will be found, regardless of whether the user has set
linecap to "round" or "square"/"flat". To keep the list of styles short for
custom palettes, the dialog can have an option to show either styles with
"round" or "rect" in case of custom palettes. But such would be a question of
design.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127347] Libre Office (6.3.0.4) Draw -> PDF export shows squared fills on non-transparent circles and ellipses if one object anywhere has a "transparent fill" set

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127347

Eick  changed:

   What|Removed |Added

Summary|Libre Office (6.3.0) Draw   |Libre Office (6.3.0.4) Draw
   |-> PDF export shows squared |-> PDF export shows squared
   |fills on non-transparent|fills on non-transparent
   |circles and ellipses if one |circles and ellipses if one
   |object has a "transparent   |object anywhere has a
   |fill"   |"transparent fill" set

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127170] The German documentation for time formats does not explain formatting differences of durations and wall clock time.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127170

--- Comment #4 from Albrecht Müller  ---
(In reply to Eike Rathke from comment #3)
> 
> This is a bit nasty as using both the [MM] and the M codes in one format
> seems to trick out the type detection, i.e. after defining it the format at
> ...

I don't really care if this behaviour is a bug or not as this is a bug report
against the documentation and not against a particular behaviour of Calc. The
key problem here is that the help function does not specify how to deal with
ambiguous format strings: Should Calc consider these strings as illegal and
treat them as an error?  Or should it use some default interpretation? How to
deal with a situation where you want minutes values at position where Calc
would interpret it as month value? What are the exact rules to resolve the
ambiguities?

I stumbled over this problem when I found your comment
https://bugs.documentfoundation.org/show_bug.cgi?id=125099#c8 and tried to find
out the difference between "[HH]" and "HH" in the context of duration and wall
clock time. The help information
https://help.libreoffice.org/6.3/en-US/text/shared/01/05020301.html?DbPAR=SHARED#hd_id3155870
states that "HH" are between 00 and 23 while "[HH]" may deliver values above
23. It says nothing about durations or wall clock time, and nothing about
possibly different rounding behaviour. I think this is a defect in the
documentation - users cannot know the kind of difference you mention in your
comment.

Date/time calculations are tricky. A special problem is that these calculations
normally use integral quantities of time units and therefore exact calculations
are possible. Calc represents date/time values as float numbers. One day
corresponds to the value of one. Hours, minutes and seconds correspond to
values less than one. In general, points in time that correspond to a
combination of integral numbers of hours, minutes and seconds have no exact
representation as floating point values. Therefore date/time calculations
usually contain round-off errors. Nevertheless all spreadsheet programs I used
so far - including LibreOffice up to version 6.0.4.2 - delivered exact values
when I did some simple date/time calculations. There is a defect in the help
function as it does not specify how Calc is expected to handle date/time
calculations, i.e. the behaviour of date/time calculations is undefined. A
nasty consequence of this fact is a recent change the date/time calculation
algorithm. This algorithm used to deliver a difference of one minute if you
subtracted two timestamps that were one minute apart. The new algorithm returns
essentially a random value which is 0 or 1 minute with about 50% probability
each (see bug 127334) which breaks all legacy spreadsheets that contain this
kind of calculations. As the user documentation does not specify a correct
behaviour the behaviour of the new algorithm can be classified as "NOTABUG".

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127349] Libre Office (6.3.0.4) Draw -> PDF export shows black fills on non-transparent objects that are behind or too close (circles and ellipses) to a transparent one

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127349

--- Comment #1 from Eick  ---
Created attachment 153887
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153887=edit
generated PDF export showcasing problems

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 75923] EDITING: Spelling and Grammar: English - "Always Correct" button is undocumented and nonfunctional

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=75923

--- Comment #14 from MartinPC  ---
(In reply to MartinPC from comment #13)

> I've been using word processors since WordStar for DOS and it took
> me an *unreasonably* long time to figure out what the "Always Correct"
> button was actually doing.

One more correction: I've been using word processors since WordStar for *CP/M*,
not DOS! I really *am* getting to be an old-timer!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127324] Search-Function: Make comments searchable by default, if shown.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127324

Thomas Lendo  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 127324] Search-Function: Make comments searchable by default, if shown.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127324

Thomas Lendo  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 125974] New bug: Searching in comments doesn't work

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125974

Thomas Lendo  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 125974] New bug: Searching in comments doesn't work

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=125974

Thomas Lendo  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 127349] New: Libre Office (6.3.0.4) Draw -> PDF export shows black fills on non-transparent objects that are behind or too close (circles and ellipses) to a transparent one

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127349

Bug ID: 127349
   Summary: Libre Office (6.3.0.4) Draw -> PDF export shows black
fills on non-transparent objects that are behind or
too close (circles and ellipses) to a transparent one
   Product: LibreOffice
   Version: 6.3.0.4 release
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Printing and PDF export
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: eick.robe...@gmail.com

Description:
Libre Office (6.3.0.4) Draw
System: Windows 10

Step 1 -> launch Draw and draw a couple of circles, ellipses and other rounded
shapes, and a square, making sure to space them all well fro one another.

Step 2 -> apply colored fills to all of any types (eg. single color, 2-color
radial or linear, etc.)

Step 3 -> put two rounded objects diagonally close without touching or overlap
them in any way (one partly on top of other). In one of them set the fill to
transparent, and make it overlap the other (drawing order on top)

Step 4 -> export to PDF, open PDF see the false black fills on the rounded
objects that have no transparency.

Steps to Reproduce:
1. launch Draw and draw a couple of circles, ellipses and other rounded shapes,
making sure to space them all well from one another.

2. apply colored fills to all of any types (eg. single color, 2-color radial or
linear, etc.)

3. put two rounded objects diagonally close without touching or overlap
(touching) them in any way (one partly on top of other). In one of them set the
fill to transparent, and make it overlap the other (drawing order on top)

4. export to PDF, open PDF see the false black fills on the rounded objects
that have no transparency.

Actual Results:
non-transparent objects drawn close (in case of circles and ellipses) or behind
a transparent filled object have their fill changed to black.

Expected Results:
Expected to keep the correct fill colors on such situations.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Software should work better with transparent objects close or overlapping
non-transparent ones especially in case of circles and ellipses.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127347] Libre Office (6.3.0) Draw -> PDF export shows squared fills on non-transparent circles and ellipses if one object has a "transparent fill"

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127347

--- Comment #1 from Eick  ---
Created attachment 153886
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153886=edit
drawing file 1

this is the PDF export of a described drawing

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127347] New: Libre Office (6.3.0) Draw -> PDF export shows squared fills on non-transparent circles and ellipses if one object has a "transparent fill"

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127347

Bug ID: 127347
   Summary: Libre Office (6.3.0) Draw -> PDF export shows squared
fills on non-transparent circles and ellipses if one
object has a "transparent fill"
   Product: LibreOffice
   Version: 6.3.0.4 release
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Printing and PDF export
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: eick.robe...@gmail.com

Description:
Libre Office (6.3.0.4) Draw
System: Windows 10

Step 1 -> launch Draw and draw a couple of circles, ellipses and other rounded
shapes, and a square, making sure not to overlap any of them
Step 2 -> apply fills to all of many types (eg. single color, 2-color radial or
linear, etc.)
Step 3 -> select one of the object and set fill transparency to 50%, leave
others intact
Step 4 -> export to PDF, open PDF see the squared overlapping fills on the
rounded objects

Steps to Reproduce:
1. launch Draw and draw a couple of circles, ellipses and other rounded shapes,
and a square, making sure not to overlap any of them
2. apply fills to all of many types (eg. single color, 2-color radial or
linear, etc.)
3. select one of the object and set fill transparency to 50%, leave others
intact
4. export to PDF, open PDF see the squared overlapping fills on the rounded
objects

Actual Results:
The PDF export shows squared overlapping fills on the rounded objects. Note
that as described in step 1 all objects must be spaced a little from one
another.

Expected Results:
The fills of any object should be contained inside the object, not extrapolate
over its limits.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] online.git: test/WhiteBoxTests.cpp

2019-09-04 Thread DarkByt31 (via logerrit)
 test/WhiteBoxTests.cpp |4 
 1 file changed, 4 insertions(+)

New commits:
commit d24071e91bbfbc8ef3cd5eedc1d1179db6a5a1a0
Author: DarkByt31 
AuthorDate: Wed Sep 4 22:04:36 2019 +0530
Commit: Michael Meeks 
CommitDate: Wed Sep 4 22:09:50 2019 +0100

WhiteBoxTests: testTime corrections

Change-Id: Ia73a69396ba12921370fa12b57c249593c36e3d8

diff --git a/test/WhiteBoxTests.cpp b/test/WhiteBoxTests.cpp
index 35c6faf5b..e3a6d52a8 100644
--- a/test/WhiteBoxTests.cpp
+++ b/test/WhiteBoxTests.cpp
@@ -40,6 +40,7 @@ class WhiteBoxTests : public CPPUNIT_NS::TestFixture
 CPPUNIT_TEST(testAuthorization);
 CPPUNIT_TEST(testJson);
 CPPUNIT_TEST(testAnonymization);
+CPPUNIT_TEST(testTime);
 
 CPPUNIT_TEST_SUITE_END();
 
@@ -746,16 +747,19 @@ void WhiteBoxTests::testTime()
 oss << t.time_since_epoch().count();
 CPPUNIT_ASSERT_EQUAL(std::string("1567444337874777000"), oss.str());
 
+oss.str(std::string());
 t = Util::iso8601ToTimestamp("1970-01-01T00:00:00.00Z", 
"LastModifiedTime");
 oss << t.time_since_epoch().count();
 CPPUNIT_ASSERT_EQUAL(std::string("0"), oss.str());
 
+oss.str(std::string());
 t = std::chrono::system_clock::now();
 uint64_t t_in_micros = (t.time_since_epoch().count() / 1000) * 1000;
 oss << t_in_micros;
 std::string first = oss.str();
 std::string s = Util::getIso8601FracformatTime(t);
 t = Util::iso8601ToTimestamp(s, "LastModifiedTime");
+oss.str(std::string());
 oss << t.time_since_epoch().count();
 CPPUNIT_ASSERT_EQUAL(first, oss.str());
 }
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-ux-advise] [Bug 93111] Feature Request: Custom Style Group

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=93111

Cor Nouws  changed:

   What|Removed |Added

Version|4.0.1.2 release |Inherited From OOo

--- Comment #9 from Cor Nouws  ---
It is amazing how many interesting and also useful ideas are brought to us by
users. Kudos :) !

The requested situation (see
https://bug-attachments.documentfoundation.org/attachment.cgi?id=153845 ) could
partly be reached by having templates with custom styles that are needed. But
then the desired ones of the styles that are available by default, would not be
in the same list..

So if someone sees the challenge and the time: +1 from me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 93111] Feature Request: Custom Style Group

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=93111

Cor Nouws  changed:

   What|Removed |Added

Version|4.0.1.2 release |Inherited From OOo

--- Comment #9 from Cor Nouws  ---
It is amazing how many interesting and also useful ideas are brought to us by
users. Kudos :) !

The requested situation (see
https://bug-attachments.documentfoundation.org/attachment.cgi?id=153845 ) could
partly be reached by having templates with custom styles that are needed. But
then the desired ones of the styles that are available by default, would not be
in the same list..

So if someone sees the challenge and the time: +1 from me.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 126938] Add shortcuts for accepting and rejecting changes

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=126938

Cor Nouws  changed:

   What|Removed |Added

Version|6.3.0.4 release |unspecified
 CC||c...@nouenoff.nl

--- Comment #4 from Cor Nouws  ---
yes, if customizing by the user is possible for these, I would not make default
ones (which are not available indeed). Esp. since many times jumping fast from
one to another is not how it works. And after all the dialog to manage tracked
changes, is rather fast & handy too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 126938] Add shortcuts for accepting and rejecting changes

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=126938

Cor Nouws  changed:

   What|Removed |Added

Version|6.3.0.4 release |unspecified
 CC||c...@nouenoff.nl

--- Comment #4 from Cor Nouws  ---
yes, if customizing by the user is possible for these, I would not make default
ones (which are not available indeed). Esp. since many times jumping fast from
one to another is not how it works. And after all the dialog to manage tracked
changes, is rather fast & handy too.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 127280] Toggle baseline grid from menu

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127280

Cor Nouws  changed:

   What|Removed |Added

Version|unspecified |Inherited From OOo
 CC||c...@nouenoff.nl

--- Comment #6 from Cor Nouws  ---
if time allows.. would be a good improvement. I remember moments that I miss
it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 127280] Toggle baseline grid from menu

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127280

Cor Nouws  changed:

   What|Removed |Added

Version|unspecified |Inherited From OOo
 CC||c...@nouenoff.nl

--- Comment #6 from Cor Nouws  ---
if time allows.. would be a good improvement. I remember moments that I miss
it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127279] Register-true with better labelling

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127279

Cor Nouws  changed:

   What|Removed |Added

Version|unspecified |Inherited From OOo
 CC||c...@nouenoff.nl

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 127279] Register-true with better labelling

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127279

Cor Nouws  changed:

   What|Removed |Added

Version|unspecified |Inherited From OOo
 CC||c...@nouenoff.nl

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 127241] date format not saved properly

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127241

Dieter Praas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEEDINFO

--- Comment #11 from Dieter Praas  ---
(In reply to TorrAB from comment #2)
> Created attachment 153767 [details]
> file with date

Date in file has format -mm-dd, so it's not possible to folow the steps
from bug report. Please attach a document with date format mm/dd/

=> NEEDINFO

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: About putting back Firebird experimental

2019-09-04 Thread Terrence Enger
On Wed, 2019-09-04 at 16:59 +0200, Alexander Thurgood wrote:
> 
> I feel we would do well to remember
that this is people's live and
> valuable data we are potentially messing with here, and not all of
these
> users are DBAs, in fact rather the contrary. It matters not a jot that
> db engine XYZ can
outperform db engine ABC under circumstance PQR if the
> data that the user originally had gets
screwed up, or if the yearbook,
> contacts with photos, or multilingual accounts DB they were running
no
> longer functions correctly, or at all, they won't forgive us for it.

Indeed, I shudder to think what a customer of mine would have done if
I had given them a database conversion with the problems seen in the
conversion we are offering.

(To be fair, my commercial work was easier: I was always converting
one particular database.  And knowledge of the business process and
the customer's goal usually combined to make it pretty obvious how to
handle an infelicity which in the general case would be a problem
without a good solution.)

Still, as always, we can only do what we can do.  The most important
thing we can do is to not surprise the user.  I think we should try
very hard to avoid this grave sin.

To that end, I propose a pre-conversion report showing the problems
which will arise in the conversion of a particular database.  In the
case of a declared-too-long VARCHAR column, the report would show the
afflicted table and column name.  For each such column it would also
show the key values of--let us say--up to three rows where the value
actually stored is too long for Firebird.  And so forth.

I make this proposal diffidently, as it involves more work than I can
do.  I invite your thoughts.

Terry.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 102847] [META] Quick Find, Search and Replace

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=102847

Dieter Praas  changed:

   What|Removed |Added

 Depends on||127324


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127324
[Bug 127324] Search-Function: Make comments searchable by default, if shown.
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-ux-advise] [Bug 127324] Search-Function: Make comments searchable by default, if shown.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127324

Dieter Praas  changed:

   What|Removed |Added

 CC||dgp-m...@gmx.de,
   ||libreoffice-ux-advise@lists
   ||.freedesktop.org
 Blocks||106179, 102847
   Keywords||needsUXEval

--- Comment #1 from Dieter Praas  ---
I support the proposal

cc: Design Team


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=102847
[Bug 102847] [META] Quick Find, Search and Replace
https://bugs.documentfoundation.org/show_bug.cgi?id=106179
[Bug 106179] [META] Writer comment bugs and enhancements
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-bugs] [Bug 106179] [META] Writer comment bugs and enhancements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=106179

Dieter Praas  changed:

   What|Removed |Added

 Depends on||127324


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127324
[Bug 127324] Search-Function: Make comments searchable by default, if shown.
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127324] Search-Function: Make comments searchable by default, if shown.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127324

Dieter Praas  changed:

   What|Removed |Added

 CC||dgp-m...@gmx.de,
   ||libreoffice-ux-advise@lists
   ||.freedesktop.org
 Blocks||106179, 102847
   Keywords||needsUXEval

--- Comment #1 from Dieter Praas  ---
I support the proposal

cc: Design Team


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=102847
[Bug 102847] [META] Quick Find, Search and Replace
https://bugs.documentfoundation.org/show_bug.cgi?id=106179
[Bug 106179] [META] Writer comment bugs and enhancements
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: manually changing content.xml > invalid xml.. but why

2019-09-04 Thread Cor Nouws
Hi Eike, Regina,

Thanks for the answers.. Solved.

Eike Rathke wrote on 9/4/19 8:26 PM:

> How do you re-zip the file?

Let me elaborate. It is far from the first time that I unzip an odf
fully, change something, and then rezip.
Never had any problem. Might just have been lucky :)

> Best is to freshen the zip with just the
> content.xml to keep the original file order and compression, i.e. the
> 'mimetype' file MUST be the first entry in the zip archive and MUST NOT
> be compressed. So,
> 
>   zip -f filename.ods content.xml
> 
> should do.

Indeed, that helps. (Notably the Gnome archive manager allows to open
one file to edit and have it refreshed after closing the editor - this
is similar to what Regina writes).

> If that doesn't help then it's something different ("invalid
> xml" is a vague description).

"The file XXX is corrupt and therefore cannot be opened. ..."
The invalid xml notice is something that is shown in the emacs status.
But appears to be a red herring to me now. Especially since that notice
appears without doing anything in the file. Prolly checked against
another xml schema.

Cor

-- 
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger https://nl.libreoffice.org
- volunteer https://www.libreoffice.org
- Member Board The Document Foundation
- http://www.nouenoff.nl / https://www.mijncloudoffice.nl
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 127307] odt document bookmarks disappear if saved as HTML

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127307

Dieter Praas  changed:

   What|Removed |Added

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

--- Comment #3 from Dieter Praas  ---
(In reply to Julien Nabet from comment #2)
> Would it be possible you attach an odt file example so we can try to
> reproduce this quickly?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive
information before attaching it)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127323] Cannot Ungroup

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127323

--- Comment #5 from m.a.riosv  ---
Or maybe the shortcut it's captured by the system or another program.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 68327] SVG: draw:glue-points cannot be defined outside svg:viewbox

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=68327

--- Comment #15 from Laurent BP  ---
I can confirm behavior described in comment 13 with
- Version: 6.3.0.4
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
Threads CPU : 8; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
- Version: 6.4.0.0.alpha0+
Build ID: 1a999aa44f236c662fbf7ca6f6c23b7966ec13a9
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

security warning now additionally on *calling* scripts/macros

2019-09-04 Thread Caolán McNamara
Documents that contain macros trigger LibreOffice to present the
warning dialog that the document contains macros, and by default then
not allow the document to execute macros.

But documents that don't contain macros, but *call* scripts/macros
shipped with LibreOffice were explicitly put outside of that control

We then have a bunch of different ways to link various document events
like mouse-over or document-load or validate-cell-data to execution of
scripts.

We've had a series of problems where either:
 * A script shipped with LibreOffice should not have been trusted to be
called by document event callbacks
 * Or the document smuggles a script location url past restriction
checks and manages to execute a script on the target file system that
it shouldn't be allowed to access

And then a number of iterations of discovery of new ways to get past
added checks.

So recently I've made an effort to demote these "shared" built-in
scripts from their privileged position and to consider the presence of
a call to a script-like thing as equally hazardous as containing macros
to get that warning dialog for these cases. This has been backported to
6.2.7 and 6.3.1.

some more details are available in the commit 
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2=35fe064a67b54b0680b4845477c9b8751edda160
which maintainers of LTS might find worthwhile backporting to their own
branches as an additional backstop.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 127329] CRASH: pasting and undoing a few times

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127329

--- Comment #5 from Julien Nabet  ---
Gdb session:
(gdb) frame 6
#6  0x7fffdcb02b26 in SwHistorySetFormat::SetInDoc (this=0x5bcd4d00,
pDoc=0x5afd2bc0, bTmpSet=true) at
/home/julien/lo/libreoffice/sw/source/core/undo/rolbck.cxx:138
138 SwNode * pNode = pDoc->GetNodes()[ m_nNodeIndex ];
(gdb) p m_nNodeIndex
$1 = 182
(gdb) p pDoc->GetNodes()
$2 = (SwNodes &) @0x5afcef50: { = BigPtrArray of length 29 = {
[   0] 0x5afcfbf0StartNode , 
[   1] 0x5afcb9c0  EndNode , 
[   2] 0x5afd07c0StartNode , 
[   3] 0x5afc4fc0  EndNode , 
[   4] 0x5afb1fe0StartNode , 
[   5]  0x5b310a10   StartNode , 
[   6]   0x5b30ff50   TextNode "Dissertation s’appuyant sur un
dossier documentaire", 
[   7]  0x5b310a60 EndNode , 
[   8]  0x5bcd59e0   StartNode , 
[   9]   0x5be219d0GrfNode , 
[  10]  0x5dcbb9d0 EndNode , 
[  11] 0x5afd0840  EndNode , 
[  12] 0x5afcfb60StartNode , 
[  13] 0x5afc4b10  EndNode , 
[  14] 0x5afc4bc0StartNode , 
[  15]  0x5bc7f8f0TextNode "", 
[  16]  0x5d26c5f0TextNode "DOCUMENT 3", 
[  17]  0x5bcb5d60TextNode "", 
[  18]  0x5dc59170TextNode "Poids de l’industrie
manufacturière(1) dans l’emploi intérieur total(2) (en %) et importations de
produits de l'industrie manufacturière", 
[  19]  0x5b790660TextNode "(en milliards d'euros courants) en
France", 
[  20]  0x5b790a40TextNode "\001", 
[  21]  0x5be21c40TextNode "Source : D’après INSEE, 2016.", 
[  22]  0x5e1bf5e0TextNode "", 
[  23]  0x5e1bf9b0TextNode "Lecture : Selon l’INSEE, en France,
en 1985, les importations de produits issus de l’industrie manufacturière
s’élèvent à environ 110 milliards d’euros courants et les emplois dans
l’industrie manufac"..., 
[  24]  0x5e1c0050TextNode "", 
[  25]  0x5e27a820TextNode "(1) Les industries manufacturières
sont des industries de transformation des biens : industries alimentaires,
fabrication de textiles, industrie pharmaceutique, fabrication de machines et
équipements,"..., 
[  26]  0x5e27ad50TextNode "(2) Emploi intérieur total,
salariés et non-salariés, en nombre d’équivalents temps plein.", 
[  27]  0x5e2d44e0TextNode "", 
[  28] 0x5afcd570  EndNode }, m_vIndices = 0x5affefe8,
m_pMyDoc = 0x5afd2bc0, m_pEndOfPostIts = 0x5afcb9c0, m_pEndOfInserts =
0x5afc4fc0, m_pEndOfAutotext = 0x5afd0840, 
  m_pEndOfRedlines = 0x5afc4b10, m_pEndOfContent = std::unique_ptr
= {get() = 0x5afcd570}, m_pOutlineNodes = std::unique_ptr =
{get() = 0x55f096e0}, m_bInNodesDel = false, 
  m_bInDelUpdOutline = false}

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127329] CRASH: pasting and undoing a few times

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127329

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

On pc Debian x86-64 with master sources updated today, I could reproduce this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127329] CRASH: pasting and undoing a few times

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127329

Julien Nabet  changed:

   What|Removed |Added

   Keywords||haveBacktrace

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: manually changing content.xml > invalid xml.. but why

2019-09-04 Thread Regina Henschel

Hi,

I do not unzip to a folder. But I use "Open Archive" from 7-Zip. The 
context menu of content.xml then has "View" and "Edit". I have setup 
7-Zip to use "XML Notepad" with "Edit" and Notepad++ with "View". Then I 
use either of them to change the content of content.xml and use "Save" 
in those applications. Then close them. Now 7-Zip ask whether I want to 
update the file. Say "yes" and close 7-Zip. It has always worked. You 
might notice, that I'm working on Windows 10.


From my experience with unzipping to folder, a very common error is, 
that people do not zip the content of the folder, but the entire folder.


Kind regards
Regina

Eike Rathke schrieb am 04-Sep-19 um 20:26:

Hi Cor,

On Wednesday, 2019-09-04 19:45:33 +0200, Cor Nouws wrote:


So I try to remove from the content.xml.
This results in invalid xml file.. that LO needs to repair on opening.
Already the slightest change in the xml file (adding a space in string
"foo") makes the file invalid.


How do you re-zip the file? Best is to freshen the zip with just the
content.xml to keep the original file order and compression, i.e. the
'mimetype' file MUST be the first entry in the zip archive and MUST NOT
be compressed. So,

   zip -f filename.ods content.xml

should do. If that doesn't help then it's something different ("invalid
xml" is a vague description).

   Eike



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.2' - distro-configs/CPLinux-LOKit.conf

2019-09-04 Thread Andras Timar (via logerrit)
 distro-configs/CPLinux-LOKit.conf |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 1156dcbdbe13bdf82e82b061a55eecbe3011a078
Author: Andras Timar 
AuthorDate: Fri Jan 11 22:29:14 2019 +0100
Commit: Andras Timar 
CommitDate: Wed Sep 4 21:21:41 2019 +0200

Disable use of X11 or Wayland to reduce dependencies

Change-Id: I1006a04bab3866fe56d2a7d2348c3afd09574da7
Reviewed-on: https://gerrit.libreoffice.org/78241
Reviewed-by: Andras Timar 
Tested-by: Andras Timar 

diff --git a/distro-configs/CPLinux-LOKit.conf 
b/distro-configs/CPLinux-LOKit.conf
index 302c62302930..7e906bbf4207 100644
--- a/distro-configs/CPLinux-LOKit.conf
+++ b/distro-configs/CPLinux-LOKit.conf
@@ -37,6 +37,7 @@
 --disable-gstreamer-1-0
 --disable-evolution2
 --disable-gio
+--disable-gui
 --disable-scripting-beanshell
 --disable-scripting-javascript
 --disable-ext-wiki-publisher
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.2' - vcl/qa

2019-09-04 Thread Ashod Nakashian (via logerrit)
 vcl/qa/cppunit/pdfexport/pdfexport.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit e0712f4339c69a0cae80585df8563fe40d152177
Author: Ashod Nakashian 
AuthorDate: Wed Sep 4 11:02:25 2019 -0400
Commit: Andras Timar 
CommitDate: Wed Sep 4 21:19:41 2019 +0200

pdfexport: improved detection of failure to print with --disable-gui

PDF printing tests cannot run when we don't have the proper
support enabled, so we need to detect those cases and
avoid failing the test unnecessarily.

Change-Id: Ia602dbb5c3d16c082a8ff6e707db90501bb5453c
Reviewed-on: https://gerrit.libreoffice.org/78610
Reviewed-by: Andras Timar 
Tested-by: Andras Timar 

diff --git a/vcl/qa/cppunit/pdfexport/pdfexport.cxx 
b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
index bcc4d11d1682..03f412016f6e 100644
--- a/vcl/qa/cppunit/pdfexport/pdfexport.cxx
+++ b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
@@ -638,7 +638,7 @@ void PdfExportTest::testSofthyphenPos()
 SvFileStream aFile(maTempFile.GetURL(), StreamMode::READ);
 SvMemoryStream aMemory;
 aMemory.WriteStream(aFile);
-if (aFile.bad())
+if (aFile.bad() || !aMemory.GetSize())
 {
 // Printing to PDF failed in a non-interesting way, e.g. CUPS is not
 // running, there is no printer defined, etc.
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=103182
Bug 103182 depends on bug 127189, which changed state.

Bug 127189 Summary: Editing a particular math formula using underbrace / 
overbrace destroys the UI under GTK3
https://bugs.documentfoundation.org/show_bug.cgi?id=127189

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 39750] [META] General Math formula editor improvements

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=39750
Bug 39750 depends on bug 127189, which changed state.

Bug 127189 Summary: Editing a particular math formula using underbrace / 
overbrace destroys the UI under GTK3
https://bugs.documentfoundation.org/show_bug.cgi?id=127189

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] core.git: vcl/unx

2019-09-04 Thread Caolán McNamara (via logerrit)
 vcl/unx/generic/fontmanager/fontconfig.cxx |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

New commits:
commit 29411e7c08ec249116ee0211888e47c8b6f57707
Author: Caolán McNamara 
AuthorDate: Wed Sep 4 14:52:31 2019 +0100
Commit: Caolán McNamara 
CommitDate: Wed Sep 4 21:14:23 2019 +0200

Related: rhbz#1648281 improve fontconfig fallback for emojis

disregard text language for emoji and tag with und-zsye to
get fontconfig to give us the default emoji font

Change-Id: I8f94b0c41dea3204c9db77b96ad8f0d98bae2239
Reviewed-on: https://gerrit.libreoffice.org/78600
Tested-by: Jenkins
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/vcl/unx/generic/fontmanager/fontconfig.cxx 
b/vcl/unx/generic/fontmanager/fontconfig.cxx
index 9fd6b380b73a..2767cafcf07f 100644
--- a/vcl/unx/generic/fontmanager/fontconfig.cxx
+++ b/vcl/unx/generic/fontmanager/fontconfig.cxx
@@ -798,6 +798,11 @@ namespace
 #endif
 }
 
+bool isEmoji(sal_uInt32 nCurrentChar)
+{
+return u_hasBinaryProperty(nCurrentChar, UCHAR_EMOJI);
+}
+
 //returns true if the given code-point couldn't possibly be in rLangTag.
 bool isImpossibleCodePointForLang(const LanguageTag , sal_uInt32 
currentChar)
 {
@@ -846,6 +851,8 @@ namespace
 
 OUString getExemplarLangTagForCodePoint(sal_uInt32 currentChar)
 {
+if (isEmoji(currentChar))
+return "und-zsye";
 int32_t script = u_getIntPropertyValue(currentChar, UCHAR_SCRIPT);
 UScriptCode eScript = static_cast(script);
 OStringBuffer 
aBuf(unicode::getExemplarLanguageForUScriptCode(eScript));
@@ -904,7 +911,7 @@ void PrintFontManager::Substitute(FontSelectPattern 
, OUString& rMissin
 FcCharSetAddChar( codePoints, nCode );
 //if the codepoint is impossible for this lang tag, then clear it
 //and autodetect something useful
-if (!aLangAttrib.isEmpty() && 
isImpossibleCodePointForLang(aLangTag, nCode))
+if (!aLangAttrib.isEmpty() && 
(isImpossibleCodePointForLang(aLangTag, nCode) || isEmoji(nCode)))
 aLangAttrib.clear();
 //#i105784#/rhbz#527719  improve selection of fallback font
 if (aLangAttrib.isEmpty())
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-bugs] [Bug 127346] New: LibreOffice Math extension that generates a formula using a spreadsheet and f(x)

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127346

Bug ID: 127346
   Summary: LibreOffice Math extension that generates a formula
using a spreadsheet and f(x)
   Product: LibreOffice
   Version: 3.3.0 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: enhancement
  Priority: medium
 Component: Formula Editor
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: elmhurstproj...@gmail.com

Description:
A great extension would be auto-generate a formula using cells as variables and
f(x) for any imported spreadsheet. Bonus if it could then simplify that
formula. 

Steps to Reproduce:
1. import spreadsheet
2. assign cells as variables using formulas
3. generate equation from cells formula syntax and f(x)

Actual Results:
1. create spreadsheet.
2. think hard about how to manually transpose spreadsheet into a formula.
3. create formula manually using Math.

Expected Results:
1. create spreadsheet.
2. open Math.
3. Import spreadsheet
4. push button
5. get formula.


Reproducible: Always


User Profile Reset: No



Additional Info:

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127328] UI: Make German strings in list of embedded databases consistent

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127328

--- Comment #5 from Julien Nabet  ---
Fixed on Pootle:
for 6.2UI
https://translations.documentfoundation.org/de/translate/#search=HSQLDB%20(eingebettet)=source,target=160004969=0

for 6.3UI
https://translations.documentfoundation.org/de/translate/#search=HSQLDB%20(eingebettet)=source,target=45398818=0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127334] Regression: Incompatible changes in date/time arithmetic introduced between Version: 6.0.4.2 (x64) and version 6.2.6.2 (ubuntu)

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127334

Albrecht Müller  changed:

   What|Removed |Added

 Resolution|NOTABUG |FIXED

--- Comment #2 from Albrecht Müller  ---
The help information that explains the minute function
(https://help.libreoffice.org/6.3/en-US/text/scalc/01/func_minute.html?=CALC=WIN
) simply states  "MINUTE Calculates the minute for an internal time value. The
minute is returned as a number between 0 and 59." and specifies "=MINUTE(8.999)
returns 58" and "=MINUTE(8.) returns 59". Especially it does not refer to
the document
https://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#MINUTE
that provides a some more information about the minute function. It does not
even mention things like wall clock time or durations. This gives you a lot of
freedom to declare some behaviour as correct and you are free to change the
behaviour from version to version. Therefore closing this report as "NOTABUG"
is completly ok.

On the other hand: Doing so has some pretty nasty consequences from a users
point of view, and that's why I filed bug 127170.

First: I did this kind of trivial time calculations with different spreadsheet
programs (including LibreOffice Calc up to version 6.0.4.2) and they all were
able to come up with correct minute values. As long as this worked as expected
I did not care how this was achieved. I assume that they internally rounded
float values to some internal time resolution before they interpreted them as
time and/or date. If this resolution is choosen such that it is some orders of
magnitude above the floating point round-off errors these errors will affect
the result in extreme cases only. The programming language Java does date/time
calculations based on integral numbers of milliseconds to avoid round-off
problems altogether. Closing this bug as "NOTABUG" tells me that LibreOffices
quality standards allow time calculation algorithms to deliver zero or one
minute with equal probability when subtracting e.g. two minutes from three
minutes.

Second: This problem affects all functions of this kind. A round-off error in
the sub-milliseconds range may cause the year function to return the wrong
year. The key problem is that usually integral numbers of time units (years,
month, days, hours, minutes and seconds) are considered and therefore the
calculations could be exact. However, LibreOffice uses a time representation
that cannot guarantee an exact representation of the time units hours, minutes
and seconds.

Third: I cannot trust the results of LibreOffices date/time calculations any
more. Any legacy spreadsheets containing this kind of simple time calculations
will deliver wrong results if opened with recent versions of Calc. What makes
the matters worse is that the user documentation does not specify how Calc is
intended to handle the problems rooted in its time representation and obviously
this intention changes from time to time. Therefore  I cannot know how to use
the date/time calculation functions in a way that future version of Calc will
return the same results even if I assume that these functions are implemented
correctly.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: manually changing content.xml > invalid xml.. but why

2019-09-04 Thread Eike Rathke
Hi Cor,

On Wednesday, 2019-09-04 19:45:33 +0200, Cor Nouws wrote:

> So I try to remove from the content.xml.
> This results in invalid xml file.. that LO needs to repair on opening.
> Already the slightest change in the xml file (adding a space in string
> "foo") makes the file invalid.

How do you re-zip the file? Best is to freshen the zip with just the
content.xml to keep the original file order and compression, i.e. the
'mimetype' file MUST be the first entry in the zip archive and MUST NOT
be compressed. So,

  zip -f filename.ods content.xml

should do. If that doesn't help then it's something different ("invalid
xml" is a vague description).

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 127299] FIREBIRD: base crashes if like query has blank in parameter

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127299

--- Comment #9 from Wayne Davis  ---
Issue indeed fixed.  Thank you.  I had no idea base was getting this quality of
support.

Downloaded current version 2019-09-04_13.16.18_LibreOfficeDev_6.3.2.0.0. 
Tested, bug is gone.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

--- Comment #5 from comit...@gmail.com ---
Created attachment 153884
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153884=edit
A basic presentation with two embedded videos.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

--- Comment #4 from comit...@gmail.com ---
Created attachment 153883
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153883=edit
Expected behaviour after pressing F5 under either wayland or xorg.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

--- Comment #3 from comit...@gmail.com ---
Created attachment 153882
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153882=edit
After pressing F5 under Gnome+xorg.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

--- Comment #2 from comit...@gmail.com ---
Created attachment 153881
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153881=edit
After pressing F5 under GNOME+wayland.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127323] Cannot Ungroup

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127323

--- Comment #4 from kit...@tutanota.com ---
Yes, it does work thru that menu item, and yes, the keyboard shortcut for
Ctrl+F12 does say ungroup.  Evidently the keyboard shortcut is not actually
coded to do what it says.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

--- Comment #1 from comit...@gmail.com ---
Created attachment 153880
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153880=edit
Laying out the embedded videos.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127345] New: Impress slide show embedded video scaling/formatting problem.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127345

Bug ID: 127345
   Summary: Impress slide show embedded video scaling/formatting
problem.
   Product: LibreOffice
   Version: 6.3.0.4 release
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Impress
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: comit...@gmail.com

Description:
A slide show with embedded videos is not scaling correctly.  This seems to be
specific to a Dell XPS 13 9370.

Steps to Reproduce:
1. Create a new presentation in Impress 6.3.0.4 on a Dell XPS 13 9370 running
Fedora 30.
2. Insert a video.
3. Press F5 to run slide show.


Actual Results:
The slide show begins and the video plays, but the location is not correct
relative to where it was laid out in the editor and the video is not scaled
correctly relative to the screen size.

Expected Results:
The slide show begins and the video plays, the video is located in the correct
spot on the screen relative to where it was laid out in the editor and is
scaled to fit the box as specified in the editor.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Hardware: DELL XPS 13 9370, Intel 620 GPU with a 4k UHD touch screen.
Software: Fully up to date Fedora 30 Workstation running current stable RPM
build of Libreoffice downloaded from libreoffice.org (problem is also present
in the version that is packaged by fedora 30, as well as the version available
on flathub).

The problem happens under both wayland and xorg gnome sessions, but is actually
worse under xorg.  I have not tried it under any other desktops like KDE.

Problem happens regardless of hardware acceleration enable settings (tried
under both on and off scenarios).  I reset the user profile and tried each of
the OpenGL settings in turn. 

Problem does *NOT* happen on my desktop PC running the same version of
Fedora/LibreOffice that has a 4K screen driven by an AMD RX560 video card under
Gnome+wayland.

I will attach four screen shots plus a basic odp file with embedded videos to
demonstrate the problem.  The first image named "layout.png" shows the editor
with the expected layout of the two videos.  The second shows the problematic
slide show under wayland, the third shows the problematic slide show under
xorg.  The fourth shows the same slide show on a 1080p xorg session with the
videos located correctly.

The only workaround I have found for this problem is to use a Gnome+xorg
session and change the video settings to 1080p.

Unfortunately as this is a client's machine, I am going to be losing access to
the laptop on Saturday.  I will do my best to get additional information as
requested.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-commits] core.git: sal/qa sal/textenc

2019-09-04 Thread Stephan Bergmann (via logerrit)
 sal/qa/rtl/textenc/rtl_textcvt.cxx|   30 ++
 sal/textenc/convertbig5hkscs.cxx  |   12 ++
 sal/textenc/converteuctw.cxx  |   14 +++-
 sal/textenc/convertgb18030.cxx|   14 +++-
 sal/textenc/convertisciidevangari.cxx |   17 ++
 sal/textenc/convertiso2022cn.cxx  |   14 +++-
 sal/textenc/convertiso2022jp.cxx  |   14 +++-
 sal/textenc/convertiso2022kr.cxx  |   14 +++-
 sal/textenc/convertsinglebytetobmpunicode.cxx |   12 ++
 sal/textenc/tcvtutf8.cxx  |   11 ++---
 sal/textenc/unichars.hxx  |8 --
 11 files changed, 110 insertions(+), 50 deletions(-)

New commits:
commit cd563e7b807fe038ebefb228e70bc587c040d17d
Author: Stephan Bergmann 
AuthorDate: Wed Sep 4 14:31:30 2019 +0200
Commit: Stephan Bergmann 
CommitDate: Wed Sep 4 19:56:33 2019 +0200

Do not exclude Unicode noncharacters from rtl_convertUnicodeToText

For one, that broke round-tripping with e.g. UTF-8 (see the test case added 
to
Test::testComplex in sal/qa/rtl/textenc/rtl_textcvt.cxx) which did not treat
noncharacters as invalid.

For another,  is 
meanwhile
quite clear on the matter:

"Q: Are noncharacters prohibited in interchange?

"A: This question has led to some controversy, because the Unicode Standard 
has
been somewhat ambiguous about the status of noncharacters. The formal 
wording of
the definition of 'noncharacter' in the standard has always indicated that
noncharacters 'should never be interchanged.' That led some people to assume
that the definition actually meant 'shall not be interchanged' and that
therefore the presence of a noncharacter in any Unicode string immediately
rendered that string malformed according to the standard. But the intended 
use
of noncharacters requires the ability to exchange them in a limited 
context, at
least across APIs and even through data files and other means of 
'interchange',
so that they can be processed as intended. The choice of the word 'should' 
in
the original definition was deliberate, and indicated that one should not 
try to
interchange noncharacters precisely because their interpretation is strictly
internal to whatever implementation uses them, so they have no publicly
interchangeable semantics. But other informative wording in the text of the 
core
specification and in the character names list was differently and more 
strongly
worded, leading to contradictory interpretations.

"Given this ambiguity of intent, in 2013 the UTC issued Corrigendum #9, 
which
deleted the phrase 'and that should never be interchanged' from the 
definition
of noncharacters, to make it clear that prohibition from interchange is not 
part
of the formal definition of noncharacters. Corrigendum #9 has been 
incorporated
into the core specification for Unicode 7.0.

"Q: Are noncharacters invalid in Unicode strings and UTFs?

"A: Absolutely not. Noncharacters do not cause a Unicode string to be 
ill-formed
in any UTF. This can be seen explicitly in the table above, where every
noncharacter code point has a well-formed representation in UTF-32, in 
UTF-16,
and in UTF-8. An implementation which converts noncharacter code points 
between
one UTF representation and another must preserve these values correctly. The
fact that they are called 'noncharacters' and are not intended for open
interchange does not mean that they are somehow illegal or invalid code 
points
which make strings containing them invalid."

Change-Id: I4fcc0156e3d2fd305a7c7bb0c7b3dbef846c9e64
Reviewed-on: https://gerrit.libreoffice.org/78598
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 

diff --git a/sal/qa/rtl/textenc/rtl_textcvt.cxx 
b/sal/qa/rtl/textenc/rtl_textcvt.cxx
index 2f5359b32c77..af9ccca345e7 100644
--- a/sal/qa/rtl/textenc/rtl_textcvt.cxx
+++ b/sal/qa/rtl/textenc/rtl_textcvt.cxx
@@ -457,6 +457,8 @@ public:
 
 void testInvalidUtf8();
 
+void testInvalidUnicode();
+
 void testSRCBUFFERTOSMALL();
 
 void testMime();
@@ -471,6 +473,7 @@ public:
 CPPUNIT_TEST(testComplexCut);
 CPPUNIT_TEST(testInvalidUtf7);
 CPPUNIT_TEST(testInvalidUtf8);
+CPPUNIT_TEST(testInvalidUnicode);
 CPPUNIT_TEST(testSRCBUFFERTOSMALL);
 CPPUNIT_TEST(testMime);
 CPPUNIT_TEST(testWindows);
@@ -2336,6 +2339,15 @@ void Test::testComplex() {
   true,
   false,
   RTL_UNICODETOTEXT_FLAGS_UNDEFINED_ERROR },
+{ RTL_TEXTENCODING_UTF8,
+  RTL_CONSTASCII_STRINGPARAM("\xEF\xBF\xBF"),
+  {0x},
+  1,
+  false,
+  true,
+  true,

manually changing content.xml > invalid xml.. but why

2019-09-04 Thread Cor Nouws
Hi,

ODT with form controls wil print the form:label"foo" text in newer
versions..
So I try to remove from the content.xml.
This results in invalid xml file.. that LO needs to repair on opening.
Already the slightest change in the xml file (adding a space in string
"foo") makes the file invalid.
Both Geany and Emacs give the same problem.

Hints appreciated.

thnx
Cor

-- 
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger https://nl.libreoffice.org
- volunteer https://www.libreoffice.org
- Member Board The Document Foundation
- http://www.nouenoff.nl / https://www.mijncloudoffice.nl
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 127344] New: Idle LibreOffice consumes 100% CPU on i386

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127344

Bug ID: 127344
   Summary: Idle LibreOffice consumes 100% CPU on i386
   Product: LibreOffice
   Version: 6.2.6.2 release
  Hardware: x86 (IA32)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: LibreOffice
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: albrecht.dr...@arcor.de

Package: LibreOffice_6.2.6_Linux_x86_deb.tar.gz
OS: Debian Buster/i386
Hardware: MacBookPro5,5; Virtualbox 6.0.10 VM

Hi all,

after some time, LibreOffice starts to consume 100% of one CPU, although it is
completely idle.

To reproduce:
- launch LibreOffice writer
- wait for some time without touching Libreoffice

After a few minutes (typically less than ~15?), soffice.bin starts to consume
100% cpu.  Entering a few characters in writer /briefly/ reduces the cpu load
to almost 0, but after a short time (typically seconds), it again goes up to
100 %.

The effect is reproducible on an old 2009 MacBookPro5,5 (which is particularly
bad as it triggers a high fan speed and quickly drains the battery!) and in a
Virtualbox VM, both running Debian Buster/i386.  The LibreOffice packages
coming with Debian Buster (libreoffice_6.1.5-3_i386.deb) show the same effect.

I didn't notice this effect on my 64-bit Buster boxes, running the exactly the
same LibreOffice versions, so it /might/ be specific for i386.

On the VM, the soffice.bin thread consumes the 100% cpu, as reported by top:


 3575 albrecht  20   0  268344 140700  83740 R  99,9   7,0   1:03.72
soffice.bin  
 3580 albrecht  20   0  268344 140700  83740 S   0,0   7,0   0:00.00 PipeIPC
 3581 albrecht  20   0  268344 140700  83740 S   0,0   7,0   0:00.00
ICEConnectionWo  
 3582 albrecht  20   0  268344 140700  83740 S   0,0   7,0   0:00.00
SelectionManage  
 3592 albrecht  20   0  268344 140700  83740 S   0,0   7,0   0:00.00
GrammarChecking  
 3595 albrecht  20   0  268344 140700  83740 S   0,0   7,0   0:00.02
UpdateCheckThre  


In gdb, I interrupted the process, and got the following information:


Thread 1 "soffice.bin" received signal SIGINT, Interrupt.
0xb7fa7d71 in __kernel_vsyscall ()
(gdb) where
#0  0xb7fa7d71 in __kernel_vsyscall ()
#1  0xb7fa7d34 in __vdso_gettimeofday ()
#2  0xb6be1cb2 in tools::Time::GetMonotonicTicks() () from
/opt/libreoffice6.2/program/libmergedlo.so
#3  0xb6be1ce9 in tools::Time::GetSystemTicks() () from
/opt/libreoffice6.2/program/libmergedlo.so
#4  0xb6f850ba in Scheduler::ProcessTaskScheduling() () from
/opt/libreoffice6.2/program/libmergedlo.so
#5  0xb6f8546d in Scheduler::CallbackTaskScheduling() () from
/opt/libreoffice6.2/program/libmergedlo.so
#6  0xb071b4ec in ?? () from /opt/libreoffice6.2/program/libvclplug_gtklo.so
#7  0xb427be65 in g_main_dispatch (context=0x9c7a120) at
../../../glib/gmain.c:3182
#8  g_main_context_dispatch (context=0x9c7a120) at ../../../glib/gmain.c:3847
#9  0xb427c269 in g_main_context_iterate (context=context@entry=0x9c7a120,
block=block@entry=1, dispatch=dispatch@entry=1, self=)
at ../../../glib/gmain.c:3920
#10 0xb427c314 in g_main_context_iteration (context=0x9c7a120, may_block=1) at
../../../glib/gmain.c:3981
#11 0xb071ab19 in ?? () from /opt/libreoffice6.2/program/libvclplug_gtklo.so
#12 0xb071bff0 in ?? () from /opt/libreoffice6.2/program/libvclplug_gtklo.so
#13 0xb6f90829 in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#14 0xb6f91b7f in Application::Execute() () from
/opt/libreoffice6.2/program/libmergedlo.so
#15 0xb64912ae in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#16 0xb6f9717e in ImplSVMain() () from
/opt/libreoffice6.2/program/libmergedlo.so
#17 0xb6f97285 in SVMain() () from /opt/libreoffice6.2/program/libmergedlo.so
#18 0xb64a409b in soffice_main () from
/opt/libreoffice6.2/program/libmergedlo.so
#19 0x080485ac in ?? ()
#20 0xb519cb41 in __libc_start_main (main=0x8048580, argc=3, argv=0xbfdddf04,
init=0x80486b0, fini=0x80486a0, rtld_fini=0xb7fb9520 <_dl_fini>, 
stack_end=0xbfdddefc) at ../csu/libc-start.c:308
#21 0x080485e5 in ?? ()
(gdb) info threads
  Id   Target Id  Frame 
* 1Thread 0xb0bf38c0 (LWP 3575) "soffice.bin" 0xb7fa7d71 in
__kernel_vsyscall ()
  2Thread 0xaf2ffb40 (LWP 3580) "PipeIPC" 0xb7fa7d71 in
__kernel_vsyscall ()
  3Thread 0xae362b40 (LWP 3581) "ICEConnectionWo" 0xb7fa7d71 in
__kernel_vsyscall ()
  4Thread 0xad9ffb40 (LWP 3582) "SelectionManage" 0xb7fa7d71 in
__kernel_vsyscall ()
  5Thread 0xafcd5b40 (LWP 3592) "GrammarChecking" 0xb7fa7d71 in
__kernel_vsyscall ()
  6

[Libreoffice-bugs] [Bug 122370] Style Heading 1 is not applied to content nor option Numeric with all sublevels is applied to Headings whose levels are superior to level 1.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=122370

--- Comment #10 from Emersson Augusto Suarez Ortiz  ---
Created attachment 153879
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153879=edit
Figures to show the problem

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 122370] Style Heading 1 is not applied to content nor option Numeric with all sublevels is applied to Headings whose levels are superior to level 1.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=122370

--- Comment #9 from Emersson Augusto Suarez Ortiz  ---
I have LO Versión: 6.2.4.2 (x64)Id. de compilation:
2412653d852ce75f65fbfa83fb7e7b669a126d64 Subprocs. CPU: 4; SO: Windows 10.0;
Repres. IU: GL; VCL: win; Configuración regional: fr-CA (fr_CA); Idioma de IU:
es-ES Calc: CL, and when I try to use the header style, specifically the title
group, I can see many sub styles like "Title1" to "Title10" all of then take
their properties from "Title" Style (Fig1). Then I suppose that if I set the
"Title" properties to use the "Numeracion 123" (fig2) numbering style to put 
1. Title 1
1.1. Title 2
1.1.1. Title 3
when I use the Title1 Style I should have the number than I want, but when I
try to use then in the main document, I found that it doesn't work how it
suppose to do, and when I try to modify the "Title1" Style to attach the
"Numeracion 123" numbering style, the field is unavailable (fig3) and it has a
default value like "Numeracion de capitulos".

All this situation is very unpleasant when I have to work whit many titles in
the main document.
I hope this will be helpful to find out the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 122370] Style Heading 1 is not applied to content nor option Numeric with all sublevels is applied to Headings whose levels are superior to level 1.

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=122370

Emersson Augusto Suarez Ortiz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127279] Register-true with better labelling

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127279

--- Comment #10 from pedro.silva  ---
(In reply to V Stuart Foote from comment #9)
[...]
> Actually rather than "reference" (a paragraph style applied against the
> page) the concept would be "registration"--now common in alignment of offset
> press CMYK and half-tone image print work. But here it predates that
> considerably coming from the folding of large folio paper sizes to impose
> the signatures with correct sequence and alignment (front to back and across
> pages) -- when accomplished the printing and binding is "register-true" and
> "folded with the print".
> 
> But we have little support for imposing and printing 'folio, quarto, octavo,
> duodecimo, sextodecimo' layouts. Just look at the Print dialog's pages per
> sheet and order where we can not impose a multi-page print layout that would
> correctly _fold_. That and a lack of means to provide bleeds, trim, and
> registration marks means we can't directly perform DTP--and "register-true"
> while correct is not really appropriate.

Thanks Stuart for all the context, to me, this is gold! I really appreciate the
context and to know the reasoning behind.

> What we are able to do well is provide correct page to page registration of
> textual content. As our pages are composed dynamically when paragraphs are
> rendered the printing on pages will not register--page to page, column to
> column. But when we enable "register-true" on page styles, and allow
> individual paragraphs to pick up the alignment from the selected reference
> paragraph's line height (its font height, internal leading, external
> leading) as a baseline the documents textual content will register as if
> "imposed" correctly and then "folded with the print", trimmed, and bound.
> 
> So, while "register-true" is a correct label--agree its etymology is obscure
> and is really not helpful UX--but the action is still registration.

I agree with you, maybe having such a term based of print world without any
relation with existent LO terminology might not be the clearest.

> Rather than Reference, I would suggest:
> 
> Register line spacing / Reference style

In my opinion this is already better when compared with the current labelling.
However I'm having a hard time with "Register" or "Registration" because
somehow the following doesn't let me stop worrying about UX:

- Register is better than the Register-true (because the latter is kinda of a
state/adjective) but this term is based on printing but Document/page and its
overall line spacing (leading, Baseline grid, vertical motion etc...) are not
exclusive of print specially in this day and age.
- Users that know nothing about printing and don't own a printer they might be
quite confused with it.
- Register often times called registration is also quite an uneasy term (to me,
in this case) since there are other elements sharing the same name (e.g.:
registration marks)
- Also a document can be on purpose misregistered (out of) for artistic
purposes etc..

And in Reference style I think it would be still quite valuable to have in
there the word "Paragraph" as it helps to connect the dots and invites the user
to explore the Paragraph style dialogue etc.

Hm... I honestly think this is a great discussion and as I stated these (what
you suggested) would be already better then what we have now but I would still
use 

Page dialogue
- Referenced line spacing / Paragraph style:

"Reference" here would play quite well also in the paragraph dialogue

Paragraph dialogue
- Referenced line spacing / Activate

hm...but then again I understand your reasoning and maybe it would be good to
leave some sort of trace for the user that already use and know the feature and
all its context. And if so, then your proposal could be also a good option.

(goes away and expects no sleeping tonight on the accounts of thinking about
this :p )

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 50879] form exported as pdf does not embed all required fonts

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=50879

--- Comment #37 from Gellért Gyuris  ---
(In reply to p10 from comment #36)
> 
> Hello,
> 
> Where do I put this code ? in LO ? in a new module ?
> 
> Thanks.

Not in LO. Export document in LO to PDF, and add this small script with a
PDF-editor. I used Master PDF Editor (Document>Document Javascript).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127343] When creating a query in design view using MySQL as a backend (Connector/J), I can not access any tables in the Add Tables dialog

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127343

--- Comment #2 from Dan Lewis  ---
Created attachment 153878
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153878=edit
Screen shot for LO 6.2.6.1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127343] When creating a query in design view using MySQL as a backend (Connector/J), I can not access any tables in the Add Tables dialog

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127343

--- Comment #1 from Dan Lewis  ---
Created attachment 153877
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153877=edit
Screen show for LO 6.3

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127342] Form Control toolbar icons in Tango set are from Colibre

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127342

Aron Budea  changed:

   What|Removed |Added

 CC||heiko.tietze@documentfounda
   ||tion.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127342] New: Form Control toolbar icons in Tango set are from Colibre

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127342

Bug ID: 127342
   Summary: Form Control toolbar icons in Tango set are from
Colibre
   Product: LibreOffice
   Version: 6.1.0.3 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Keywords: bibisected, bisected, regression
  Severity: normal
  Priority: medium
 Component: UI
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: ba...@caesar.elte.hu
Blocks: 108160

- Switch icon set to Tango.
- Open View -> Toolbars -> Form Controls.

=> Most of the toolbar icons are from the Colibre icon set.

Observed using LO 6.4.0.0.alpha0+ (a40fbd031de042b0181dc5570164ae8ce0abb0f1) &
6.1.0.3 / Ubuntu 19.04 & Windows 7.
Icons are (presumably) from Tango in 6.0.0.3.
=> regression

Bibisected to the following commit using repo bibisect-linux-64-6.1. Adding Cc:
to Heiko Tietze, please take a look sometimes.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=8bdd059a1d64a1818ee0093d7a512fe38c4e2b20
author  heiko tietze2018-05-12 12:00:25
+0200
committer   Heiko Tietze2018-05-13 08:37:15
+0200

Icon themes clean-up


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=108160
[Bug 108160] [META] Tango icons
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127343] New: When creating a query in design view using MySQL as a backend (Connector/J), I can not access any tables in the Add Tables dialog

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127343

Bug ID: 127343
   Summary: When creating a query in design view using MySQL as a
backend (Connector/J), I can not access any tables in
the Add Tables dialog
   Product: LibreOffice
   Version: 6.3.1.1 rc
  Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Base
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: elderdanle...@gmail.com

Description:
When the Add Tables or Query dialog, I get a list of my schemas in LO 6.3 but
none of the schemas has a drop down list of its tables. (I have seen one of the
schema with its tables listed directly below it rather than being part of a
drop down list.

Steps to Reproduce:
1.Open the MySQL database using Connector/J using LO 6.3.
2.Click Create Query in Design View
3. The query dialog opens and then the Add Table or Query dialog opens.


Actual Results:
I have several schemas in my database, and there are all listed in this dialog.
There is no drop down list for the tables of these schemas. This is true for
6.3.0.1, 6.3.0.2, 6.3.0.4, and now 6.3.1.2. (See attached screen shot labeled
AddTableOrQuery_6.3.)

Expected Results:
The schemas listed each have a drop down list of their tables as is done when
using LO 6.2.6.1. See the screen shot labeled AddTableOrQuery_6.2.


Reproducible: Always


User Profile Reset: No



Additional Info:
I opened the same database document file by LO 6.2.6.1 and 6.3.1.2 in
succession to get the screen shots.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 108160] [META] Tango icons

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108160

Aron Budea  changed:

   What|Removed |Added

 Depends on||127342


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127342
[Bug 127342] Form Control toolbar icons in Tango set are from Colibre
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 126494] conditional formatting icon color

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=126494

raal  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED
 CC||r...@post.cz

--- Comment #9 from raal  ---
(In reply to Rizal Muttaqin from comment #8)
> Not reproducible in latest build master (RED)
> 
> Version: 6.4.0.0.alpha0+
> Build ID: 2bed8af91fc2654b9ed2432f969d32d5741a529b
> CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk2; 
> TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time:
> 2019-08-21_09:30:10
> Locale: id-ID (id_ID.UTF-8); UI-Language: en-US
> Calc: threaded

Confirm Version: 6.4.0.0.alpha0+ (x64)
Build ID: 1bad7f0b19e47a41a1919573f80785ec62c611af
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=102495
Bug 102495 depends on bug 126494, which changed state.

Bug 126494 Summary: conditional formatting icon color
https://bugs.documentfoundation.org/show_bug.cgi?id=126494

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 120543] [META] Bugs and enhancements around hyperlinks in Calc

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=120543

Thomas Lendo  changed:

   What|Removed |Added

 Depends on||127341


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127341
[Bug 127341] FORMATTING: Right-click on a cell with hyperlink should show
'Format Cells...' command
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127341] FORMATTING: Right-click on a cell with hyperlink should show 'Format Cells...' command

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127341

Thomas Lendo  changed:

   What|Removed |Added

 Blocks||120543


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=120543
[Bug 120543] [META] Bugs and enhancements around hyperlinks in Calc
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 127341] New: FORMATTING: Right-click on a cell with hyperlink should show 'Format Cells...' command

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=127341

Bug ID: 127341
   Summary: FORMATTING: Right-click on a cell with hyperlink
should show 'Format Cells...' command
   Product: LibreOffice
   Version: 6.4.0.0.alpha0+ Master
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Calc
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: thomas.le...@gmail.com

When you make a right-click on a cell, then a context menu appears with the
command 'Format Cells...' at its end.

But if you do this right-click on a hyperlink, then this cell format command is
missing and the hyperlink-related context menu is popping up.

This is no problem if only a part of the cell content contains a hyperlink. But
if the whole content is a hyperlink, you can't open the 'Format Cells...'
command with a right-click.

You can test it in attachment 153875.

Possible solution could be to add the 'Format Cells...' to the
hyperlink-related context menu. But I don't know where this context menu also
is used and if this leads to a false behavior elsewhere.


Steps to reproduce:
1. Open a new Calc document.
2. Write text in a cell that is as long as the cell is wide.
3. Select the cell (not the string in it) and click the 'Insert Hyperlink'
command. Insert a web address or something else.
4. Right-click on this cell with a hyperlink.

If you want to edit the whole cell and not the content/hyperlink, it's not
possible anymore. Right-clicking on a hyperlink brings you the hyperlink
context menu and not the cell context menu.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 123027] FOOTNOTE SETTING DIALOG: Changing character style of footnote area has no effect

2019-09-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=123027

raal  changed:

   What|Removed |Added

 CC||bjoern.michaelsen@libreoffi
   ||ce.org
   Keywords|bibisectRequest |bibisected, bisected

--- Comment #7 from raal  ---
(In reply to Mike Kaganski from comment #5)
> (From bug 127254 comment #3)
> > That was changed in
> > https://git.libreoffice.org/core/+/e9bf0102783e23cf8b7c609a9a5265ab436dc90e

Adding cc to Bjoern

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

  1   2   3   4   >