[Libreoffice-commits] core.git: 2 commits - filter/source formula/source include/filter include/formula

[Noel Grandin (via logerrit)]

 filter/source/flash/swfwriter.hxx   |2 +-
 filter/source/graphicfilter/icgm/cgm.cxx|2 +-
 filter/source/graphicfilter/icgm/cgm.hxx|2 +-
 filter/source/graphicfilter/icgm/chart.cxx  |2 +-
 filter/source/graphicfilter/icgm/chart.hxx  |2 +-
 filter/source/graphicfilter/ios2met/ios2met.cxx |4 ++--
 filter/source/msfilter/mstoolbar.cxx|4 ++--
 filter/source/msfilter/svdfppt.cxx  |2 +-
 filter/source/svg/svgwriter.hxx |2 +-
 filter/source/xsltfilter/LibXSLTTransformer.hxx |6 +++---
 formula/source/core/api/token.cxx   |2 +-
 formula/source/ui/dlg/ControlHelper.hxx |4 ++--
 formula/source/ui/dlg/funcpage.cxx  |6 +++---
 formula/source/ui/dlg/funcpage.hxx  |8 
 formula/source/ui/dlg/funcutl.cxx   |4 ++--
 formula/source/ui/dlg/parawin.cxx   |4 ++--
 formula/source/ui/dlg/parawin.hxx   |6 +++---
 formula/source/ui/dlg/structpg.cxx  |6 +++---
 formula/source/ui/dlg/structpg.hxx  |   10 +-
 include/filter/msfilter/escherex.hxx|6 +++---
 include/filter/msfilter/mstoolbar.hxx   |   20 ++--
 include/filter/msfilter/svdfppt.hxx |2 +-
 include/formula/tokenarray.hxx  |6 +++---
 23 files changed, 56 insertions(+), 56 deletions(-)

New commits:
commit 2c7aa60b69967a80b7874503f0e9e85546a04cde
Author: Noel Grandin 
AuthorDate: Tue Sep 3 16:17:03 2019 +0200
Commit: Noel Grandin 
CommitDate: Wed Sep 4 08:16:00 2019 +0200

loplugin:constmethod in filter

Change-Id: Ib337c45c0ee7de881313b000bf2f8d816fd17884
Reviewed-on: https://gerrit.libreoffice.org/78565
Tested-by: Jenkins
Reviewed-by: Noel Grandin 

diff --git a/filter/source/flash/swfwriter.hxx 
b/filter/source/flash/swfwriter.hxx
index 7d65a21a20fa..ecb04e9dd0ce 100644
--- a/filter/source/flash/swfwriter.hxx
+++ b/filter/source/flash/swfwriter.hxx
@@ -145,7 +145,7 @@ public:
 void write( SvStream& out );
 
 sal_uInt16 getID() const { return mnId; }
-const vcl::Font& getFont() { return maFont; }
+const vcl::Font& getFont() const { return maFont; }
 
 private:
 const vcl::Font maFont;
diff --git a/filter/source/graphicfilter/icgm/cgm.cxx 
b/filter/source/graphicfilter/icgm/cgm.cxx
index 22240779768d..8122d399eaa6 100644
--- a/filter/source/graphicfilter/icgm/cgm.cxx
+++ b/filter/source/graphicfilter/icgm/cgm.cxx
@@ -75,7 +75,7 @@ CGM::~CGM()
 maDefRepSizeList.clear();
 };
 
-sal_uInt32 CGM::GetBackGroundColor()
+sal_uInt32 CGM::GetBackGroundColor() const
 {
 return pElement ? pElement->aColorTable[ 0 ] : 0;
 }
diff --git a/filter/source/graphicfilter/icgm/cgm.hxx 
b/filter/source/graphicfilter/icgm/cgm.hxx
index 388b5eea3dcc..19773b9117c1 100644
--- a/filter/source/graphicfilter/icgm/cgm.hxx
+++ b/filter/source/graphicfilter/icgm/cgm.hxx
@@ -133,7 +133,7 @@ class CGM
 ~CGM();
 
 CGM(css::uno::Reference< css::frame::XModel > 
const & rModel);
-sal_uInt32  GetBackGroundColor();
+sal_uInt32  GetBackGroundColor() const;
 boolIsValid() const { return mbStatus; };
 boolIsFinished() const { return mbIsFinished; };
 boolWrite( SvStream& rIStm );
diff --git a/filter/source/graphicfilter/icgm/chart.cxx 
b/filter/source/graphicfilter/icgm/chart.cxx
index 845fab4e0d77..439d941c33ad 100644
--- a/filter/source/graphicfilter/icgm/chart.cxx
+++ b/filter/source/graphicfilter/icgm/chart.cxx
@@ -50,7 +50,7 @@ void CGMChart::ResetAnnotation()
 mDataNode[ 0 ].nZoneEnum = 0;
 }
 
-bool CGMChart::IsAnnotation()
+bool CGMChart::IsAnnotation() const
 {
 return ( mDataNode[ 0 ].nZoneEnum == 0 );
 }
diff --git a/filter/source/graphicfilter/icgm/chart.hxx 
b/filter/source/graphicfilter/icgm/chart.hxx
index 837015614696..839be2e4a196 100644
--- a/filter/source/graphicfilter/icgm/chart.hxx
+++ b/filter/source/graphicfilter/icgm/chart.hxx
@@ -74,7 +74,7 @@ class CGMChart final
 voidInsertTextEntry( std::unique_ptr );
 
 voidResetAnnotation();
-boolIsAnnotation();
+boolIsAnnotation() const;
 };
 
 #endif
diff --git a/filter/source/graphicfilter/ios2met/ios2met.cxx 
b/filter/source/graphicfilter/ios2met/ios2met.cxx
index f1d8e5661083..236506aff7cc 100644
--- a/filter/source/graphicfilter/ios2met/ios2met.cxx
+++ b/filter/source/graphicfilter/ios2met/ios2met.cxx
@@ -378,7 +378,7 @@ private:
 Color GetPaletteColor(sal_uInt32 nIndex);
 
 
-boolIsLineInfo();
+boolIsLineInfo() const;
 voidDrawPolyLine( const tools::Polygon& rPolygon );
 voidDrawPolygon( const tools::Polygon& rPolygon );
 

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

[László Németh (via logerrit)]

 sc/source/filter/excel/xeview.cxx |6 --
 sc/source/filter/inc/xeview.hxx   |1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

New commits:
commit 47aa9324e3d15fcc9d1195b9b0822b5568e6d96e
Author: László Németh 
AuthorDate: Tue Sep 3 17:19:18 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 08:28:19 2019 +0200

tdf#127110 XLSX export: fix bad view position

Update SheetView attribute topLeftCell only
in the case of embedded OLE sheets.

Regression from commit 3707e2a7b8b05617b0afb75374f866c967593861
"tdf#122624 XLSX OLE in DOCX: export view positions".

Change-Id: I9ea57ff1531d710bff34df12fb7e0bb1e3edbea5
Reviewed-on: https://gerrit.libreoffice.org/78570
Tested-by: Jenkins
Reviewed-by: László Németh 

diff --git a/sc/source/filter/excel/xeview.cxx 
b/sc/source/filter/excel/xeview.cxx
index 964b7d2447b0..91a372700560 100644
--- a/sc/source/filter/excel/xeview.cxx
+++ b/sc/source/filter/excel/xeview.cxx
@@ -285,7 +285,8 @@ sal_uInt16 lclGetXclZoom( long nScZoom, sal_uInt16 
nDefXclZoom )
 
 XclExpTabViewSettings::XclExpTabViewSettings( const XclExpRoot& rRoot, SCTAB 
nScTab ) :
 XclExpRoot( rRoot ),
-mnGridColorId( XclExpPalette::GetColorIdFromIndex( EXC_COLOR_WINDOWTEXT ) )
+mnGridColorId( XclExpPalette::GetColorIdFromIndex( EXC_COLOR_WINDOWTEXT ) 
),
+mbHasTabSettings(false)
 {
 // *** sheet flags ***
 
@@ -304,6 +305,7 @@ XclExpTabViewSettings::XclExpTabViewSettings( const 
XclExpRoot& rRoot, SCTAB nSc
 
 if( const ScExtTabSettings* pTabSett = GetExtDocOptions().GetTabSettings( 
nScTab ) )
 {
+mbHasTabSettings = true;
 const ScExtTabSettings& rTabSett = *pTabSett;
 XclExpAddressConverter& rAddrConv = GetAddressConverter();
 
@@ -419,7 +421,7 @@ void XclExpTabViewSettings::SaveXml( XclExpXmlStream& rStrm 
)
 rWorksheet->startElement(XML_sheetViews);
 
 // handle missing viewdata at embedded XLSX OLE objects
-if (maData.mbSelected)
+if( !mbHasTabSettings && maData.mbSelected )
 {
 SCCOL nPosLeft = rStrm.GetRoot().GetDoc().GetPosLeft();
 SCROW nPosTop = rStrm.GetRoot().GetDoc().GetPosTop();
diff --git a/sc/source/filter/inc/xeview.hxx b/sc/source/filter/inc/xeview.hxx
index 4416417ea623..8d320177d8d0 100644
--- a/sc/source/filter/inc/xeview.hxx
+++ b/sc/source/filter/inc/xeview.hxx
@@ -159,6 +159,7 @@ private:
 private:
 XclTabViewData  maData; /// All view settings for a sheet.
 sal_uInt32  mnGridColorId;  /// Color identifier for grid 
color.
+boolmbHasTabSettings;   /// It's false for embedded OLE 
spreadsheets.
 };
 
 #endif
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Noel Grandin (via logerrit)]

 include/svx/sdr/contact/viewcontact.hxx   |8 +---
 include/svx/sdr/contact/viewcontactofsdrobj.hxx   |2 +-
 sd/source/core/CustomAnimationEffect.cxx  |2 +-
 svx/source/engine3d/view3d.cxx|2 +-
 svx/source/sdr/contact/viewcontact.cxx|8 
 svx/source/sdr/contact/viewcontactofsdrobj.cxx|8 
 svx/source/sdr/contact/viewcontactofsdrobjcustomshape.cxx |2 +-
 svx/source/sdr/contact/viewcontactofvirtobj.cxx   |2 +-
 svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx  |2 +-
 svx/source/svdraw/svdobj.cxx  |4 ++--
 svx/source/svdraw/svdotxtr.cxx|2 +-
 11 files changed, 22 insertions(+), 20 deletions(-)

New commits:
commit 2340c2ffe46271c5a14e8831b8a8f5b56ed2da8c
Author: Noel Grandin 
AuthorDate: Wed Sep 4 09:17:42 2019 +0200
Commit: Noel Grandin 
CommitDate: Wed Sep 4 10:16:20 2019 +0200

reduce Primitive2DContainer copying

Change-Id: I418b17034c1949ddda1de7025821ca51f4cdb018
Reviewed-on: https://gerrit.libreoffice.org/78579
Tested-by: Jenkins
Reviewed-by: Noel Grandin 

diff --git a/include/svx/sdr/contact/viewcontact.hxx 
b/include/svx/sdr/contact/viewcontact.hxx
index edc70af19b54..d3455ac77cd0 100644
--- a/include/svx/sdr/contact/viewcontact.hxx
+++ b/include/svx/sdr/contact/viewcontact.hxx
@@ -124,10 +124,12 @@ public:
 // add Gluepoints (if available)
 virtual drawinglayer::primitive2d::Primitive2DContainer 
createGluePointPrimitive2DSequence() const;
 
-// allow embedding if needed (e.g. for SdrObjects, evtl. Name, Title and 
description get added). This
+// Allow embedding if needed (e.g. for SdrObjects, evtl. Name, Title and 
description get added). This
 // is a helper normally used from 
getViewIndependentPrimitive2DContainer(), but there is one exception
-// for 3D scenes
-virtual drawinglayer::primitive2d::Primitive2DContainer 
embedToObjectSpecificInformation(const 
drawinglayer::primitive2d::Primitive2DContainer& rSource) const;
+// for 3D scenes.
+// We take the param by value, since, for the common case, we can just 
std::move into the param, and
+// std::move the result out, avoiding copying.
+virtual drawinglayer::primitive2d::Primitive2DContainer 
embedToObjectSpecificInformation(drawinglayer::primitive2d::Primitive2DContainer
 rSource) const;
 
 virtual basegfx::B2DRange getRange( const 
drawinglayer::geometry::ViewInformation2D& rViewInfo2D ) const;
 
diff --git a/include/svx/sdr/contact/viewcontactofsdrobj.hxx 
b/include/svx/sdr/contact/viewcontactofsdrobj.hxx
index df2840476bcd..2508316a7c9f 100644
--- a/include/svx/sdr/contact/viewcontactofsdrobj.hxx
+++ b/include/svx/sdr/contact/viewcontactofsdrobj.hxx
@@ -77,7 +77,7 @@ public:
 // allow embedding if needed (e.g. for SdrObjects, evtl. Name, Title and 
description get added). This
 // is a helper normally used from 
getViewIndependentPrimitive2DContainer(), but there is one exception
 // for 3D scenes
-virtual drawinglayer::primitive2d::Primitive2DContainer 
embedToObjectSpecificInformation(const 
drawinglayer::primitive2d::Primitive2DContainer& rSource) const override;
+virtual drawinglayer::primitive2d::Primitive2DContainer 
embedToObjectSpecificInformation(drawinglayer::primitive2d::Primitive2DContainer
 aSource) const override;
 };
 
 }}
diff --git a/sd/source/core/CustomAnimationEffect.cxx 
b/sd/source/core/CustomAnimationEffect.cxx
index 102df7fb1f2f..1a08b9b4d7de 100644
--- a/sd/source/core/CustomAnimationEffect.cxx
+++ b/sd/source/core/CustomAnimationEffect.cxx
@@ -1563,7 +1563,7 @@ void CustomAnimationEffect::updatePathFromSdrPathObj( 
const SdrPathObj& rPathObj
 {
 ::tools::Rectangle aBoundRect(0,0,0,0);
 
-const drawinglayer::primitive2d::Primitive2DContainer 
xPrimitives(pObj->GetViewContact().getViewIndependentPrimitive2DContainer());
+const drawinglayer::primitive2d::Primitive2DContainer& 
xPrimitives(pObj->GetViewContact().getViewIndependentPrimitive2DContainer());
 const drawinglayer::geometry::ViewInformation2D aViewInformation2D;
 const basegfx::B2DRange 
aRange(xPrimitives.getB2DRange(aViewInformation2D));
 
diff --git a/svx/source/engine3d/view3d.cxx b/svx/source/engine3d/view3d.cxx
index b6d170554f64..67b974b26cb0 100644
--- a/svx/source/engine3d/view3d.cxx
+++ b/svx/source/engine3d/view3d.cxx
@@ -124,7 +124,7 @@ 
Impl3DMirrorConstructOverlay::Impl3DMirrorConstructOverlay(const E3dView& rView)
 {
 // use the view-independent primitive representation 
(without
 // evtl. GridOffset, that may be applied to the 
DragEntry individually)
-const drawinglayer::primitive2d::Primitive2DContainer 
aNewSequence(
+const 

Re: GSoC19 - Android Viewer(Online) - Final Report

[Jan Holesovsky]

Hi Kaishu,

Kaishu Sahu píše v Út 27. 08. 2019 v 02:13 +0530:

> Following is the link to the project's(Android Viewer Online) final
> report -
> https://gist.github.com/Kaishu-Sahu/aa4fa27dd181b8751952ad8f99370c4a

Thank you for your great work in this GSoC, you've achieved a lot! 
Hope to see you around even after the end of the GSoC :-)

All the best,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Tünde Tóth (via logerrit)]

 sw/qa/extras/ooxmlexport/data/tdf127116.odt   |binary
 sw/qa/extras/ooxmlexport/ooxmlexport10.cxx|5 -
 sw/qa/extras/ooxmlexport/ooxmlexport13.cxx|   11 +++
 sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx |2 +-
 sw/source/filter/ww8/docxattributeoutput.cxx  |5 +
 5 files changed, 21 insertions(+), 2 deletions(-)

New commits:
commit 79939168b47ae9c8089c93f88ed322dff67203fe
Author: Tünde Tóth 
AuthorDate: Thu Aug 29 11:54:22 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 12:34:36 2019 +0200

tdf#127116 DOCX export: fix hyperlink to bookmark target with spaces

Conversion of spaces to underline characters was only in bookmark names,
but not in the URLs using these bookmark names.


Change-Id: Idb0d9945c79139d8a935ffcf6a3b29a9298c2270
Reviewed-on: https://gerrit.libreoffice.org/78267
Reviewed-by: László Németh 
Tested-by: László Németh 

diff --git a/sw/qa/extras/ooxmlexport/data/tdf127116.odt 
b/sw/qa/extras/ooxmlexport/data/tdf127116.odt
new file mode 100644
index ..2825b34c078f
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/tdf127116.odt differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport10.cxx 
b/sw/qa/extras/ooxmlexport/ooxmlexport10.cxx
index a57b1ad39f96..babff3bbec07 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport10.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport10.cxx
@@ -128,8 +128,11 @@ DECLARE_OOXMLEXPORT_TEST(testSmartart, "smartart.docx")
 
 DECLARE_OOXMLEXPORT_TEST(testFdo69548, "fdo69548.docx")
 {
+if (!mbExported)
+return;
+
 // The problem was that the last space in target URL was removed
-CPPUNIT_ASSERT_EQUAL(OUString("#this is a bookmark"), 
getProperty(getRun(getParagraph(1), 1), "HyperLinkURL"));
+CPPUNIT_ASSERT_EQUAL(OUString("#this_is_a_bookmark"), 
getProperty(getRun(getParagraph(1), 1), "HyperLinkURL"));
 }
 
 DECLARE_OOXMLEXPORT_TEST(testWpsOnly, "wps-only.docx")
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx 
b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
index 295177486228..ed6bcc309c93 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
@@ -640,6 +640,17 @@ DECLARE_OOXMLEXPORT_TEST(tdf118169, "tdf118169.docx")
 CPPUNIT_ASSERT_EQUAL(OUString(u"őőő"), 
getProperty(xPropertySet, "Label"));
 }
 
+DECLARE_OOXMLEXPORT_TEST(testTdf127116, "tdf127116.odt")
+{
+xmlDocPtr pXmlDoc = parseExport("word/document.xml");
+if (!pXmlDoc)
+return;
+
+OUString bookmarkName = getXPath(pXmlDoc, 
"/w:document/w:body/w:p[1]/w:bookmarkStart", "name");
+OUString anchor = getXPath(pXmlDoc, 
"/w:document/w:body/w:p[2]/w:hyperlink", "anchor");
+CPPUNIT_ASSERT_EQUAL(anchor, bookmarkName);
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx 
b/sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx
index d716ad535f84..e269a3bfba6e 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx
@@ -651,7 +651,7 @@ DECLARE_OOXMLEXPORT_TEST(testToxmarkHyperlink, 
"toxmarkhyperlink.fodt")
 DECLARE_OOXMLEXPORT_TEST(testOO34469, "ooo34469-1.odt")
 {
 if (xmlDocPtr pXmlDoc = parseExport())
-assertXPath(pXmlDoc, "/w:document/w:body/w:p[1]/w:hyperlink[1]", 
"anchor", "2.9.2.Creating New files|outline");
+assertXPath(pXmlDoc, "/w:document/w:body/w:p[1]/w:hyperlink[1]", 
"anchor", "2.9.2.Creating_New_files|outline");
 }
 
 DECLARE_OOXMLEXPORT_TEST(testOO39845, "ooo39845-7.odt")
diff --git a/sw/source/filter/ww8/docxattributeoutput.cxx 
b/sw/source/filter/ww8/docxattributeoutput.cxx
index 0a0a8a94badb..debba8ae9ae1 100644
--- a/sw/source/filter/ww8/docxattributeoutput.cxx
+++ b/sw/source/filter/ww8/docxattributeoutput.cxx
@@ -2914,6 +2914,11 @@ bool DocxAttributeOutput::StartURL( const OUString& 
rUrl, const OUString& rTarge
 }
 }
 }
+if (sMark.indexOf(' ') != -1 && !sMark.endsWith("|table") && 
!sMark.endsWith("|frame") && !sMark.endsWith("|graphic") && 
!sMark.endsWith("|ole") && !sMark.endsWith("|region"))
+{
+// Spaces are prohibited in bookmark name.
+sMark = sMark.replace(' ', '_');
+}
 m_pHyperlinkAttrList->add( FSNS( XML_w, XML_anchor ),
 OUStringToOString( sMark, RTL_TEXTENCODING_UTF8 ).getStr( 
) );
 }
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Andreas Heinisch (via logerrit)]

 basctl/source/basicide/moduldl2.cxx |   10 --
 basctl/source/basicide/moduldlg.cxx |7 +--
 2 files changed, 9 insertions(+), 8 deletions(-)

New commits:
commit e8b3df5b9b0eb0a93c25b6dc2e445ae44a7e3f78
Author: Andreas Heinisch 
AuthorDate: Fri Aug 2 14:57:49 2019 +0200
Commit: Samuel Mehrbrodt 
CommitDate: Wed Sep 4 08:52:50 2019 +0200

tdf#93476 Sort Macro library list after creating/importing a macro

Only set the widget as sorted in the ctor, it remains sorted

Change-Id: I96897cf5512e91192c69874ca857a967b09a1490
Reviewed-on: https://gerrit.libreoffice.org/76866
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt 

diff --git a/basctl/source/basicide/moduldl2.cxx 
b/basctl/source/basicide/moduldl2.cxx
index 18ed7f1a0796..c55b40e60c61 100644
--- a/basctl/source/basicide/moduldl2.cxx
+++ b/basctl/source/basicide/moduldl2.cxx
@@ -217,6 +217,9 @@ LibPage::LibPage(weld::Container* pParent, OrganizeDialog* 
pDialog)
m_xLibBox->get_height_rows(10));
 m_xLibBox->set_size_request(aSize.Width(), aSize.Height());
 
+// tdf#93476 The libraries should be listed alphabetically
+m_xLibBox->make_sorted();
+
 m_xEditButton->connect_clicked( LINK( this, LibPage, ButtonHdl ) );
 m_xNewLibButton->connect_clicked( LINK( this, LibPage, ButtonHdl ) );
 m_xPasswordButton->connect_clicked( LINK( this, LibPage, ButtonHdl ) );
@@ -648,7 +651,6 @@ void LibPage::InsertLib()
 const int nRow = rView.n_children() - 1;
 rView.set_toggle(nRow, TRISTATE_TRUE, 0);
 rView.set_text(nRow, aLibName, 1);
-rView.make_sorted();
 rView.set_cursor(rView.find_text(aLibName));
 }
 }
@@ -675,7 +677,6 @@ void LibPage::InsertLib()
 return;
 
 bool bChanges = false;
-int nNewPos = m_xLibBox->n_children();
 bool bRemove = false;
 bool bReplace = xLibDlg->IsReplace();
 bool bReference = xLibDlg->IsReference();
@@ -894,13 +895,11 @@ void LibPage::InsertLib()
 
 // insert listbox entry
 ImpInsertLibEntry( aLibName, m_xLibBox->n_children() );
+m_xLibBox->set_cursor( m_xLibBox->find_text(aLibName) );
 bChanges = true;
 }
 }
 
-if (nNewPos < m_xLibBox->n_children())
-m_xLibBox->set_cursor(nNewPos);
-
 if ( bChanges )
 MarkDocumentModified( m_aCurDocument );
 });
@@ -1323,7 +1322,6 @@ void createLibImpl(weld::Window* pWin, const 
ScriptDocument& rDocument,
 if( pLibBox )
 {
 pLibBox->append_text(aLibName);
-pLibBox->make_sorted();
 pLibBox->set_cursor(pLibBox->find_text(aLibName));
 }
 
diff --git a/basctl/source/basicide/moduldlg.cxx 
b/basctl/source/basicide/moduldlg.cxx
index cf4ff447547f..fb1d72e2d161 100644
--- a/basctl/source/basicide/moduldlg.cxx
+++ b/basctl/source/basicide/moduldlg.cxx
@@ -537,6 +537,9 @@ ObjectPage::ObjectPage(weld::Container* pParent, const 
OString , BrowseMod
m_xBasicBox->get_height_rows(14));
 m_xBasicBox->set_size_request(aSize.Width(), aSize.Height());
 
+// tdf#93476 The dialogs should be listed alphabetically
+m_xBasicBox->make_sorted();
+
 m_xEditButton->connect_clicked( LINK( this, ObjectPage, ButtonHdl ) );
 m_xDelButton->connect_clicked( LINK( this, ObjectPage, ButtonHdl ) );
 m_xBasicBox->connect_changed( LINK( this, ObjectPage, BasicBoxHighlightHdl 
) );
@@ -817,7 +820,6 @@ void ObjectPage::NewDialog()
 m_xBasicBox->AddEntry(aDlgName, RID_BMP_DIALOG, 
xSubRootEntry.get(), false,

std::make_unique(OBJ_TYPE_DIALOG), xIter.get());
 assert(xIter.get() && "Insert entry failed!");
-m_xBasicBox->make_sorted();
 }
 m_xBasicBox->set_cursor(*xIter);
 m_xBasicBox->select(*xIter);
@@ -888,6 +890,8 @@ LibDialog::LibDialog(weld::Window* pParent)
 {
 m_xLibBox->set_size_request(m_xLibBox->get_approximate_digit_width() * 28,
 m_xLibBox->get_height_rows(8));
+// tdf#93476 The libraries should be listed alphabetically
+m_xLibBox->make_sorted();
 }
 
 LibDialog::~LibDialog()
@@ -976,7 +980,6 @@ SbModule* createModImpl(weld::Window* pWin, const 
ScriptDocument& rDocument,
 {
 rBasicBox.AddEntry(aModName, RID_BMP_MODULE, 
xSubRootEntry.get(), false,

std::make_unique(OBJ_TYPE_MODULE), xEntry.get());
-rBasicBox.make_sorted();
 }
 rBasicBox.set_cursor(*xEntry);
 

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

[Stephan Bergmann (via logerrit)]

 sw/source/filter/ww8/ww8par.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit c6ad32e03de01525a863171ed58df05e89e9f105
Author: Stephan Bergmann 
AuthorDate: Wed Sep 4 10:39:19 2019 +0200
Commit: Stephan Bergmann 
CommitDate: Wed Sep 4 13:01:47 2019 +0200

Fix typo in bug ID

The comment had been added with e38e3fc6c0ba5cef622f7412a573bd96c2476ca2
"#i9240# During 8bit conversion fallback to 1252 if a character is 
undefined in
our source charset. Word appears to do this" (i.e., mentioning i9240 
instead of
i9241), and  "Do not show
lithuanian letter 'Š'" looks more relevant here than
 "The compound words
�FAKSIMILINIS PRANE�IMAS� have to be Align Centered
Horizontally."

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

diff --git a/sw/source/filter/ww8/ww8par.cxx b/sw/source/filter/ww8/ww8par.cxx
index 744772c46478..ecfb44878133 100644
--- a/sw/source/filter/ww8/ww8par.cxx
+++ b/sw/source/filter/ww8/ww8par.cxx
@@ -2886,7 +2886,7 @@ void SwWW8ImplReader::PostProcessAttrs()
 }
 
 /*
- #i9241#
+ #i9240#
  It appears that some documents that are in a baltic 8 bit encoding which has
  some undefined characters can have use made of those characters, in which
  case they default to CP1252. If not then it's perhaps that the font encoding
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Tamas Bunth (via logerrit)]

 connectivity/source/drivers/mysqlc/mysqlc_connection.cxx |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

New commits:
commit 8483f48aa90d9c487320af855e333c1e6c9453c2
Author: Tamas Bunth 
AuthorDate: Tue Sep 3 15:29:55 2019 +0200
Commit: Xisco Faulí 
CommitDate: Wed Sep 4 12:19:00 2019 +0200

tdf#127093 mysqlc: set NO_AUTO_VALUE_ON_ZERO

Without setting this sql_mode, NULL or 0 inserted to an auto-incremented 
column
of a prepared statement would cause that to be auto generated.

Setting NO_AUTO_VALUE_ON_ZERO allows us to copy/paste auto-incremented
columns which may contain zero values as well.

Change-Id: I9602746371c75c82c99ff63240025e8cfb03776a
Reviewed-on: https://gerrit.libreoffice.org/78560
Tested-by: Jenkins
Reviewed-by: Tamás Bunth 
(cherry picked from commit 91a97c5e0b7b760ec0b46ad38b28ec1419c7d48f)
Reviewed-on: https://gerrit.libreoffice.org/78582
Reviewed-by: Xisco Faulí 

diff --git a/connectivity/source/drivers/mysqlc/mysqlc_connection.cxx 
b/connectivity/source/drivers/mysqlc/mysqlc_connection.cxx
index 74613a733a3a..4ad4d2c6f29b 100644
--- a/connectivity/source/drivers/mysqlc/mysqlc_connection.cxx
+++ b/connectivity/source/drivers/mysqlc/mysqlc_connection.cxx
@@ -196,7 +196,8 @@ void OConnection::construct(const OUString& url, const 
Sequence&
*this, OUString(), 0, Any());
 }
 
-lcl_executeUpdate(_mysql, OString{ "SET session sql_mode='ANSI_QUOTES'" 
});
+lcl_executeUpdate(_mysql,
+  OString{ "SET session 
sql_mode='ANSI_QUOTES,NO_AUTO_VALUE_ON_ZERO'" });
 lcl_executeUpdate(_mysql, OString{ "SET NAMES utf8" });
 }
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: compilerplugins/clang include/sfx2 include/vcl sfx2/Library_sfx.mk sfx2/sdi sfx2/source solenv/clang-format vcl/inc vcl/Library_vclplug_gen.mk vcl/osx vcl/source vcl/un

[Szabolcs Toth (via logerrit)]

 compilerplugins/clang/badstatics.cxx|3 
 compilerplugins/clang/unusedenumconstants.writeonly.results |2 
 include/sfx2/sfxsids.hrc|1 
 include/vcl/svapp.hxx   |   42 -
 sfx2/Library_sfx.mk |1 
 sfx2/sdi/appslots.sdi   |5 
 sfx2/sdi/sfx.sdi|   19 
 sfx2/source/appl/app.cxx|3 
 sfx2/source/appl/appdata.cxx|2 
 sfx2/source/appl/appserv.cxx|   26 
 sfx2/source/appl/imestatuswindow.cxx|  229 --
 sfx2/source/appl/imestatuswindow.hxx|  119 ---
 sfx2/source/inc/appdata.hxx |3 
 solenv/clang-format/blacklist   |5 
 vcl/Library_vclplug_gen.mk  |1 
 vcl/inc/pch/precompiled_vcl.hxx |1 
 vcl/inc/salimestatus.hxx|   39 -
 vcl/inc/salinst.hxx |4 
 vcl/inc/svdata.hxx  |   15 
 vcl/inc/unx/gtk/gtkinst.hxx |3 
 vcl/inc/unx/i18n_ic.hxx |4 
 vcl/inc/unx/i18n_status.hxx |   89 --
 vcl/inc/unx/salinst.h   |1 
 vcl/osx/salinst.cxx |1 
 vcl/source/app/salvtables.cxx   |   10 
 vcl/source/app/svapp.cxx|   29 
 vcl/source/app/svdata.cxx   |1 
 vcl/source/app/svmain.cxx   |4 
 vcl/unx/generic/app/i18n_cb.cxx |2 
 vcl/unx/generic/app/i18n_ic.cxx |   23 
 vcl/unx/generic/app/i18n_im.cxx |2 
 vcl/unx/generic/app/i18n_status.cxx |  439 
 vcl/unx/generic/window/salframe.cxx |   52 -
 vcl/unx/gtk/gtkinst.cxx |   11 
 vcl/win/app/salinst.cxx |1 
 35 files changed, 13 insertions(+), 1179 deletions(-)

New commits:
commit 5bfa8b8d5e1cf3cb572dbd91bf3b0cfcf29fb65a
Author: Szabolcs Toth 
AuthorDate: Mon Aug 12 10:58:40 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 09:12:32 2019 +0200

tdf#118314 Code clean up on imestatuswindow

Change-Id: I8bc5a73a91f28fcfd22ef716e9cf87d53997b1ad
Reviewed-on: https://gerrit.libreoffice.org/77337
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl 
Reviewed-by: László Németh 

diff --git a/compilerplugins/clang/badstatics.cxx 
b/compilerplugins/clang/badstatics.cxx
index 1c099a14236a..5f1edea78476 100644
--- a/compilerplugins/clang/badstatics.cxx
+++ b/compilerplugins/clang/badstatics.cxx
@@ -159,8 +159,7 @@ public:
 && pVarDecl->isThisDeclarationADefinition())
 {
 auto const name(pVarDecl->getName());
-if (   name == "g_pI18NStatusInstance" // I18NStatus::free()
-|| name == "s_pPreviousView" // not an owning pointer
+if (   name == "s_pPreviousView" // not an owning pointer
 || name == "s_pDefCollapsed" // SvImpLBox::~SvImpLBox()
 || name == "s_pDefExpanded"  // SvImpLBox::~SvImpLBox()
 || name == "g_pDDSource" // SvTreeListBox::dispose()
diff --git a/compilerplugins/clang/unusedenumconstants.writeonly.results 
b/compilerplugins/clang/unusedenumconstants.writeonly.results
index e1a9019589bc..38d6a1783e53 100644
--- a/compilerplugins/clang/unusedenumconstants.writeonly.results
+++ b/compilerplugins/clang/unusedenumconstants.writeonly.results
@@ -10414,8 +10414,6 @@ vcl/inc/salframe.hxx:72
 enum SalFrameStyleFlags NOSHADOW
 vcl/inc/salptype.hxx:32
 enum JobSetFlags ALL
-vcl/inc/svdata.hxx:134
-enum ImplSVAppData::ImeStatusWindowMode ImeStatusWindowMode_UNKNOWN
 vcl/inc/unx/desktops.hxx:29
 enum DesktopType DESKTOP_UNKNOWN
 vcl/inc/unx/i18n_cb.hxx:67
diff --git a/include/sfx2/sfxsids.hrc b/include/sfx2/sfxsids.hrc
index 1dcc40fc8ee4..80c92e1cdc2a 100644
--- a/include/sfx2/sfxsids.hrc
+++ b/include/sfx2/sfxsids.hrc
@@ -211,7 +211,6 @@ class SvxSearchItem;
 #define SID_INTERACTIONHANDLER  (SID_SFX_START + 1675)
 #define SID_OPENHYPERLINK   (SID_SFX_START + 1676)
 #define SID_CONTENT (SID_SFX_START + 1679)
-#define SID_SHOW_IME_STATUS_WINDOW  (SID_SFX_START + 1680)
 #define SID_VIEWONLY(SID_SFX_START + 1682)
 #define SID_REPAIRPACKAGE   (SID_SFX_START + 

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

[Kelemen Gábor (via logerrit)]

 sw/source/ui/dbui/addresslistdialog.cxx |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit a9e098aa4e66c771642b26527e3e48c48c428574
Author: Kelemen Gábor 
AuthorDate: Tue Aug 6 14:22:36 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 10:20:14 2019 +0200

tdf#125330 Disable Filter and Change Table buttons

in the Select Address List dialog if there are no entries

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

diff --git a/sw/source/ui/dbui/addresslistdialog.cxx 
b/sw/source/ui/dbui/addresslistdialog.cxx
index be4d6275fb74..88aabd52855e 100644
--- a/sw/source/ui/dbui/addresslistdialog.cxx
+++ b/sw/source/ui/dbui/addresslistdialog.cxx
@@ -211,6 +211,8 @@ 
SwAddressListDialog::SwAddressListDialog(SwMailMergeAddressBlockPage* pParent)
 m_xOK->set_sensitive(m_xListLB->n_children() > 0 && bEnableOK);
 m_xEditPB->set_sensitive(bEnableEdit);
 m_xRemovePB->set_sensitive(m_xListLB->n_children() > 0);
+m_xFilterPB->set_sensitive(m_xListLB->n_children() > 0);
+m_xTablePB->set_sensitive(m_xListLB->n_children() > 0);
 m_xListLB->connect_changed(LINK(this, SwAddressListDialog, 
ListBoxSelectHdl_Impl));
 TableSelectHdl(nullptr);
 }
@@ -307,6 +309,7 @@ IMPL_LINK_NOARG(SwAddressListDialog, RemoveHdl_Impl, 
weld::Button&, void)
 {
 m_xRemovePB->set_sensitive(false);
 m_xEditPB->set_sensitive(false);
+m_xFilterPB->set_sensitive(false);
 m_xCreateListPB->set_sensitive(true);
 }
 }
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Michael Stahl (via logerrit)]

 sw/qa/extras/ooxmlexport/data/tdf95848.docx   |binary
 sw/qa/extras/ooxmlexport/ooxmlexport13.cxx|   34 ++
 writerfilter/source/dmapper/DomainMapper.cxx  |6 +++
 writerfilter/source/dmapper/DomainMapper_Impl.cxx |   27 -
 writerfilter/source/dmapper/NumberingManager.cxx  |9 +
 writerfilter/source/dmapper/NumberingManager.hxx  |5 +++
 writerfilter/source/dmapper/PropertyMap.cxx   |3 -
 writerfilter/source/dmapper/PropertyMap.hxx   |8 ++---
 writerfilter/source/dmapper/StyleSheetTable.hxx   |2 -
 9 files changed, 86 insertions(+), 8 deletions(-)

New commits:
commit 7992bd73a2307edce96a145e954f8e4c3ab9f57d
Author: Michael Stahl 
AuthorDate: Tue Sep 3 13:49:57 2019 +0200
Commit: Michael Stahl 
CommitDate: Wed Sep 4 10:40:26 2019 +0200

tdf#95848 writerfilter: DOCX import: fix mapping of w:abstractNum

The problem is that the bugdoc has multiple w:num numbering definitions
that refer to the same w:abstractNum abstract numbering definition.

Apparently (and i can't find this documented anywhere) w:abstractNum
corresponds to a SwList in Writer, i.e. all w:num that refer to the same
w:abstractNum share the same numbering tree, but they may have different
numbering properties via w:lvlOverride.

So i think this should be imported as a single SwList per w:abstractNum,
and every use of w:lvlOverride should create a new SwNumRule, but still
share the same SwList; the previous situation was a SwNumRule + SwList
per w:num element.

This implements simply a SwNumRule per w:num (regardless of
w:lvlOverride) because that was easy; the AbstractListDef class gets a
member to store the ListId of the created SwList when any of its
associated w:num / ListDef is used first, and the non-first ones get
this ListId set to force them into the same SwList.

Unfortunately it turns out the export has the same
SwNumRule->w:abstractNum problem, which remains to be fixed.

Change-Id: I92ce989afd15f24e36b6be6ccaf67ba3e0128963
Reviewed-on: https://gerrit.libreoffice.org/78556
Tested-by: Jenkins
Reviewed-by: Michael Stahl 

diff --git a/sw/qa/extras/ooxmlexport/data/tdf95848.docx 
b/sw/qa/extras/ooxmlexport/data/tdf95848.docx
new file mode 100644
index ..3bf17f6928c1
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/tdf95848.docx differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx 
b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
index 804ec41a4bed..295177486228 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
@@ -66,6 +66,40 @@ DECLARE_OOXMLEXPORT_TEST(testTdf121374_sectionHF2, 
"tdf121374_sectionHF2.doc")
 CPPUNIT_ASSERT( xHeaderText->getString().startsWith("virkamatka-anomus") );
 }
 
+// TODO export has the same wrong assumption that abstractNum = SwNumRule
+DECLARE_SW_EXPORT_TEST(testTdf95848, "tdf95848.docx", nullptr, Test)
+{
+OUString listId;
+OUString listStyle;
+{
+uno::Reference xPara(getParagraph(1), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(static_cast(2), 
getProperty(xPara, "NumberingLevel"));
+CPPUNIT_ASSERT(xPara->getPropertyValue("NumberingStyleName") >>= 
listStyle);
+CPPUNIT_ASSERT(listStyle.startsWith("WWNum"));
+CPPUNIT_ASSERT(xPara->getPropertyValue("ListId") >>= listId);
+CPPUNIT_ASSERT_EQUAL(OUString("1.1.1"), getProperty(xPara, 
"ListLabelString"));
+}
+{
+uno::Reference xPara(getParagraph(2), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(static_cast(2), 
getProperty(xPara, "NumberingLevel"));
+CPPUNIT_ASSERT_EQUAL(listStyle, getProperty(xPara, 
"NumberingStyleName"));
+CPPUNIT_ASSERT_EQUAL(listId, getProperty(xPara, "ListId"));
+CPPUNIT_ASSERT_EQUAL(OUString("1.1.2"), getProperty(xPara, 
"ListLabelString"));
+}
+{
+uno::Reference xPara(getParagraph(3), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(static_cast(2), 
getProperty(xPara, "NumberingLevel"));
+// different numbering style
+OUString listStyle3;
+CPPUNIT_ASSERT(xPara->getPropertyValue("NumberingStyleName") >>= 
listStyle3);
+CPPUNIT_ASSERT(listStyle3.startsWith("WWNum"));
+CPPUNIT_ASSERT(listStyle3 != listStyle);
+// but same list
+CPPUNIT_ASSERT_EQUAL(OUString("1.1.3"), getProperty(xPara, 
"ListLabelString"));
+CPPUNIT_ASSERT_EQUAL(listId, getProperty(xPara, "ListId"));
+}
+}
+
 DECLARE_OOXMLEXPORT_TEST(testTdf126723, "tdf126723.docx")
 {
 CPPUNIT_ASSERT_EQUAL(static_cast(0), 
getProperty(getParagraph(2), "ParaLeftMargin"));
diff --git a/writerfilter/source/dmapper/DomainMapper.cxx 
b/writerfilter/source/dmapper/DomainMapper.cxx
index f2cd94906405..6fff9546f18b 100644
--- a/writerfilter/source/dmapper/DomainMapper.cxx
+++ b/writerfilter/source/dmapper/DomainMapper.cxx
@@ 

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

[Balazs Varga (via logerrit)]

 chart2/source/view/axes/VCartesianAxis.cxx |   12 +++-
 sw/qa/extras/layout/data/tdf127304.odt |binary
 sw/qa/extras/layout/layout.cxx |   21 +
 3 files changed, 28 insertions(+), 5 deletions(-)

New commits:
commit 4b3a648a2fd7d733674f95bb7f20670c57e99252
Author: Balazs Varga 
AuthorDate: Tue Sep 3 14:54:52 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 13:36:35 2019 +0200

tdf#127304 Chart: fix rotation of multilevel axis labels

If the first level of horizontal category axis labels
is rotated vertically, then the other levels should not be
rotated.

Regression from commit: 23c0b3e13f88d6d71d528777d4f86f50c0766672
(tdf#107074 uncommenting createLabels for the axis fixes the issue)

Change-Id: Ia1978fdc345fa154cff2ea03d2a94475f73398a6
Reviewed-on: https://gerrit.libreoffice.org/78557
Reviewed-by: László Németh 
Tested-by: László Németh 

diff --git a/chart2/source/view/axes/VCartesianAxis.cxx 
b/chart2/source/view/axes/VCartesianAxis.cxx
index 34faa8bdac79..4874f7f9575f 100644
--- a/chart2/source/view/axes/VCartesianAxis.cxx
+++ b/chart2/source/view/axes/VCartesianAxis.cxx
@@ -757,8 +757,8 @@ bool VCartesianAxis::createTextShapes(
 }
 }
 
- // Stores an array of text label strings in case of a normal
- // (non-complex) category axis.
+// Stores an array of text label strings in case of a normal
+// (non-complex) category axis.
 const uno::Sequence* pCategories = nullptr;
 if( m_bUseTextLabels && !m_aAxisProperties.m_bComplexCategories )
 pCategories = _aTextLabels;
@@ -1680,10 +1680,12 @@ void VCartesianAxis::createLabels()
 {
 aComplexProps.bLineBreakAllowed = true;
 aComplexProps.bOverlapAllowed = 
aComplexProps.fRotationAngleDegree != 0.0;
-//Only the first level of complex vertical category axis 
labels orientation should be horizontal
-if( nTextLevel > 0 && m_aAxisProperties.m_bSwapXAndY )
+if( nTextLevel > 0 )
 {
-aComplexProps.fRotationAngleDegree = 90.0;
+if( m_aAxisProperties.m_bSwapXAndY )
+aComplexProps.fRotationAngleDegree = 90.0;
+else
+aComplexProps.fRotationAngleDegree = 0.0;
 }
 }
 AxisLabelProperties& rAxisLabelProperties =  
m_aAxisProperties.m_bComplexCategories ? aComplexProps : m_aAxisLabelProperties;
diff --git a/sw/qa/extras/layout/data/tdf127304.odt 
b/sw/qa/extras/layout/data/tdf127304.odt
new file mode 100644
index ..e8a4d6e03b0a
Binary files /dev/null and b/sw/qa/extras/layout/data/tdf127304.odt differ
diff --git a/sw/qa/extras/layout/layout.cxx b/sw/qa/extras/layout/layout.cxx
index 2a43db31486c..f5cae5aa8405 100644
--- a/sw/qa/extras/layout/layout.cxx
+++ b/sw/qa/extras/layout/layout.cxx
@@ -2320,6 +2320,27 @@ CPPUNIT_TEST_FIXTURE(SwLayoutWriter, testTdf126244)
 "900");
 }
 
+CPPUNIT_TEST_FIXTURE(SwLayoutWriter, testTdf127304)
+{
+SwDoc* pDoc = createDoc("tdf127304.odt");
+SwDocShell* pShell = pDoc->GetDocShell();
+
+// Dump the rendering of the first page as an XML file.
+std::shared_ptr xMetaFile = pShell->GetPreviewMetaFile();
+MetafileXmlDump dumper;
+xmlDocPtr pXmlDoc = dumpAndParse(dumper, *xMetaFile);
+CPPUNIT_ASSERT(pXmlDoc);
+// Test the first level of horizontal category axis labels orientation. 
The first level orientation should be vertical.
+assertXPath(pXmlDoc, 
"/metafile/push[1]/push[1]/push[1]/push[3]/push[1]/font[1]", "orientation",
+"900");
+// Test the second level of horizontal category axis labels orientation. 
The second level orientation should be horizontal.
+assertXPath(pXmlDoc, 
"/metafile/push[1]/push[1]/push[1]/push[3]/push[1]/font[5]", "orientation",
+"0");
+// Test the third level of horizontal category axis labels orientation. 
The third level orientation should be horizontal.
+assertXPath(pXmlDoc, 
"/metafile/push[1]/push[1]/push[1]/push[3]/push[1]/font[7]", "orientation",
+"0");
+}
+
 CPPUNIT_TEST_FIXTURE(SwLayoutWriter, testTdf124796)
 {
 SwDoc* pDoc = createDoc("tdf124796.odt");
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: Branch 'libreoffice-6-2' - sc/source

[Eike Rathke (via logerrit)]

 sc/source/ui/docshell/docsh.cxx  |   13 --
 sc/source/ui/docshell/docsh4.cxx |   64 +--
 sc/source/ui/docshell/externalrefmgr.cxx |1 
 sc/source/ui/inc/docsh.hxx   |2 
 4 files changed, 49 insertions(+), 31 deletions(-)

New commits:
commit 3d59261bfa6f02a36b20cd117ed25422c59fbe4f
Author: Eike Rathke 
AuthorDate: Fri Aug 16 15:36:15 2019 +0200
Commit: Caolán McNamara 
CommitDate: Wed Sep 4 12:02:21 2019 +0200

Resolves: tdf#126928 allow link updates in an intermediate linked document

... if link updates are allowed in the current document and that
intermediate document resides in a trusted location.

This works with both, the "Always (from trusted locations)" and
the "On request" settings under Tools -> Options -> Calc ->
General. It can't work with documents residing in a non-trusted
location as there is no way to allow updates on demand for a such
loaded document (hidden via formulas).

Reviewed-on: https://gerrit.libreoffice.org/77588
Reviewed-by: Eike Rathke 
Tested-by: Jenkins
(cherry picked from commit 54bf84746a2a9a2e2aaf0df9e429b0cfd538f640)

 Conflicts:
sc/source/ui/docshell/docsh4.cxx
sc/source/ui/docshell/externalrefmgr.cxx

Backported. Also includes

commit 1663b1e8233db6c6d1c2b35639ad984961084009
CommitDate: Tue Feb 26 21:15:57 2019 +0100

tdf#120736: For Calc shared documents also check the original 
document URL

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

diff --git a/sc/source/ui/docshell/docsh.cxx b/sc/source/ui/docshell/docsh.cxx
index 59fe24a832ec..3d20d85bfb31 100644
--- a/sc/source/ui/docshell/docsh.cxx
+++ b/sc/source/ui/docshell/docsh.cxx
@@ -601,15 +601,22 @@ bool ScDocShell::Load( SfxMedium& rMedium )
 bool bRet = SfxObjectShell::Load(rMedium);
 if (bRet)
 {
-comphelper::EmbeddedObjectContainer& rEmbeddedObjectContainer = 
getEmbeddedObjectContainer();
-rEmbeddedObjectContainer.setUserAllowsLinkUpdate(false);
-
 if (GetMedium())
 {
 const SfxUInt16Item* pUpdateDocItem = 
SfxItemSet::GetItem(rMedium.GetItemSet(), SID_UPDATEDOCMODE, 
false);
 m_nCanUpdate = pUpdateDocItem ? pUpdateDocItem->GetValue() : 
css::document::UpdateDocMode::NO_UPDATE;
 }
 
+// GetLinkUpdateModeState() evaluates m_nCanUpdate so that must have
+// been set first. Do not override an already forbidden LinkUpdate (the
+// default is allow).
+comphelper::EmbeddedObjectContainer& rEmbeddedObjectContainer = 
getEmbeddedObjectContainer();
+if (rEmbeddedObjectContainer.getUserAllowsLinkUpdate())
+{
+// For anything else than LM_ALWAYS we need user confirmation.
+rEmbeddedObjectContainer.setUserAllowsLinkUpdate( 
GetLinkUpdateModeState() == LM_ALWAYS);
+}
+
 {
 //  prepare a valid document for XML filter
 //  (for ConvertFrom, InitNew is called before)
diff --git a/sc/source/ui/docshell/docsh4.cxx b/sc/source/ui/docshell/docsh4.cxx
index e0214146bce9..ac2ebfb33a0b 100644
--- a/sc/source/ui/docshell/docsh4.cxx
+++ b/sc/source/ui/docshell/docsh4.cxx
@@ -154,6 +154,41 @@ IMPL_LINK_NOARG( ScDocShell, ReloadAllLinksHdl, Button*, 
void )
 SAL_WARN_IF(!pViewFrame, "sc", "expected there to be a ViewFrame");
 }
 
+ScLkUpdMode ScDocShell::GetLinkUpdateModeState() const
+{
+const ScDocument& rDoc = GetDocument();
+
+ScLkUpdMode nSet = rDoc.GetLinkMode();
+
+if (nSet == LM_UNKNOWN)
+{
+ScAppOptions aAppOptions = SC_MOD()->GetAppOptions();
+nSet = aAppOptions.GetLinkMode();
+}
+
+if (m_nCanUpdate == css::document::UpdateDocMode::NO_UPDATE)
+nSet = LM_NEVER;
+else if (m_nCanUpdate == css::document::UpdateDocMode::FULL_UPDATE)
+nSet = LM_ALWAYS;
+
+if (nSet == LM_ALWAYS
+&& !(SvtSecurityOptions().isTrustedLocationUriForUpdatingLinks(
+GetMedium() == nullptr ? OUString() : 
GetMedium()->GetName())
+|| (IsDocShared()
+&& 
SvtSecurityOptions().isTrustedLocationUriForUpdatingLinks(
+GetSharedFileURL()
+{
+nSet = LM_ON_DEMAND;
+}
+if (m_nCanUpdate == css::document::UpdateDocMode::QUIET_UPDATE
+&& nSet == LM_ON_DEMAND)
+{
+nSet = LM_NEVER;
+}
+
+return nSet;
+}
+
 void ScDocShell::Execute( SfxRequest& rReq )
 {
 const SfxItemSet* pReqArgs = rReq.GetArgs();
@@ -451,34 +486,7 @@ void ScDocShell::Execute( SfxRequest& rReq )
 break;
 case SID_UPDATETABLINKS:
 {
-ScDocument& rDoc = GetDocument();
-
-ScLkUpdMode 

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

[Stephan Bergmann (via logerrit)]

 include/rtl/textcvt.h |9 ++
 sal/qa/rtl/textenc/rtl_textcvt.cxx|2 -
 sal/textenc/convertbig5hkscs.cxx  |   22 +---
 sal/textenc/converteuctw.cxx  |   22 +---
 sal/textenc/convertgb18030.cxx|   32 ++--
 sal/textenc/convertisciidevangari.cxx |   19 ++
 sal/textenc/convertiso2022cn.cxx  |   23 ++---
 sal/textenc/convertiso2022jp.cxx  |   18 -
 sal/textenc/convertiso2022kr.cxx  |   17 +++--
 sal/textenc/convertsimple.cxx |3 ++
 sal/textenc/convertsinglebytetobmpunicode.cxx |3 ++
 sal/textenc/tcvtmb.cxx|   34 ++
 sal/textenc/tcvtutf7.cxx  |   17 +
 sal/textenc/tcvtutf8.cxx  |   15 +--
 14 files changed, 204 insertions(+), 32 deletions(-)

New commits:
commit ca6ddfcc9385f1c31531eae31dfa81a9dda246f0
Author: Stephan Bergmann 
AuthorDate: Wed Sep 4 09:36:03 2019 +0200
Commit: Stephan Bergmann 
CommitDate: Wed Sep 4 13:02:11 2019 +0200

[API CHANGE] rtl_convertTextToUnicode behavior upon erroneous input

 specifies that
FLAGS_UNDEFINED_ERROR, FLAGS_MBUNDEFINED_ERROR, and FLAGS_INVALID_ERROR: 
"Read
past the [erroneous] code in the input buffer [...]"  But actual behavior of
rtl_convertTextToUnicode for the various rtl_TextEncoding values has been
inconsistent.  Some erroneous input (mostly single-byte UNDEFINED and 
INVALID
ones) has not been consumed at all, some (multi-byte MBUNDEFINED and 
INVALID)
has been consumed partly, and some has been consumed fully as required.

However, at least since 8dd4265b9ddbd7786b6237676909eae5b540da0e 
"CWS-TOOLING:
integrate CWS hb18", Custom8BitToUnicode in sw/source/filter/ww8/ww8par.cxx
appears to rely on the broken behavior of not consuming erroneous input.  
(It
reads the chunk of valid input with e.g. some RTL_TEXTENCODING_MS_125x that
happens to exhibit the broken behavior of not consuming erroneous input, 
then
wants to try to re-read the erroneous input with RTL_TEXTENCODING_MS_1252.  
For
example, opening sw/qa/core/data/ww8/pass/forcepoint50-grfanchor-1.doc 
triggers
that code.  For whatever reason, the am_faksas.dot attached to
 "Do not show lithuanian
letter 'Š'" appears to not, or at least no longer, trigger that code.)

Therefore, it would be useful to have a mode in which 
rtl_convertTextToUnicode
does not consume erroneous input.  (And I plan on doing changes in
sal/osl/unx/file* that would benefit from that behavior, too.)  But changing
rtl_convertTextToUnicode to generally not consume erroneous input would not 
be
feasible:  If calls do not set RTL_TEXTTOUNICODE_FLAGS_FLUSH, part of an
erroneous input can already have been consumed by a previous call, so the
current call cannot undo that.

But a change that looks like it can work is to change the behavior only if
RTL_TEXTTOUNICODE_FLAGS_FLUSH is set.  In that case we can at least not 
consume
the part of an erroneous input that has not yet been consumed by a previous 
call
(which would necessarily have been done with RTL_TEXTTOUNICODE_FLAGS_FLUSH
unset).  The expecation is that code that relies on the don't-consume 
behavior
will do only single calls with RTL_TEXTTOUNICODE_FLAGS_FLUSH set (so 
reliably
not consume the complete erroneous input), while other code (which might do
calls in a loop) will not care whether erroneous input has been consumed,
anyway.  This can be considered a mild form of behavioral API CHANGE (but 
note
that the old implementation didn't exhibit the requested behavior anyway).

So all implementations of rtl_convertTextToUnicode for the various
rtl_TextEncoding values have been adapted to the new behavior.  The only
exceptions are ImplDummyToUnicode (sal/textenc/textcvt.cxx), which is a 
special
case anyway used by RTL_TEXTENCODING_DONTKNOW, and two out of three places
(marked with a "TODO" each) in ImplUTF7ToUnicode (sal/textenc/tcvtutf7.cxx),
where it is hard to retrofit the expected behaivor, and 
RTL_TEXTENCODING_UTF7 is
probably not relevant for the use cases relying on the 
don't-consume--behavior,
anyway.

Whether a similar change should be done for rtl_convertUnicodeToText can be
examined later.

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

diff --git a/include/rtl/textcvt.h b/include/rtl/textcvt.h
index 09c33b1cb0ed..67e9f55e0f65 100644
--- a/include/rtl/textcvt.h
+++ 

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

[Tamas Bunth (via logerrit)]

 dbaccess/source/ui/inc/DExport.hxx |3 ---
 dbaccess/source/ui/uno/copytablewizard.cxx |6 --
 2 files changed, 9 deletions(-)

New commits:
commit 8a9ce8164aedda16e6732845adfdae03a7c810de
Author: Tamas Bunth 
AuthorDate: Tue Sep 3 15:28:05 2019 +0200
Commit: Xisco Faulí 
CommitDate: Wed Sep 4 11:55:57 2019 +0200

Revert "tdf#127093, tdf#127092 Fix pasting autoincremented"

This reverts commit fa177231cd20bf3c3f4bb9b50f6646da139c6766.

Change-Id: Ia0c2d83c840c0ff8981b721766a6a1df810f971d
Reviewed-on: https://gerrit.libreoffice.org/78559
Tested-by: Jenkins
Reviewed-by: Tamás Bunth 
(cherry picked from commit d783017c1ccb4e62e99f26b42250ac4e15780cff)
Reviewed-on: https://gerrit.libreoffice.org/78581
Reviewed-by: Xisco Faulí 

diff --git a/dbaccess/source/ui/inc/DExport.hxx 
b/dbaccess/source/ui/inc/DExport.hxx
index 7dbcbf31fc6a..397b527d6d7d 100644
--- a/dbaccess/source/ui/inc/DExport.hxx
+++ b/dbaccess/source/ui/inc/DExport.hxx
@@ -61,9 +61,6 @@ namespace dbaui
 public:
 typedef std::map TColumns;
 typedef std::vector 
TColumnVector;
-
-// first value is the position in the destination table. The second
-// value is the position of the column in the source table.
 typedef std::vector< std::pair >   TPositions;
 
 protected:
diff --git a/dbaccess/source/ui/uno/copytablewizard.cxx 
b/dbaccess/source/ui/uno/copytablewizard.cxx
index d8dd195701cf..e7004aa8d29b 100644
--- a/dbaccess/source/ui/uno/copytablewizard.cxx
+++ b/dbaccess/source/ui/uno/copytablewizard.cxx
@@ -1183,12 +1183,6 @@ void CopyTableWizard::impl_copyRows_throw( const 
Reference< XResultSet >& _rxSou
 // otherwise we don't get the correct value when only the 
2nd source column was selected
 continue;
 }
-else if( xMeta->isAutoIncrement( rColumnPos.second ) )
-{
-// it is auto incremented. Let the DBMS deal with it.
-++nSourceColumn;
-continue;
-}
 
 if ( ( nSourceColumn < 1 ) || ( nSourceColumn >= 
static_cast(aSourceColTypes.size()) ) )
 {   // ( we have to check here against 1 because the 
parameters are 1 based)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

About Languagetool/Lightproof (grammar checker)

[julien2412]

Hello,

Taking a look at LanguageTool (grammar checker), I just wonder if we still
use it.
Indeed, LanguageTool is a Java component we have in version 1.7 whereas last
version is 4.6 (see
https://extensions.libreoffice.org/extensions/languagetool) and it seemed to
me we prefer the extension LightProof which uses Python.

Taking a look at git history, there's a config fix in 04/2019, a slight fix
in uitest in 08/2017, then you have about 20 commits between 2010 and 2014.

Taking a look at tdf bugtracker, I found above these 3 which contain
"languagetool" in their title:
- tdf#36540: XProofreader gets both deleted and inserted tracked changes,
causing spurious errors marked by LanguageTool

- tdf#92153: LanguageTool invokes appearing of pop-ups on (seemingly)
unrelated moments when JRE is disabled

- tdf#101687: LanguageTool - double spaces in automatic line break aren't
highlighted

Considering all this, I wonder if it could be removed so :
- we may decruftify a bit LO code
- remove a bit of Java dependency
- promote LightProof

If we finally want to keep languagetool, perhaps we should create a new
enhancement bug to upgrade it.

Any thoughts?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[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,

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

[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-commits] core.git: vcl/unx

[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

Re: About putting back Firebird experimental

[Alexander Thurgood]

Le 22/08/2019 à 12:12, Jean-Pierre Ledure a écrit :

Hi all,

> (3) the limits are different: e.g. VARCHAR max. length is < 2Gb in
> Hsqldb and  < 32K in Firebird, the max. length of a table row is < 2Gb
> in Firebird and <64K in Firebird, the max. length of a column name is
> 128B in Hsqldb and 31B in Firebird.
> 

And therein lies the problem, we have substituted the default db engine
for one that is less, or depending on how you look at it, otherwise
capable, in many respects...without providing the means for users of the
existing one to have their data survive the transition, or rather, we
let them believe that it will survive, and then fail at the task.

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.

And yes, I appreciate that at some stage, a decision on whether we have
reached a sufficiently advanced stage of conversion therapy will need to
be taken and acted upon. The question then is what level of
success/failure is deemed acceptable ?


Alex

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

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

[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-commits] core.git: Branch 'distro/collabora/cp-6.2' - vcl/qa

[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-commits] core.git: Branch 'libreoffice-6-3' - oox/source sw/qa

[Tamás Zolnai (via logerrit)]

 oox/source/ole/axbinarywriter.cxx|4 ++--
 sw/qa/extras/ooxmlexport/data/tdf118169.docx |binary
 sw/qa/extras/ooxmlexport/ooxmlexport13.cxx   |   11 +++
 3 files changed, 13 insertions(+), 2 deletions(-)

New commits:
commit 7d9f20a723a73300e05a9885c5f02516f771692d
Author: Tamás Zolnai 
AuthorDate: Wed Aug 28 16:24:59 2019 +0200
Commit: Xisco Faulí 
CommitDate: Wed Sep 4 15:30:07 2019 +0200

tdf#118169: ActiveX form control saved incorrectly with accented letters

Write out unicode strings without any compression.

Change-Id: I93cadc40bacbd679724c3404fd870cba48065650
Reviewed-on: https://gerrit.libreoffice.org/78234
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/78592

diff --git a/oox/source/ole/axbinarywriter.cxx 
b/oox/source/ole/axbinarywriter.cxx
index 89d2dc25351a..400e6fbde551 100644
--- a/oox/source/ole/axbinarywriter.cxx
+++ b/oox/source/ole/axbinarywriter.cxx
@@ -144,8 +144,8 @@ void AxBinaryPropertyWriter::writePairProperty( AxPairData& 
orPairData )
 
 void AxBinaryPropertyWriter::writeStringProperty( OUString& orValue )
 {
-sal_uInt32 nSize = orValue.getLength();
-setFlag(  nSize, AX_STRING_COMPRESSED );
+sal_uInt32 nSize = orValue.getLength() * 2;
+setFlag(  nSize, AX_STRING_COMPRESSED, false );
 maOutStrm.writeAligned< sal_uInt32 >( nSize );
 maLargeProps.push_back( ComplexPropVector::value_type( new StringProperty( 
orValue, nSize ) ) );
 startNextProperty();
diff --git a/sw/qa/extras/ooxmlexport/data/tdf118169.docx 
b/sw/qa/extras/ooxmlexport/data/tdf118169.docx
new file mode 100644
index ..2510fb3e59eb
Binary files /dev/null and b/sw/qa/extras/ooxmlexport/data/tdf118169.docx differ
diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx 
b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
index aab416a86f25..6a71a8e24747 100644
--- a/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
+++ b/sw/qa/extras/ooxmlexport/ooxmlexport13.cxx
@@ -414,6 +414,17 @@ DECLARE_OOXMLEXPORT_TEST(tdf127085, "tdf127085.docx")
 uno::Reference xShape(getShape(1), uno::UNO_QUERY);
 CPPUNIT_ASSERT_EQUAL(sal_Int16(50), getProperty(xShape, 
"FillTransparence"));
 }
+
+DECLARE_OOXMLEXPORT_TEST(tdf118169, "tdf118169.docx")
+{
+// Unicode characters were converted to question marks.
+uno::Reference xControlShape(getShape(1), 
uno::UNO_QUERY);
+uno::Reference 
xPropertySet(xControlShape->getControl(), uno::UNO_QUERY);
+uno::Reference xServiceInfo(xPropertySet, 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(true, 
bool(xServiceInfo->supportsService("com.sun.star.form.component.CheckBox")));
+CPPUNIT_ASSERT_EQUAL(OUString(u"őőő"), 
getProperty(xPropertySet, "Label"));
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
___
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' - 2 commits - bin/check-elf-dynamic-objects external/cairo

[Andras Timar (via logerrit)]

 bin/check-elf-dynamic-objects   |3 +++
 external/cairo/ExternalProject_cairo.mk |2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

New commits:
commit 7f02eb18b6051a7df42bf784eac542f2665e7281
Author: Andras Timar 
AuthorDate: Wed Sep 4 14:32:46 2019 +0200
Commit: Andras Timar 
CommitDate: Wed Sep 4 14:32:46 2019 +0200

tdf#121983 set RPATH of internally built libcairo.so

Change-Id: I8620fdcae2fcd34807b6b83b7c38aa5ca1ba2caa

diff --git a/external/cairo/ExternalProject_cairo.mk 
b/external/cairo/ExternalProject_cairo.mk
index 6ce6993408cd..1bf3bc33a543 100644
--- a/external/cairo/ExternalProject_cairo.mk
+++ b/external/cairo/ExternalProject_cairo.mk
@@ -63,7 +63,7 @@ $(call gb_ExternalProject_get_state_target,cairo,build) :
$(if $(filter INTEL ARM,$(CPUNAME)),ac_cv_c_bigendian=no 
ax_cv_c_float_words_bigendian=no)) \
$(if $(filter 
MACOSX,$(OS)),--prefix=/@.__OOO)
 \
&& cp cairo-version.h src/cairo-version.h \
-   && cd src && $(MAKE) \
+   && cd src && $(MAKE) && chrpath -r '$$ORIGIN' 
.libs/libcairo.so.2.1160$(CAIRO_VERSION_MICRO).0 \
)
 
 endif
commit df92637754c5e7fd59d0aec8bf646c8b42416fd5
Author: Andras Timar 
AuthorDate: Wed Sep 4 14:09:17 2019 +0200
Commit: Andras Timar 
CommitDate: Wed Sep 4 14:09:17 2019 +0200

tdf#121983 add whitelist for libcairo.so.2

Change-Id: If255e5af56d78047af9d38d6a7f0df07016e

diff --git a/bin/check-elf-dynamic-objects b/bin/check-elf-dynamic-objects
index 8848207855f5..d17a08717a8f 100755
--- a/bin/check-elf-dynamic-objects
+++ b/bin/check-elf-dynamic-objects
@@ -114,6 +114,9 @@ local file="$1"
 # skip the majority of files, no ELF binaries here
 skip=1
 ;;
+*/libcairo.so.2)
+whitelist="${whitelist} ${x11whitelist} libxcb-shm.so.0 
libxcb.so.1 libxcb-render.so.0"
+;;
 */libcairocanvaslo.so)
 whitelist="${whitelist} libcairo.so.2"
 ;;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Caolán McNamara (via logerrit)]

 cui/source/inc/numpages.hxx  |6 --
 cui/source/tabpages/numpages.cxx |   28 +++-
 2 files changed, 27 insertions(+), 7 deletions(-)

New commits:
commit de3933d0a5d37ea215dd16abd4aef0dd25b6c315
Author: Caolán McNamara 
AuthorDate: Tue Sep 3 10:14:45 2019 +0100
Commit: Caolán McNamara 
CommitDate: Wed Sep 4 14:04:13 2019 +0200

Resolves: tdf#127120 double selection in B dialog

because the list wants to ensure that at least one thing is selected and the
multiselect is implemented with two events of deselect-all followed by 
select.

post a user event on getting either deselect or select and process it
once when the dust has settled

Change-Id: I553bf23d7a8c4625a8706fb2df4b169d91b7ad32
Reviewed-on: https://gerrit.libreoffice.org/78542
Tested-by: Jenkins
Tested-by: Xisco Faulí 
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/cui/source/inc/numpages.hxx b/cui/source/inc/numpages.hxx
index 183f1d7825ac..6582a81fc873 100644
--- a/cui/source/inc/numpages.hxx
+++ b/cui/source/inc/numpages.hxx
@@ -331,8 +331,9 @@ class SvxNumPositionTabPage : public SfxTabPage
 std::unique_ptr pActNum;
 std::unique_ptr pSaveNum;
 
-sal_uInt16  nActNumLvl;
-sal_uInt16  nNumItemId;
+ImplSVEvent*m_pLevelHdlEvent;
+sal_uInt16  nActNumLvl;
+sal_uInt16  nNumItemId;
 MapUnit eCoreUnit;
 
 boolbModified   : 1;
@@ -371,6 +372,7 @@ class SvxNumPositionTabPage : public SfxTabPage
 voidInitControls();
 
 DECL_LINK(LevelHdl_Impl, weld::TreeView&, void);
+DECL_LINK(LevelHdl, void *, void);
 DECL_LINK(EditModifyHdl_Impl, weld::ComboBox&, void);
 DECL_LINK(DistanceHdl_Impl, weld::MetricSpinButton&, void);
 DECL_LINK(DistanceFocusHdl_Impl, Control&, void);
diff --git a/cui/source/tabpages/numpages.cxx b/cui/source/tabpages/numpages.cxx
index 89c43731389a..d7985b5ef5a6 100644
--- a/cui/source/tabpages/numpages.cxx
+++ b/cui/source/tabpages/numpages.cxx
@@ -2497,6 +2497,7 @@ void SvxNumberingPreview::Paint(vcl::RenderContext& 
rRenderContext, const ::tool
 //merged
 SvxNumPositionTabPage::SvxNumPositionTabPage(TabPageParent pParent, const 
SfxItemSet& rSet)
 : SfxTabPage(pParent, "cui/ui/numberingpositionpage.ui", 
"NumberingPositionPage", )
+, m_pLevelHdlEvent(nullptr)
 , nActNumLvl(1)
 , nNumItemId(SID_ATTR_NUMBERING_RULE)
 , bModified(false)
@@ -2568,6 +2569,11 @@ SvxNumPositionTabPage::~SvxNumPositionTabPage()
 
 void SvxNumPositionTabPage::dispose()
 {
+if (m_pLevelHdlEvent)
+{
+Application::RemoveUserEvent(m_pLevelHdlEvent);
+m_pLevelHdlEvent = nullptr;
+}
 m_xPreviewWIN.reset();
 SfxTabPage::dispose();
 }
@@ -3008,17 +3014,29 @@ IMPL_LINK_NOARG(SvxNumPositionTabPage, 
EditModifyHdl_Impl, weld::ComboBox&, void
 SetModified();
 }
 
-IMPL_LINK(SvxNumPositionTabPage, LevelHdl_Impl, weld::TreeView&, rBox, void)
+IMPL_LINK_NOARG(SvxNumPositionTabPage, LevelHdl_Impl, weld::TreeView&, void)
+{
+if (m_pLevelHdlEvent)
+return;
+// tdf#127120 multiselection may be implemented by deselect follow by 
select so
+// fire off the handler to happen on next event loop and only process the
+// final state
+m_pLevelHdlEvent = Application::PostUserEvent(LINK(this, 
SvxNumPositionTabPage, LevelHdl));
+}
+
+IMPL_LINK_NOARG(SvxNumPositionTabPage, LevelHdl, void*, void)
 {
+m_pLevelHdlEvent = nullptr;
+
 sal_uInt16 nSaveNumLvl = nActNumLvl;
 nActNumLvl = 0;
-std::vector aSelectedRows = rBox.get_selected_rows();
+std::vector aSelectedRows = m_xLevelLB->get_selected_rows();
 if (std::find(aSelectedRows.begin(), aSelectedRows.end(), 
pActNum->GetLevelCount()) != aSelectedRows.end() &&
 (aSelectedRows.size() == 1 || nSaveNumLvl != 0x))
 {
 nActNumLvl = 0x;
 for( sal_uInt16 i = 0; i < pActNum->GetLevelCount(); i++ )
-rBox.unselect(i);
+m_xLevelLB->unselect(i);
 }
 else if (!aSelectedRows.empty())
 {
@@ -3029,7 +3047,7 @@ IMPL_LINK(SvxNumPositionTabPage, LevelHdl_Impl, 
weld::TreeView&, rBox, void)
 nActNumLvl |= nMask;
 nMask <<= 1;
 }
-rBox.unselect(pActNum->GetLevelCount());
+m_xLevelLB->unselect(pActNum->GetLevelCount());
 }
 else
 {
@@ -3039,7 +3057,7 @@ IMPL_LINK(SvxNumPositionTabPage, LevelHdl_Impl, 
weld::TreeView&, rBox, void)
 {
 if(nActNumLvl & nMask)
 {
-rBox.select(i);
+m_xLevelLB->select(i);
 break;
 }
 nMask <<=1;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Graphic rendering: primitive functions

[Caolán McNamara]

On Wed, 2019-09-04 at 07:41 -0700, cekkr wrote:
> Hello,
> I'm studying the working of windows rendering, in particular on OS X.
> Which parts of codes are strictly related to "primitive" functions
> for rendering on the different OSs? 
> 
> For be a little more clear, "ad absurdum" where I have to code for
> implement LibreOffice on a my theoretical graphic server?

As a sample, for bottom level drawing, you typically inherit from
SalGraphics in vcl/inc/salgdi.hxx and provide implementations of the
pure virtual methods of that, e.g.

virtual voiddrawPixel( long nX, long nY ) = 0;

vcl/headless/svpgdi.cxx is one such implementation that draws to a
cairo canvas and is reused by the gtk3 implementation.

FWIW the OSX one is in vcl/quartz/salgdi.cxx and
vcl/quartz/salgdicommon.cxx

That's the bottom level drawing stuff. See vcl/inc/salinst.hxx for the
entry point for creating toplevel frames, printers, off-screen virtual
drawing devices, and so on

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

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

[Caolán McNamara (via logerrit)]

 vcl/inc/unx/glyphcache.hxx |7 +++
 vcl/unx/generic/gdi/cairotextrender.cxx|   20 
 vcl/unx/generic/glyphs/freetype_glyphcache.cxx |   20 
 3 files changed, 47 insertions(+)

New commits:
commit df4a6f977843dbf4eb8bb5998b090d92c454611b
Author: Caolán McNamara 
AuthorDate: Wed Sep 4 10:57:06 2019 +0100
Commit: Caolán McNamara 
CommitDate: Wed Sep 4 13:45:10 2019 +0200

tdf#127189 FreeType <= 2.8 will fail to render stretched horizontal brace...

glyphs in starmath at a fairly low stretch ratio. The failure will set
CAIRO_STATUS_FREETYPE_ERROR on the surface which cannot be cleared, so all
further painting to the surface fails.

This appears fixed in 2.9 with

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=91015cb41d8f56777f93394f5a60914bc0c0f330
"Improve complex rendering at high ppem"

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

diff --git a/vcl/inc/unx/glyphcache.hxx b/vcl/inc/unx/glyphcache.hxx
index 0331d7e9f86e..ccb25cab87e2 100644
--- a/vcl/inc/unx/glyphcache.hxx
+++ b/vcl/inc/unx/glyphcache.hxx
@@ -117,6 +117,13 @@ public:
 FreetypeFontInstance*   GetFontInstance() const { return 
mpFontInstance.get(); }
 
 voidSetFontVariationsOnHBFont(hb_font_t* pHbFace) 
const;
+
+// tdf#127189 FreeType <= 2.8 will fail to render stretched horizontal 
brace glyphs
+// in starmath at a fairly low stretch ratio. This appears fixed in 2.9 
with
+// 
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=91015cb41d8f56777f93394f5a60914bc0c0f330
+// "Improve complex rendering at high ppem"
+static bool AlmostHorizontalDrainsRenderingPool();
+
 private:
 friend class GlyphCache;
 friend class FreetypeFontInstance;
diff --git a/vcl/unx/generic/gdi/cairotextrender.cxx 
b/vcl/unx/generic/gdi/cairotextrender.cxx
index 8b55ab6da58d..0b24cbf32d63 100644
--- a/vcl/unx/generic/gdi/cairotextrender.cxx
+++ b/vcl/unx/generic/gdi/cairotextrender.cxx
@@ -204,6 +204,22 @@ void CairoTextRender::DrawTextLayout(const 
GenericSalLayout& rLayout, const SalG
 if (nWidth == 0 || nHeight == 0)
 return;
 
+int nRatio = nWidth * 10 / nHeight;
+if (nRatio > 100 && rFSD.maTargetName == "OpenSymbol" && 
FreetypeFont::AlmostHorizontalDrainsRenderingPool())
+{
+// tdf#127189 FreeType <= 2.8 will fail to render stretched horizontal
+// brace glyphs in starmath at a fairly low stretch ratio. The failure
+// will set CAIRO_STATUS_FREETYPE_ERROR on the surface which cannot be
+// cleared, so all further painting to the surface fails.
+
+// This appears fixed in >= freetype 2.9
+
+// Restrict this bodge to a stretch ratio > ~10 of the OpenSymbol font
+// where it has been seen in practice.
+SAL_WARN("vcl", "rendering text would fail with stretch ratio of: " << 
nRatio << ", with FreeType <= 2.8");
+return;
+}
+
 /*
  * It might be ideal to cache surface and cairo context between calls and
  * only destroy it when the drawable changes, but to do that we need to at
@@ -330,6 +346,10 @@ void CairoTextRender::DrawTextLayout(const 
GenericSalLayout& rLayout, const SalG
 
 cairo_set_font_matrix(cr, );
 cairo_show_glyphs(cr, _glyphs[nStartIndex], nLen);
+if (cairo_status(cr) != CAIRO_STATUS_SUCCESS)
+{
+SAL_WARN("vcl", "rendering text failed with stretch ratio of: " << 
nRatio << ", " << cairo_status_to_string(cairo_status(cr)));
+}
 
 #if OSL_DEBUG_LEVEL > 2
 //draw origin
diff --git a/vcl/unx/generic/glyphs/freetype_glyphcache.cxx 
b/vcl/unx/generic/glyphs/freetype_glyphcache.cxx
index 1b3532ceee1b..525da6e52b43 100644
--- a/vcl/unx/generic/glyphs/freetype_glyphcache.cxx
+++ b/vcl/unx/generic/glyphs/freetype_glyphcache.cxx
@@ -324,6 +324,26 @@ void GlyphCache::InitFreetype()
 (void)vclFontFileList::get();
 }
 
+namespace
+{
+bool DoesAlmostHorizontalDrainRenderingPool()
+{
+FT_Int nMajor, nMinor, nPatch;
+FT_Library_Version(aLibFT, , , );
+if (nMajor > 2)
+return false;
+if (nMajor == 2 && nMinor <= 8)
+return true;
+return false;
+}
+}
+
+bool FreetypeFont::AlmostHorizontalDrainsRenderingPool()
+{
+static bool bAlmostHorizontalDrainsRenderingPool = 
DoesAlmostHorizontalDrainRenderingPool();
+return bAlmostHorizontalDrainsRenderingPool;
+}
+
 FT_Face FreetypeFont::GetFtFace() const
 {
 FT_Activate_Size( maSizeFT );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: officecfg/registry sw/inc sw/sdi sw/source sw/uiconfig

[Gabor Kelemen (via logerrit)]

 officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu |   22 
++
 sw/inc/cmdid.h  |2 
 sw/sdi/_viewsh.sdi  |   12 +++
 sw/sdi/swriter.sdi  |   36 
++
 sw/source/uibase/uiview/view2.cxx   |   11 ++-
 sw/source/uibase/uiview/viewstat.cxx|2 
 sw/uiconfig/swriter/toolbar/changes.xml |2 
 7 files changed, 85 insertions(+), 2 deletions(-)

New commits:
commit 1496a1831d1be0a2d24be9fe3ecf627b2664e938
Author: Gabor Kelemen 
AuthorDate: Wed Jul 31 08:37:28 2019 +0200
Commit: László Németh 
CommitDate: Wed Sep 4 14:32:58 2019 +0200

tdf#101977 change tracking: add 'Accept/Reject and jump to next' commands

to Track Changes toolbar by creating the new Writer UNO command
.uno:RejectTrackedChangeToNext and .uno:AcceptTrackedChangeToNext.

Note: This feature is similar to what Word does by default.

Change-Id: Ic5d7f5663217c605ccbee2f16b49e76522f911e6
Reviewed-on: https://gerrit.libreoffice.org/76719
Reviewed-by: László Németh 
Tested-by: László Németh 

diff --git 
a/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu 
b/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu
index 3867e735dfd5..c17d52bcb2a2 100644
--- a/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu
+++ b/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu
@@ -238,6 +238,17 @@
   1
 
   
+  
+
+  Reject and Move to Next
+
+
+  Reject Track Change and select the next 
one
+
+
+  1
+
+  
   
 
   Reject All
@@ -266,6 +277,17 @@
   1
 
   
+  
+
+  Accept and Move to Next
+
+
+  Accept Track Change and select the next 
one
+
+
+  1
+
+  
   
 
   Accept All
diff --git a/sw/inc/cmdid.h b/sw/inc/cmdid.h
index 32a434f997c7..0916d97c90cd 100644
--- a/sw/inc/cmdid.h
+++ b/sw/inc/cmdid.h
@@ -141,6 +141,8 @@
 #define FN_REDLINE_PREV_CHANGE   (FN_EDIT2 + 42)/* Go to the previous 
change */
 #define FN_REDLINE_ACCEPT_ALL(FN_EDIT2 + 43)/* Redlining Accept 
All*/
 #define FN_REDLINE_REJECT_ALL(FN_EDIT2 + 44)/* Redlining Reject 
All*/
+#define FN_REDLINE_ACCEPT_TONEXT (FN_EDIT2 + 45)/* Redlining Accept 
and jump to next*/
+#define FN_REDLINE_REJECT_TONEXT (FN_EDIT2 + 46)/* Redlining Reject 
and jump to next*/
 
 // Region: Edit
 #define FN_REFRESH_VIEW (FN_VIEW + 1)   /* Refresh/Redraw */
diff --git a/sw/sdi/_viewsh.sdi b/sw/sdi/_viewsh.sdi
index 824eb2f0e6e3..ad97fe844319 100644
--- a/sw/sdi/_viewsh.sdi
+++ b/sw/sdi/_viewsh.sdi
@@ -152,6 +152,18 @@ interface BaseTextEditView
 StateMethod = GetState ;
 DisableFlags="SfxDisableFlags::SwOnMailboxEditor";
 ]
+FN_REDLINE_ACCEPT_TONEXT
+[
+ExecMethod = Execute;
+StateMethod = GetState;
+DisableFlags="SfxDisableFlags::SwOnMailboxEditor";
+]
+FN_REDLINE_REJECT_TONEXT
+[
+ExecMethod = Execute;
+StateMethod = GetState;
+DisableFlags="SfxDisableFlags::SwOnMailboxEditor";
+]
 
 SID_DOCUMENT_COMPARE // status(play)
 [
diff --git a/sw/sdi/swriter.sdi b/sw/sdi/swriter.sdi
index bb5d67ce161b..3f96725b5bf8 100644
--- a/sw/sdi/swriter.sdi
+++ b/sw/sdi/swriter.sdi
@@ -7345,6 +7345,42 @@ SfxVoidItem PreviousTrackedChange FN_REDLINE_PREV_CHANGE
 GroupId = SfxGroupId::Edit;
 ]
 
+SfxVoidItem AcceptTrackedChangeToNext FN_REDLINE_ACCEPT_TONEXT
+[
+AutoUpdate = FALSE,
+FastCall = FALSE,
+ReadOnlyDoc = FALSE,
+Toggle = FALSE,
+Container = FALSE,
+RecordAbsolute = FALSE,
+RecordPerSet;
+Asynchron;
+
+
+AccelConfig = TRUE,
+MenuConfig = TRUE,
+ToolBoxConfig = TRUE,
+GroupId = SfxGroupId::Edit;
+]
+
+SfxVoidItem RejectTrackedChangeToNext FN_REDLINE_REJECT_TONEXT
+[
+AutoUpdate = FALSE,
+FastCall = FALSE,
+ReadOnlyDoc = FALSE,
+Toggle = FALSE,
+Container = FALSE,
+RecordAbsolute = FALSE,
+RecordPerSet;
+Asynchron;
+
+
+AccelConfig = TRUE,
+MenuConfig = TRUE,
+ToolBoxConfig = TRUE,
+GroupId = SfxGroupId::Edit;
+]
+
 SfxVoidItem NavigateBack FN_NAVIGATION_BACK
 [
 AutoUpdate = TRUE,
diff --git a/sw/source/uibase/uiview/view2.cxx 
b/sw/source/uibase/uiview/view2.cxx
index fb43ba7a3cf8..bfc36246debc 100644
--- a/sw/source/uibase/uiview/view2.cxx
+++ b/sw/source/uibase/uiview/view2.cxx
@@ -668,6 +668,8 @@ void SwView::Execute(SfxRequest )
 break;
 case FN_REDLINE_ACCEPT_DIRECT:
 case FN_REDLINE_REJECT_DIRECT:
+case 

Re: About putting back Firebird experimental

[julien2412]

Xisco Fauli wrote
> if we want to put it back to experimental, personally I would prefer to
> do it *only* in 6.3 and leave it as it's in master so we can test it and
> improve it.
> ...

It can be tested on master sources just by enabling experimental.
We already put in release notes for 6.3 that migration/Firebird part wasn't
experimental anymore.

If I remember well, we wanted to give a try to this part by putting it by
default.
Considering the number of bugs, we can see the test failed, we're not ready.
So the goal is to avoid letting it this part by default for next release
6.4.0 (except if we can fix enough bugs related to it of course).

Now, if somebody wants to revert the patch which reenabled experimental only
for this part, feel free to do it but I won't do it myself since I'm
strongly against it.

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Graphic rendering: primitive functions

[cekkr]

Thank you so much,
it is EXACTLY the answer that I was looking for

R



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About putting back Firebird experimental

[Xisco Fauli]

Hi Julien,

if we want to put it back to experimental, personally I would prefer to
do it *only* in 6.3 and leave it as it's in master so we can test it and
improve it.

In the past, We did the same in 6.2 <
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2=7991a4d718c282f1fd999e76f683e333b5c220af
> and 6.1 <
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-1=0b3ee8ffbb6b33827c17af56c62dc5285f3ba258
>

Regards

El 29/8/19 a les 20:57, julien2412 ha escrit:
> For information, I pushed the patch https://gerrit.libreoffice.org/#/c/78240/
>
> If someone sees some regressions or wants to comment, don't hesitate to tell
> of course so we can push an additional patch or revert this one if it brings
> too much regression/confusion.
>
>
>
> --
> Sent from: 
> http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0

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

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

[Khaled Hosny (via logerrit)]

 vcl/source/font/fontmetric.cxx |4 -
 vcl/source/fontsubset/sft.cxx  |5 +-
 vcl/unx/generic/fontmanager/fontconfig.cxx |   51 -
 vcl/unx/generic/glyphs/freetype_glyphcache.cxx |6 +-
 4 files changed, 34 insertions(+), 32 deletions(-)

New commits:
commit 1fc306203b047e79d5b3f30cf615609f80b62fe4
Author: Khaled Hosny 
AuthorDate: Tue Aug 27 15:19:15 2019 +0200
Commit: Caolán McNamara 
CommitDate: Wed Sep 4 16:03:55 2019 +0200

Make Noto Color Emoji font work on Linux

Noto Color Emoji is a bitmap color font, Cairo knows how to scale such
fonts and FontConfig will identify them as scalable but not outline
fonts, so change the FontConfig checks to checks for scalability.

Make sft.cxx:doOpenTTFont() accept non-outline fonts, the text will not
show in PDF but that is not worse than the status quo.

Change-Id: I756c718296d2c43e3165cd2f07b11bbb981318d3
Reviewed-on: https://gerrit.libreoffice.org/78218
Tested-by: Jenkins
Reviewed-by: Khaled Hosny 
(cherry picked from commit dcf7792da2aa2a1ef774a124f7b21f68fff0fd15)
Reviewed-on: https://gerrit.libreoffice.org/78589

diff --git a/vcl/source/font/fontmetric.cxx b/vcl/source/font/fontmetric.cxx
index 4e6c648be3c7..a9325fde9a21 100644
--- a/vcl/source/font/fontmetric.cxx
+++ b/vcl/source/font/fontmetric.cxx
@@ -485,8 +485,8 @@ void ImplFontMetricData::ImplCalcLineSpacing(const 
std::vector& rHheaDa
 if (mnAscent || mnDescent)
 mnIntLeading = mnAscent + mnDescent - mnHeight;
 
-SAL_INFO("vcl.gdi.fontmetric",
-  "fsSelection: "   << rInfo.fsSelection
+SAL_INFO("vcl.gdi.fontmetric", GetFamilyName()
+ << ": fsSelection: "   << rInfo.fsSelection
  << ", typoAscender: "  << rInfo.typoAscender
  << ", typoDescender: " << rInfo.typoDescender
  << ", typoLineGap: "   << rInfo.typoLineGap
diff --git a/vcl/source/fontsubset/sft.cxx b/vcl/source/fontsubset/sft.cxx
index 2ad41691f1ef..979783a5021a 100644
--- a/vcl/source/fontsubset/sft.cxx
+++ b/vcl/source/fontsubset/sft.cxx
@@ -1668,7 +1668,10 @@ static SFErrCodes doOpenTTFont( sal_uInt32 facenum, 
TrueTypeFont* t )
 /* TODO: implement to get subsetting */
 assert(t->goffsets != nullptr);
 } else {
-return SFErrCodes::TtFormat;
+// Bitmap font, accept for now.
+t->goffsets = static_cast(calloc(1+t->nglyphs, 
sizeof(sal_uInt32)));
+/* TODO: implement to get subsetting */
+assert(t->goffsets != nullptr);
 }
 
 table = getTable(t, O_hhea);
diff --git a/vcl/unx/generic/fontmanager/fontconfig.cxx 
b/vcl/unx/generic/fontmanager/fontconfig.cxx
index e13eb0a82716..8e3e9163d1ce 100644
--- a/vcl/unx/generic/fontmanager/fontconfig.cxx
+++ b/vcl/unx/generic/fontmanager/fontconfig.cxx
@@ -65,7 +65,7 @@ namespace
 
 class FontCfgWrapper
 {
-FcFontSet* m_pOutlineSet;
+FcFontSet* m_pFontSet;
 
 void addFontSet( FcSetName );
 
@@ -93,17 +93,14 @@ private:
 };
 
 FontCfgWrapper::FontCfgWrapper()
-: m_pOutlineSet( nullptr )
+: m_pFontSet( nullptr )
 {
 FcInit();
 }
 
 void FontCfgWrapper::addFontSet( FcSetName eSetName )
 {
-/*
-  add only acceptable outlined fonts to our config,
-  for future fontconfig use
-*/
+// Add only acceptable fonts to our config, for future fontconfig use.
 FcFontSet* pOrig = FcConfigGetFonts( FcConfigGetCurrent(), eSetName );
 if( !pOrig )
 return;
@@ -112,10 +109,12 @@ void FontCfgWrapper::addFontSet( FcSetName eSetName )
 for( int i = 0; i < pOrig->nfont; ++i )
 {
 FcPattern* pPattern = pOrig->fonts[i];
-// #i115131# ignore non-outline fonts
-FcBool bOutline = FcFalse;
-FcResult eOutRes = FcPatternGetBool( pPattern, FC_OUTLINE, 0, 
 );
-if( (eOutRes != FcResultMatch) || (bOutline == FcFalse) )
+// #i115131# ignore non-scalable fonts
+// Scalable fonts are usually outline fonts, but some bitmaps fonts
+// (like Noto Color Emoji) are also scalable.
+FcBool bScalable = FcFalse;
+FcResult eScalableRes = FcPatternGetBool(pPattern, FC_SCALABLE, 0, 
);
+if ((eScalableRes != FcResultMatch) || (bScalable == FcFalse))
 continue;
 
 // Ignore Type 1 fonts, too.
@@ -125,7 +124,7 @@ void FontCfgWrapper::addFontSet( FcSetName eSetName )
 continue;
 
 FcPatternReference( pPattern );
-FcFontSetAdd( m_pOutlineSet, pPattern );
+FcFontSetAdd( m_pFontSet, pPattern );
 }
 
 // TODO?: FcFontSetDestroy( pOrig );
@@ -216,16 +215,16 @@ namespace
 
 FcFontSet* FontCfgWrapper::getFontSet()
 {
-if( !m_pOutlineSet )
+if( !m_pFontSet )
 {
-m_pOutlineSet = FcFontSetCreate();
+m_pFontSet = FcFontSetCreate();
 addFontSet( FcSetSystem );
 addFontSet( FcSetApplication );
 
-

Graphic rendering: primitive functions

[cekkr]

Hello,
I'm studying the working of windows rendering, in particular on OS X.
Which parts of codes are strictly related to "primitive" functions for
rendering on the different OSs? 

For be a little more clear, "ad absurdum" where I have to code for implement
LibreOffice on a my theoretical graphic server?

Thank you,
Riccardo



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[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

security warning now additionally on *calling* scripts/macros

[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

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

[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

Re: About putting back Firebird experimental

[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-commits] core.git: Changes to 'refs/tags/cib-6.1-4'

[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

[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-commits] core.git: vcl/source

[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-commits] core.git: Branch 'libreoffice-6-3' - vcl/source

[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: sc/source

[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-commits] core.git: sw/uiconfig

[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-commits] core.git: Branch 'distro/collabora/cp-6.2' - distro-configs/CPLinux-LOKit.conf

[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

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

[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-bugs] [Bug 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

Timur Davletshin  changed:

   What|Removed |Added

Version|6.3.1.1 rc  |6.3.0.4 release

-- 
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 127327] New: GTK2 backend → Corrupted thumbnail generation

[bugzilla-daemon]

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

Bug ID: 127327
   Summary: GTK2 backend → Corrupted thumbnail generation
   Product: LibreOffice
   Version: 6.3.1.1 rc
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: LibreOffice
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: timur.davlets...@gmail.com

Description:
Thumbnail generation is broken in GTK2 backend (6.3.1 RC)

Steps to Reproduce:
1. Switch to GTK2 backend
2. Create any document
3. Save it
4a. Preview thumbnail in recent documents is black
4b. Rename saved file to zip and open it. Thumbnail PNG inside is black too.

Actual Results:
Black thumbnail

Expected Results:
Preview reflects document content


Reproducible: Always


User Profile Reset: Yes



Additional Info:
GTK3 and QT/KDE works fine.

-- 
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 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

Timur Davletshin  changed:

   What|Removed |Added

Summary|GTK2 backend → Corrupted|GTK2 backend → Corrupted
   |thumbnail generation|thumbnail generation (6.3.1
   ||RC)

-- 
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 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

--- Comment #1 from Timur Davletshin  ---
Probably it is linked to
https://bugs.documentfoundation.org/show_bug.cgi?id=126254

-- 
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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

--- Comment #8 from Alex Thurgood  ---
(In reply to laurens from comment #6)

No crash for me either with the test document and

Version: 6.4.0.0.alpha0+
Build ID: e04b6f3c0cdacf2a3cdcd3f34bad54c8764ff1ed
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
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

[Libreoffice-bugs] [Bug 62926] Add option to show 'Apply Style' menu in plain text

[bugzilla-daemon]

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

--- Comment #15 from Thomas Lendo  ---
If you combine answer 1 and 4 (new option in general and Writer options) then
you have an absolute majority of over 50% for a new option. So, everybody can
read out from a statistic/survey what he wants.

My proposal in comment 12 would not change the sum of options, so this wouldn't
clutter the UI (new options setting instead of style sidebar checkbox).

-- 
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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

laur...@norbit.no changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #9 from laur...@norbit.no ---
I've reset the user profile and can no longer reproduce myself, so I guess it
was a corruption somewhere.

-- 
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] New: UI: Make German strings in list of embedded databases consistent

[bugzilla-daemon]

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

Bug ID: 127328
   Summary: UI: Make German strings in list of embedded databases
consistent
   Product: LibreOffice
   Version: 6.3.0.4 release
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: medium
 Component: Localization
  Assignee: libreoffice-bugs@lists.freedesktop.org
  Reporter: thomas.le...@gmail.com

The German strings in the list of embedded databases in the first page of the
Datase Wizard differ:

English version:
* HSQLDB Embedded
* Firebird Embedded

German version:
* Firebord (eingebettet)
* Eingebettete HSQLDB

Differences:
- Different wording ('embedded' as prefix and suffix)
- Different sorting than in English version


Another question:
As the string before the drop down list already is named 'Embedded database',
why is 'embedded' duplicated in the list entries?


Version: 6.3.0.4 (x64)
Build-ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU-Threads: 12; BS: Windows 10.0; UI-Render: Standard; VCL: win; 

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_22:04:10

-- 
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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

--- Comment #10 from laur...@norbit.no ---
(In reply to laurens from comment #9)
> I've reset the user profile and can no longer reproduce myself, so I guess
> it was a corruption somewhere.

NB I Also changed LO version to RC at the same time, as I needed the fixed for
the scrolling bug.

Version: 6.3.1.2
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.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-bugs] [Bug 127006] Inserting a Section - Using 'Enter' Key Blows up the Insert Section Function

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

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

--- Comment #4 from Dieter Praas  ---
I can't confirm this with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: en-GB (de_DE); UI-Language: en-US
Calc: threaded


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=107738
[Bug 107738] [META] Section 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

[Libreoffice-bugs] [Bug 107738] [META] Section bugs and enhancements

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

 Depends on||127006


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127006
[Bug 127006] Inserting a Section - Using 'Enter' Key Blows up the Insert
Section Function
-- 
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 107738] [META] Section bugs and enhancements

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

 Depends on||126892


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=126892
[Bug 126892] visibility of cut/pasted section cannot be programmatically
changed
-- 
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 126892] visibility of cut/pasted section cannot be programmatically changed

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

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


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=107738
[Bug 107738] [META] Section 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

[Libreoffice-bugs] [Bug 127274] Insert Field crashes LO

[bugzilla-daemon]

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

Alex Thurgood  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #11 from Alex Thurgood  ---
No repro either with

Version: 6.3.0.4
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

however, the problem you are experiencing is probably due to having a
registered database in your user profile. There was bug 119419, now fixed, that
read all of the registered databases from the user profile and then attempted
to connect to each one in turn when the user tried inserting a field into a
document via the Insert Fields menu. If you had deactivated the use of the JRE,
then almost certainly any attempt to attempt to load a connection to a
previously registered database from the user profile would have caused a crash.

-- 
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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

--- Comment #12 from Alex Thurgood  ---
And bug 119419 was linked to bug 112634, which is where the fix went in.

-- 
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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

Alex Thurgood  changed:

   What|Removed |Added

 Resolution|FIXED   |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 127274] Insert Field crashes LO

[bugzilla-daemon]

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

laur...@norbit.no changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #13 from laur...@norbit.no ---
(In reply to Alex Thurgood from comment #11)
> No repro either with
> 
> Version: 6.3.0.4
> Build ID: 057fc023c990d676a43019934386b85b21a9ee99
> Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
> Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: threaded
> 
> however, the problem you are experiencing is probably due to having a
> registered database in your user profile. There was bug 119419, now fixed,
> that read all of the registered databases from the user profile and then
> attempted to connect to each one in turn when the user tried inserting a
> field into a document via the Insert Fields menu. If you had deactivated the
> use of the JRE, then almost certainly any attempt to attempt to load a
> connection to a previously registered database from the user profile would
> have caused a crash.

I wonder if that was also the reason that I could not *disable* the JRE on that
Profile / LO version (it kept coming back on). I have to admit that I find the
JRE setting very confusing as a non LO expert, but that is a different issue.
All I know is that I try to avoid Java :)

-- 
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 108897] [META] XLSX (OOXML) bug tracker

[bugzilla-daemon]

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

Bug 127110 Summary: Vesion 6.3.0.4 not saving .xlsx files correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=127110

   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 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

Julien Nabet  changed:

   What|Removed |Added

 CC||caol...@redhat.com,
   ||serval2...@yahoo.fr

--- Comment #2 from Julien Nabet  ---
Caolán: should we consider it as a WONTFIX since gtk2 will be soon dropped?

-- 
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 127259] EDITING: Pasting into Writer produces extraneous hashtags, and is overwritten by the last thing copied within Writer itself

[bugzilla-daemon]

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

--- Comment #1 from Alex Thurgood  ---
This is a very complicated set of steps requiring at least 2 other software
applications in order to try and confirm, and involving installing those
applications under conditions in which the testers may not feel entirely happy
doing so (particularly if they are not open source programs), so it seems
unlikely that this report will ever be confirmed.

That isn't to say that it won't be, but the reality of the situation is that
there are relatively few testers on macOS, and most of them are probably loathe
to install proprietary software they don't need.

That aside, and FWIW, there is currently ongoing development to try and improve
the copy/paste mechanisms within LO, so hopefully one of those code changes
might bring a positive change to your problem in the near-ish future.
Additionally, the copy/paste mechanism is inevitably dependent on how the OS
handles such data.

-- 
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

[bugzilla-daemon]

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

Julien Nabet  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||heiko.tietze@documentfounda
   ||tion.org,
   ||serval2...@yahoo.fr,
   ||xiscofa...@libreoffice.org
   Keywords||topicUI

--- Comment #1 from Julien Nabet  ---
Heiko/Xisco: before talking about translation, there's first an UI question.

-- 
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 127272] odt document + UI "registers" etc.: Writer crashes when UI will be set to "registers" etc. resp. after this when odt file should be opened

[bugzilla-daemon]

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

--- Comment #11 from Xisco Faulí  ---
(In reply to Mike Kaganski from comment #10)
> Looks like fixed in my testing.

Hi Mike and Sumit Chauhan, Thanks for the quick fix.
I see you have changed the file quite a lot <
https://cgit.freedesktop.org/libreoffice/core/log/vcl/source/window/builder.cxx
> so i'm hesitant to cherry-pick it to libreoffice-6-3
Could you please cherry-pick it to 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 127279] Register-true with better labelling

[bugzilla-daemon]

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

--- Comment #8 from pedro.silva  ---
(In reply to V Stuart Foote from comment #7)
> Obviously we do not implement a vertical grid typesetting framework on which
> objects can be aligned.

Understood.

> Rather, we describe a "Reference" paragraph style--font and leading--that
> establishes a text line height. And effectively sets text "baselines" as
> vertically filled from top down and applied within margins of a page style. 
> 
> Multiple paragraphs on multiple pages will be aligned to that baseline when
> those paragraphs (selectively) are 'Register true' enabled. 
> 
> And beleive different page styles (each with a "Reference style" and
> corresponding line height/baselines) can be defined (pre-defined in
> template) for use in complex documents.
> 
> This is a different approach to that of InDesign or even Scribus.

Agreed, it is most def. a different approach and I see no problem with that.

In this bug what I tried to propose was a better labelling. As you see when
describing the functionality you use the word Baseline (let us forget for a
minute about the "Grid"). Also I never encounter any educational material on
graphic design, typography or simply about print with that term but all of
these do have baselines as a though term. Moreover and as you see in
https://help.libreoffice.org/Writer/Printing_Register-true the current term is
not really about an element or characteristic of the text/page but rather an
ideal to be achieved "This term refers to the congruent imprint of the lines
within a type area[...]" so it's kinda odd that is being used as a label for an
on/off toggle. 

Nevertheless I hear you and so here are some options that could be a better fit
than the current “Register-true”/“Reference Style:” in Page Style > Page (tab):

- Align to fixed Baseline / Reference Style:
- Fixed Baseline / Reference Style:
- Referenced line spacing / Paragraph style:

I think the 3rd would be a good because not only it's more clear it uses the
same terminology from the Paragraph dialogue (Paragraph Styles > Indents &
Spacing). To pair with this, in the Paragraph dialogue the group titled
"Register-true" with the checkbox "Activate" would become:

- Referenced line spacing / Activate

-- 
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 71732] [META] Bugs related to text rendering, typography and font features in LO

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

 Depends on||127208


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=127208
[Bug 127208] tilde displays like macron
-- 
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 127208] tilde displays like macron

[bugzilla-daemon]

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

Dieter Praas  changed:

   What|Removed |Added

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

--- Comment #3 from Dieter Praas  ---
(In reply to Miguel Frasson from comment #1)
> Created attachment 153724 [details]
> ODT file inplementing font tests.

I can't sonfirm this with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: en-GB (de_DE); UI-Language: en-US
Calc: threaded

It seems you're using an old version of LibreOffice. Could you please try to
reproduce it with the latest version of LibreOffice from
https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's
status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is
still present in the latest version. Change to RESOLVED WORKSFORME, if the
problem went away.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=71732
[Bug 71732] [META] Bugs related to text rendering, typography and font features
in LO
-- 
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 127195] Strange placement of "Don't show this again" box in No help installed dialog

[bugzilla-daemon]

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

--- Comment #2 from Heiko Tietze  ---
Created attachment 153856
  --> https://bugs.documentfoundation.org/attachment.cgi?id=153856=edit
Screenshot with Gtk3

Content is centered, which looks weird indeed.

-- 
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

[bugzilla-daemon]

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

Julien Nabet  changed:

   What|Removed |Added

 CC||lio...@mamane.lu

--- Comment #3 from Julien Nabet  ---
Thomas: about rationalizing and removing "Embedded" part since there's already
"Embedded database", I think the labels must be used elsewhere. That's why I
think we may just keep "embedded". About prefix or suffix, I've got no strong
opinion.


Heiko: thank you for your quick feedback!


Lionel: since it concerns Base, even if it's just UI part, thought you might be
interested in this one. (I was first only focused on UX team).

-- 
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 127272] odt document + UI "registers" etc.: Writer crashes when UI will be set to "registers" etc. resp. after this when odt file should be opened

[bugzilla-daemon]

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

--- Comment #14 from stefan_lange...@t-online.de  
---
Test was OK (no crash at open or change UI) with 
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 2c7aa60b69967a80b7874503f0e9e85546a04cde
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-09-04_06:15:45
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL

Many thanks!

I hope soon comes also a new build on Win-x86_64@62-TDF or at least on
Win-x86@62-TDF...

-- 
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 38194] Style indicator in document margin

[bugzilla-daemon]

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

Regina Henschel  changed:

   What|Removed |Added

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

--- Comment #24 from Regina Henschel  ---
Putting such information into the comment margin will conflict with ordinary
comments. This area is too small anyway. I see also problems with adding
rectangles to the page margins. You would need to touch a lot of code, to
distinct them from other graphic content. So I do not like that idea at all.

But I support Andreas' idea of a separate inspector window similar to those
known from DOM inspectors. It has the advantage, that it needs no code
integration, but can be provided purely as extension. Such window would allow a
more detailed view on the inheritance of properties. For example, a portion of
text can have a direct format "yellow", a character style with "italic", which
is derived from a character style with language set to "German", and uses the
font height of the paragraph style, which inherits the font itself from the
default style. And such window can be freely positioned and sized.

-- 
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 38194] Style indicator in document margin

[bugzilla-daemon]

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

Regina Henschel  changed:

   What|Removed |Added

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

--- Comment #24 from Regina Henschel  ---
Putting such information into the comment margin will conflict with ordinary
comments. This area is too small anyway. I see also problems with adding
rectangles to the page margins. You would need to touch a lot of code, to
distinct them from other graphic content. So I do not like that idea at all.

But I support Andreas' idea of a separate inspector window similar to those
known from DOM inspectors. It has the advantage, that it needs no code
integration, but can be provided purely as extension. Such window would allow a
more detailed view on the inheritance of properties. For example, a portion of
text can have a direct format "yellow", a character style with "italic", which
is derived from a character style with language set to "German", and uses the
font height of the paragraph style, which inherits the font itself from the
default style. And such window can be freely positioned and sized.

-- 
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 120663] No impress remote: Impress incompatible with current bluetooth stack on linux (RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use)

[bugzilla-daemon]

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

sergio.calleg...@gmail.com changed:

   What|Removed |Added

 CC||sergio.calleg...@gmail.com

--- Comment #7 from sergio.calleg...@gmail.com ---
Wonder if it could be useful to kindly ask Andrzej Hunt if he can look into the
issue. If I am not wrong he is the author of the current bluez 5 code in
Impress.

-- 
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 107943] [META] Save bugs and enhancements

[bugzilla-daemon]

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

Bug 120867 Summary: First file save after opening slower compared to previous 
versions
https://bugs.documentfoundation.org/show_bug.cgi?id=120867

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INSUFFICIENTDATA|---

-- 
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 120867] First file save after opening slower compared to previous versions

[bugzilla-daemon]

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

Alex Thurgood  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INSUFFICIENTDATA|---

--- Comment #4 from Alex Thurgood  ---
Unfortunately, still the case with latest master (own build).

The same applies to the first selection of a file to load via the Finder using
Cmd-O.

-- 
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 88268] EDITING: Report builder cause LO to quit unexpectedly when drag resizing header and detail or footer controls together in OSX

[bugzilla-daemon]

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

--- Comment #23 from Alex Thurgood  ---
Still reproducible in 

Version: 6.4.0.0.alpha0+
Build ID: e04b6f3c0cdacf2a3cdcd3f34bad54c8764ff1ed
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
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

[Libreoffice-bugs] [Bug 93094] Editing - sqlite3 tables read only even when defined with primary key using Xerial jdbc driver

[bugzilla-daemon]

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

--- Comment #29 from Alex Thurgood  ---
Problem still reproducible with 

Version: 6.4.0.0.alpha0+
Build ID: e04b6f3c0cdacf2a3cdcd3f34bad54c8764ff1ed
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threade

-- 
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 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

--- Comment #6 from Timur Davletshin  ---
(In reply to Xisco Faulí from comment #5)
> Could you please share a screenshot ?
> We already have these 2 reports -> bug 126791 and bug 125461

I believe it is the same. I believe I used wrong keywords before posting a new
bug. Recent document shows internal thumbnail.png, which is generated by LO.

-- 
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 127326] UI: First Page icon in Calc's page preview toolbar looks different than last page icon

[bugzilla-daemon]

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

m.a.riosv  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||miguelangelrv@libreoffice.o
   ||rg
 Status|UNCONFIRMED |NEW

--- Comment #1 from m.a.riosv  ---
Repro
Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: es-ES (es_ES); UI-Language: en-USCalc: CL

-- 
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

[bugzilla-daemon]

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

--- Comment #8 from pedro.silva  ---
(In reply to V Stuart Foote from comment #7)
> Obviously we do not implement a vertical grid typesetting framework on which
> objects can be aligned.

Understood.

> Rather, we describe a "Reference" paragraph style--font and leading--that
> establishes a text line height. And effectively sets text "baselines" as
> vertically filled from top down and applied within margins of a page style. 
> 
> Multiple paragraphs on multiple pages will be aligned to that baseline when
> those paragraphs (selectively) are 'Register true' enabled. 
> 
> And beleive different page styles (each with a "Reference style" and
> corresponding line height/baselines) can be defined (pre-defined in
> template) for use in complex documents.
> 
> This is a different approach to that of InDesign or even Scribus.

Agreed, it is most def. a different approach and I see no problem with that.

In this bug what I tried to propose was a better labelling. As you see when
describing the functionality you use the word Baseline (let us forget for a
minute about the "Grid"). Also I never encounter any educational material on
graphic design, typography or simply about print with that term but all of
these do have baselines as a though term. Moreover and as you see in
https://help.libreoffice.org/Writer/Printing_Register-true the current term is
not really about an element or characteristic of the text/page but rather an
ideal to be achieved "This term refers to the congruent imprint of the lines
within a type area[...]" so it's kinda odd that is being used as a label for an
on/off toggle. 

Nevertheless I hear you and so here are some options that could be a better fit
than the current “Register-true”/“Reference Style:” in Page Style > Page (tab):

- Align to fixed Baseline / Reference Style:
- Fixed Baseline / Reference Style:
- Referenced line spacing / Paragraph style:

I think the 3rd would be a good because not only it's more clear it uses the
same terminology from the Paragraph dialogue (Paragraph Styles > Indents &
Spacing). To pair with this, in the Paragraph dialogue the group titled
"Register-true" with the checkbox "Activate" would become:

- Referenced line spacing / Activate

-- 
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

[bugzilla-daemon]

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

vistama...@web.de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #8 from vistama...@web.de ---
I do no agree!
This is NO duplicate to 69551. The other bug is about "automatic style
display". This is the opposite of it: "user defined style display".
These bugs are very different.

-- 
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 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #3 from Heiko Tietze  ---
Is there anything specific you would add to the View submenu? Otherwise I'd
close the ticket as WFM.

-- 
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 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #3 from Heiko Tietze  ---
Is there anything specific you would add to the View submenu? Otherwise I'd
close the ticket as WFM.

-- 
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 102998] [META] Mail merge bugs and enhancements

[bugzilla-daemon]

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

Bug 125330 Summary: Disable Filter and Change Table in mail wizard
https://bugs.documentfoundation.org/show_bug.cgi?id=125330

   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 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #4 from pedro.silva  ---
(In reply to Heiko Tietze from comment #3)
> Is there anything specific you would add to the View submenu? Otherwise I'd
> close the ticket as WFM.

Go ahead, thanks!

-- 
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 118314] Remove "Input Method Status" menu option and implementation

[bugzilla-daemon]

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

László Németh  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |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-ux-advise] [Bug 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #4 from pedro.silva  ---
(In reply to Heiko Tietze from comment #3)
> Is there anything specific you would add to the View submenu? Otherwise I'd
> close the ticket as WFM.

Go ahead, thanks!

-- 
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 85811] [META] Main menu bar bugs and enhancements

[bugzilla-daemon]

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

Bug 118314 Summary: Remove "Input Method Status" menu option and implementation
https://bugs.documentfoundation.org/show_bug.cgi?id=118314

   What|Removed |Added

 Status|NEW |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 127329] CRASH: pasting and undoing a few times

[bugzilla-daemon]

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

Xisco Faulí  changed:

   What|Removed |Added

 CC||michael.st...@cib.de

--- Comment #1 from Xisco Faulí  ---
Hi Michael,
It seems another file affected by the fly at-char selection you recently fixed
in
https://gerrit.libreoffice.org/plugins/gitiles/core/+/3345feb67f2c49a1b76639965b56968e1c5f03ee%5E%21
I thought you might be interested in this issue...

-- 
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

[bugzilla-daemon]

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

Xisco Faulí  changed:

   What|Removed |Added

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

-- 
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 127294] Making tips of the day specific to the kind of document created

[bugzilla-daemon]

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

--- Comment #4 from Heiko Tietze  ---
The illustration next to the tip has a MIME type icon depending on the module
right now, if it's a specific tip.

-- 
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 127294] Making tips of the day specific to the kind of document created

[bugzilla-daemon]

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

--- Comment #4 from Heiko Tietze  ---
The illustration next to the tip has a MIME type icon depending on the module
right now, if it's a specific tip.

-- 
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 120663] No impress remote: Impress incompatible with current bluetooth stack on linux (RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use)

[bugzilla-daemon]

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

sergio.calleg...@gmail.com changed:

   What|Removed |Added

Summary|No impress remote: RFCOMM   |No impress remote: Impress
   |server failed for   |incompatible with current
   |LibreOffice Impress Remote: |bluetooth stack on linux
   |rfcomm_bind: Address|(RFCOMM server failed for
   |already in use  |LibreOffice Impress Remote:
   ||rfcomm_bind: Address
   ||already in use)

--- Comment #6 from sergio.calleg...@gmail.com ---
Issue persists with current LibO 6.3.1.2 and most likely due to the fact that
the bluetooth stack on linux (bluez) has changed in the past years and impress
has not cought up.

Problem is now more visible due to the startup tooltips in Impress 6.3.x which
explicitly introduce the impress remote functionality inviting the users to
test it. Goes like: start Impress -> see tooltip -> get interested -> download
and install phone app -> try -> fail -> get disappointed and remove phone app.

Because the phone based remote is one of those little things with a great wow
factor that makes LibO really shine out and amaze people when used in front of
an audience, it would really be great if the functionality could be restored.
It is literally a little big thing helping getting a foot in the door.

In fact, I suppose that if one could also add a "spotlight" and "zoom"
functionality in it (in addition to the pointer) and the ability to use the
phone accelerometers for moving the pointer (in place of the finger on the
screen) it would make LibO a serious contender for all those coveting the
"Logitech spotlight" that is currently the hot thing in presentations selling
for over $100. See also https://github.com/jahnf/Projecteur .

-- 
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 127327] GTK2 backend → Corrupted thumbnail generation (6.3.1 RC)

[bugzilla-daemon]

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

--- Comment #8 from Timur Davletshin  ---
(In reply to Xisco Faulí from comment #5)
> Could you please share a screenshot ?
> We already have these 2 reports -> bug 126791 and bug 125461

This happens only with gtk2 backend. It was introduced in 6.3 I believe.
Earlier mentioned bug with black "About" screen was introduced at the same
time.

-- 
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 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #2 from pedro.silva  ---
(In reply to Heiko Tietze from comment #1)
> Helplines while moving are under View > Grid and Helplines. What else
> exactly do you expect in the main menu? Please keep in mind that a clean
> menu is a big plus for usability. And you may also customize the menu for
> your needs (Tools > Customize).

Understood and agreed, (I though I already answer but I see that no) I was
testing with different versions and I think I miss that or that I had some sort
of customization. Anyhow thanks for taking the time.

-- 
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 127289] Add available options to View menu

[bugzilla-daemon]

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

--- Comment #2 from pedro.silva  ---
(In reply to Heiko Tietze from comment #1)
> Helplines while moving are under View > Grid and Helplines. What else
> exactly do you expect in the main menu? Please keep in mind that a clean
> menu is a big plus for usability. And you may also customize the menu for
> your needs (Tools > Customize).

Understood and agreed, (I though I already answer but I see that no) I was
testing with different versions and I think I miss that or that I had some sort
of customization. Anyhow thanks for taking the time.

-- 
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 127319] Feature request: Spellcheck: Ignore superscript footnote anchors

[bugzilla-daemon]

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

m.a.riosv  changed:

   What|Removed |Added

   Severity|normal  |enhancement

-- 
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