Re: buildbot/bin/sendEmail issue

[Maarten Hoes]

Hi,

On Mon, Jan 26, 2015 at 6:34 AM, Jonathan Aquilina 
wrote:
>
> Hi Maarten,
>
> Did you manage to get it working?
>
Yes, after patching sendEmail.


Thanks,


- Maarten
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: buildbot/bin/sendEmail issue

[Jonathan Aquilina]

I did it a bit differently I setup postfix to work as the relay through
gmail, and that for the most part worked out of the box for me.

On Mon, Jan 26, 2015 at 9:01 AM, Maarten Hoes 
wrote:

> Hi,
>
> On Mon, Jan 26, 2015 at 6:34 AM, Jonathan Aquilina 
> wrote:
> >
> > Hi Maarten,
> >
> > Did you manage to get it working?
> >
> Yes, after patching sendEmail.
>
>
> Thanks,
>
>
> - Maarten
>
>


-- 
Jonathan Aquilina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Workflow between dev, UX and l10n teams

[Sophie]

Hi,

Resending as there was no answer to the proposals :)
Cheers
Sophie
Le 19/01/2015 11:03, Sophie a écrit :
> Hi all,
> 
> [Please follow-up the discussion on projects@ list to keep the history
> of the thread there and ease the discussion, thanks :-)]
> 
> I would like to open a discussion about the way developers team, UX team
> and l10n team should interact and work together.
> 
> There has been a heavy discussion [see this thread 1] during this round
> of translation. The l10n team was a bit frustrated that there were again
> so many changes in the en_US version that does not concern the l10n
> versions (like adding colon at the end or capitals in the middle of the
> strings).
> 
> Each time, it seems part of this could be automated or a reflection
> on how to avoid messing the l10n work should have been introduced before
> those changes are committed. For example, if I decide to change FR
> localization to have sentence capitalization in the menu entries, none
> of the 100 other localizations won't and shouldn't be affected. It
> should be the same for en_US version or if really impossible, try to
> find a solution that lower the impact on all localizations.
> 
> None of the l10n teams is against changing or correcting the UI of the
> en_US version and none is against the natural evolution of the suite.
> What is not bearable is when you have 100 000 changes in en_US and only
> a 1/3 concerns all the other languages and it is repeated over the
> branches.
> 
> We are trying to change our workflow to work on master instead of
> branches. That will allow us to review the strings earlier (to leverage
> heavy unneeded changes if possible) and have more time to localize. But
> that will work only if each taking part of the changes take care of the
> others.
> 
> To conclude, what l10n team would like to see is:
> - a review process of the strings before they are committed and make
> sure they respect the en_US standards (capitals, grammar, punctuation,
> typography). Maybe adding the Gnome HIG book to our pages [like 2] if
> not already.
> 
> - if there is a way to script changes, script them otherwise wait until
> there is a script available to commit them
> 
> - any time there are heavy changes that pop up in someone's mind (like
> changing ... for …) discuss it with the l10n team before committing
> those changes.
> 
> I know it may lower the enthusiasm of some contributors, but it will
> regain the one of our l10n teams for sure :)
> 
> 
> [1]
> http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
> [2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en
> 
> Cheers
> Sophie
> 


-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Jenkins verification of gerrit patches

[Miklos Vajna]

On Mon, Jan 26, 2015 at 05:28:29AM +0100, Lionel Elie Mamane  
wrote:
> Is there some way to get the compilation result? That could be a nice
> way to verify patches for a platform one does not have a build
> environment for, and/or to give an experimental version to test to a
> bug reporter.

Yes, it's possible, just the Jenkins UI is confusing a bit.

E.g. you get this link in gerrit:

http://ci.libreoffice.org/job/lo_gerrit_master/272/

Now hover your mouse over the interesting platform and click on the
small black down arrow that appears, and select console output.


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

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Miklos Vajna]

Hi David,

On Sun, Jan 25, 2015 at 04:27:12PM +, David Gerard  
wrote:
> I want to write a blog post saying how I did
> this - before I do so, will there be a problem putting it up with that
> secret (which is presumably the one in every TDF build)? Should I use
> another one? If so, how do I obtain another one?

Even if it's not hard to get the TDF secret from the binaries, it's not
fair to advertise them. The more widely it's known, the more probable
that someone will reuse it in some nasty application, then the
TDF-registered app ID will get shut down, making LibreOffice users sad.

See here on how to obtain your own ID:

https://developers.google.com/drive/web/about-auth

If you write a blog post about this topic, that's great, but I guess
best to not mention any ID explicitly, they are kind of a secret anyway.

Regards,

Miklos


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

[Bug 60739] cut/paste coding redux

[bugzilla-daemon]

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

Michaël Lefèvre  changed:

   What|Removed |Added

   Assignee|libreoffice-b...@lists.free |lefevr...@yahoo.fr
   |desktop.org |

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

Re: CppCheck Report Failure

[Miklos Vajna]

On Sun, Jan 25, 2015 at 01:08:29AM +, "cppcheck.libreoff...@gmail.com" 
 wrote:
> The cppcheck job failed with message: "Failed to run cppcheck-htmlreport."
> 
> This job was run at 2015-25-01_02:08:29 with user buildslave at host vm140 as 
> /home/buildslave/source/dev-tools/cppcheck/cppcheck-report.sh

Maybe it's better to mail the ones who have access to that VM instead of
the general public who can't help? ;-)


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

[Libreoffice-commits] core.git: 62 commits - android/Bootstrap android/CustomTarget_android_desktop.mk android/CustomTarget_lo_android.mk android/experimental android/Makefile android/mobile-config.py

[Miklos Vajna]

 android/Bootstrap/Makefile.shared  
   |   15 
 android/Bootstrap/no-resource-compress-20.xml  
   |1 
 android/Bootstrap/no-resource-compress-21.xml  
   |1 
 android/Bootstrap/no-resource-compress-22.xml  
   |1 
 android/Bootstrap/no-resource-compress-23.xml  
   |1 
 android/Bootstrap/no-resource-compress-24.xml  
   |1 
 android/Bootstrap/src/org/libreoffice/kit/Document.java
   |   12 
 android/CustomTarget_android_desktop.mk
   |2 
 android/CustomTarget_lo_android.mk 
   |2 
 android/Makefile   
   |   19 
 android/experimental/LOAndroid3/AndroidManifest.xml.in 
   |   24 -
 android/experimental/LOAndroid3/Makefile   
   |3 
 android/experimental/LOAndroid3/res/layout/about.xml   
   |   10 
 android/experimental/LOAndroid3/res/values/arrays.xml  
   |2 
 android/experimental/LOAndroid3/res/values/ids.xml 
   |4 
 android/experimental/LOAndroid3/res/values/strings.xml 
   |1 
 android/experimental/LOAndroid3/src/java/org/libreoffice/LOAbout.java  
   |   23 -
 android/experimental/LOAndroid3/src/java/org/libreoffice/LOEvent.java  
   |5 
 android/experimental/LOAndroid3/src/java/org/libreoffice/LOKitShell.java   
   |   16 
 android/experimental/LOAndroid3/src/java/org/libreoffice/LOKitThread.java  
   |   30 +
 
android/experimental/LOAndroid3/src/java/org/libreoffice/LOKitTileProvider.java 
  |   42 ++
 
android/experimental/LOAndroid3/src/java/org/libreoffice/LibreOfficeMainActivity.java
 |8 
 android/experimental/LOAndroid3/src/java/org/libreoffice/MockTileProvider.java 
   |   13 
 android/experimental/LOAndroid3/src/java/org/libreoffice/TileIdentifier.java   
   |   22 +
 android/experimental/LOAndroid3/src/java/org/libreoffice/TileProvider.java 
   |   43 ++
 android/experimental/LOAndroid3/src/java/org/libreoffice/ui/FileUtilities.java 
   |   20 -
 
android/experimental/LOAndroid3/src/java/org/libreoffice/ui/GridItemAdapter.java
  |4 
 
android/experimental/LOAndroid3/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
|   18 
 
android/experimental/LOAndroid3/src/java/org/libreoffice/ui/ListItemAdapter.java
  |4 
 
android/experimental/LOAndroid3/src/java/org/mozilla/gecko/gfx/ComposedTileLayer.java
 |   89 ++--
 
android/experimental/LOAndroid3/src/java/org/mozilla/gecko/gfx/GeckoLayerClient.java
  |   75 +--
 
android/experimental/LOAndroid3/src/java/org/mozilla/gecko/gfx/JavaPanZoomController.java
 |   15 
 android/experimental/LOAndroid3/src/java/org/mozilla/gecko/gfx/LayerView.java  
   |4 
 android/experimental/LOAndroid3/src/java/org/mozilla/gecko/gfx/SubTile.java
   |8 
 android/mobile-config.py   
   |6 
 config_host.mk.in  
   |1 
 configure.ac   
   |   37 +
 desktop/source/lib/init.cxx
   |   18 
 desktop/source/lib/lokandroid.cxx  
   |   13 
 dev/null   
   |binary
 include/LibreOfficeKit/LibreOfficeKit.h
   |   20 -
 include/LibreOfficeKit/LibreOfficeKit.hxx  
   |   12 
 include/vcl/ITiledRenderable.hxx   
   |7 
 libreofficekit/README  
   |5 
 libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx
   |   17 
 libreofficekit/source/gtk/lokdocview.c 
   |  199 +++---
 sw/inc/unotxdoc.hxx
   |2 
 sw/inc/viewsh.hxx  
   |5 
 sw/source/core/view/viewsh.cxx 
   |   14 
 sw/source/core/view/vnew.cxx  

Re: CppCheck Report Failure

[Maarten Hoes]

Hi,


On Mon, Jan 26, 2015 at 10:22 AM, Miklos Vajna 
wrote:
>
> On Sun, Jan 25, 2015 at 01:08:29AM +, "cppcheck.libreoff...@gmail.com"
 wrote:
> > The cppcheck job failed with message: "Failed to run
cppcheck-htmlreport."
> >
> > This job was run at 2015-25-01_02:08:29 with user buildslave at host
vm140 as /home/buildslave/source/dev-tools/cppcheck/cppcheck-report.sh
>
> Maybe it's better to mail the ones who have access to that VM instead of
> the general public who can't help? ;-)
>

Good point. However, as Im currently not planning on personally watching
over the job for the rest of my life, the job needs to notify someone on
failure, right ? It seemed like a good idea at the time to mail the dev
mailing list on failure (just as an email is send to the dev list on
success).

At least until a good candidate can be found to mail instead ? Of course,
Im open to suggestions (including, but not limited to, not mailing anyone
until a suitable candidate is found.).




- Maarten
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: Branch 'feature/tiled-editing' - 475 commits - accessibility/inc android/Bootstrap android/CustomTarget_android_desktop.mk android/CustomTarget_lo_android.mk android/ex

[Miklos Vajna]

Rebased ref, commits from common ancestor:
commit eb2de5c700e9c19abf96228ee8610d608d568652
Author: Miklos Vajna 
Date:   Fri Jan 23 18:38:55 2015 +0100

LOK: don't ignore all callback events when we're in the callback already

There are two conflicting requirements here:

- if there was an invalidation event, and PaintTile() is called due to
  that, then we're not interested in invalidation events generated by
  PaintTile() itself.
- we do want other event types all the time like the cursor rectangle

Change SwViewShell::libreOfficeKitCallback(), so that it doesn't ignore
all callbacks when we're in the callback already, just the so far only
problematic type: tile invalidation.

Change-Id: Idcaedbbe0fe2b5b1aa9bafbfe33a81c8011fe148

diff --git a/sw/inc/viewsh.hxx b/sw/inc/viewsh.hxx
index 8ee2d11..16db81b 100644
--- a/sw/inc/viewsh.hxx
+++ b/sw/inc/viewsh.hxx
@@ -197,6 +197,7 @@ protected:
 
 LibreOfficeKitCallback mpLibreOfficeKitCallback;
 void* mpLibreOfficeKitData;
+bool mbInLibreOfficeKitCallback;
 
 public:
 TYPEINFO();
diff --git a/sw/source/core/view/viewsh.cxx b/sw/source/core/view/viewsh.cxx
index 0d7dcb7..14741cd 100644
--- a/sw/source/core/view/viewsh.cxx
+++ b/sw/source/core/view/viewsh.cxx
@@ -125,6 +125,11 @@ void 
SwViewShell::registerLibreOfficeKitCallback(LibreOfficeKitCallback pCallbac
 
 void SwViewShell::libreOfficeKitCallback(int nType, const char* pPayload) const
 {
+if (mbInLibreOfficeKitCallback && nType == LOK_CALLBACK_INVALIDATE_TILES)
+// Make sure no more invalidation events are issued when we're in the
+// callback already.
+return;
+
 if (mpLibreOfficeKitCallback)
 mpLibreOfficeKitCallback(nType, pPayload, mpLibreOfficeKitData);
 }
@@ -1775,8 +1780,7 @@ void SwViewShell::PaintTile(VirtualDevice &rDevice, int 
contextWidth, int contex
 OutputDevice *pSaveOut = mpOut;
 bool bTiledRendering = mbTiledRendering;
 mbTiledRendering = true;
-LibreOfficeKitCallback pCallback = mpLibreOfficeKitCallback;
-mpLibreOfficeKitCallback = 0;
+mbInLibreOfficeKitCallback = true;
 mpOut = &rDevice;
 
 // resizes the virtual device so to contain the entrie context
@@ -1824,7 +1828,7 @@ void SwViewShell::PaintTile(VirtualDevice &rDevice, int 
contextWidth, int contex
 
 // SwViewShell's output device tear down
 mpOut = pSaveOut;
-mpLibreOfficeKitCallback = pCallback;
+mbInLibreOfficeKitCallback = false;
 mbTiledRendering = bTiledRendering;
 
 static bool bDebug = getenv("SW_DEBUG_TILEDRENDERING") != 0;
diff --git a/sw/source/core/view/vnew.cxx b/sw/source/core/view/vnew.cxx
index 6a951a1..d4813f9 100644
--- a/sw/source/core/view/vnew.cxx
+++ b/sw/source/core/view/vnew.cxx
@@ -171,6 +171,7 @@ SwViewShell::SwViewShell( SwDoc& rDocument, vcl::Window 
*pWindow,
 mbSelectAll(false),
 mpLibreOfficeKitCallback(0),
 mpLibreOfficeKitData(0),
+mbInLibreOfficeKitCallback(false),
 mpPrePostOutDev(0), // #i72754#
 maPrePostMapMode()
 {
@@ -249,6 +250,7 @@ SwViewShell::SwViewShell( SwViewShell& rShell, vcl::Window 
*pWindow,
 mbSelectAll(false),
 mpLibreOfficeKitCallback(0),
 mpLibreOfficeKitData(0),
+mbInLibreOfficeKitCallback(false),
 mpPrePostOutDev(0), // #i72754#
 maPrePostMapMode()
 {
commit c7ce08fbb1fa7f5f91d5fc2b2257370976fc4c30
Author: Miklos Vajna 
Date:   Fri Jan 23 17:13:03 2015 +0100

sw: missing consts

Change-Id: I052c8dfb668cbc31ba03d9b68bc21be58fce0e2a

diff --git a/sw/inc/viewsh.hxx b/sw/inc/viewsh.hxx
index 6a73d55..8ee2d11 100644
--- a/sw/inc/viewsh.hxx
+++ b/sw/inc/viewsh.hxx
@@ -580,11 +580,11 @@ public:
 /// The actual implementation of the 
vcl::ITiledRenderable::registerCallback() API for Writer.
 void registerLibreOfficeKitCallback(LibreOfficeKitCallback pCallback, 
void* pLibreOfficeKitData);
 /// Invokes the registered callback, if there are any.
-void libreOfficeKitCallback(int nType, const char* pPayload);
+void libreOfficeKitCallback(int nType, const char* pPayload) const;
 /// Set if we are doing tiled rendering.
 void setTiledRendering(bool bTiledRendering);
 /// Are we doing tiled rendering?
-bool isTiledRendering();
+bool isTiledRendering() const;
 
 };
 
diff --git a/sw/source/core/view/viewsh.cxx b/sw/source/core/view/viewsh.cxx
index 5e13cd5..0d7dcb7 100644
--- a/sw/source/core/view/viewsh.cxx
+++ b/sw/source/core/view/viewsh.cxx
@@ -123,7 +123,7 @@ void 
SwViewShell::registerLibreOfficeKitCallback(LibreOfficeKitCallback pCallbac
 mpLibreOfficeKitData = pData;
 }
 
-void SwViewShell::libreOfficeKitCallback(int nType, const char* pPayload)
+void SwViewShell::libreOfficeKitCallback(int nType, const char* pPayload) const
 {
 if (mpLibreOfficeKitCallback)
 mpLibreOfficeKitCallback(nType, pPayload, mpLibreOfficeKitData);
@@ -134,7 +134,7 @@ void SwViewShell::setTiledRendering(bool bTiledRendering)
   

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Alex Thurgood]

Le 26/01/2015 10:04, Miklos Vajna a écrit :

Hi Miklos,

> See here on how to obtain your own ID:
> 
> https://developers.google.com/drive/web/about-auth
> 

So, just to further my understanding of the practicalities involved, if
I want to use Google Docs/Drive CMIS integration on Mac, or Linux, for
myself, I have to build LO with credentials that I've obtained according
to the link you posted above ? Not really an accessible feature then, as
in, broadly accessible to the public, is it ?

Note that I'm not criticizing, but trying to understand why, from a
marketing perspective, we tout a feature that actually isn't available
in the builds we deliver publicly for platforms other than Windows, or
perhaps have I completely misunderstood how it works ?


Alex




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

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Miklos Vajna]

Hi Alex,

https://wiki.documentfoundation.org/Development/ReleaseBuilds documents
that the gdrive flags are also used for TDF builds, so they are
available for the general public.

Regards,

Miklos


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

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

[Miklos Vajna]

 libreofficekit/source/gtk/lokdocview.c |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 883ae86d2a204dee39f0288733901a5b8ac70d8f
Author: Miklos Vajna 
Date:   Mon Jan 26 10:57:10 2015 +0100

fix for missing g_info

Change-Id: Ibfab6d3aadb126fc357fd2d15485dcde8ceefa94

diff --git a/libreofficekit/source/gtk/lokdocview.c 
b/libreofficekit/source/gtk/lokdocview.c
index bb2444c..7264563 100644
--- a/libreofficekit/source/gtk/lokdocview.c
+++ b/libreofficekit/source/gtk/lokdocview.c
@@ -19,6 +19,9 @@
 #ifndef G_SOURCE_REMOVE
 #define G_SOURCE_REMOVE FALSE
 #endif
+#ifndef g_info
+#define g_info(...) g_log(G_LOG_DOMAIN, G_LOG_LEVEL_INFO, __VA_ARGS__)
+#endif
 
 static void lok_docview_class_init( LOKDocViewClass* pClass );
 static void lok_docview_init( LOKDocView* pDocView );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: Branch 'aoo/trunk' - toolkit/source xmlscript/dtd xmlscript/source

[Tsutomu Uchino]

 toolkit/source/helper/property.cxx |2 -
 xmlscript/dtd/dialog.dtd   |1 
 xmlscript/source/xmldlg_imexp/exp_share.hxx|2 +
 xmlscript/source/xmldlg_imexp/imp_share.hxx|3 +
 xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx |2 +
 xmlscript/source/xmldlg_imexp/xmldlg_export.cxx|   31 +
 xmlscript/source/xmldlg_imexp/xmldlg_impmodels.cxx |3 +
 xmlscript/source/xmldlg_imexp/xmldlg_import.cxx|   38 +
 8 files changed, 81 insertions(+), 1 deletion(-)

New commits:
commit 350c4f9a01b88d4fd1006465151348ac5d459f1a
Author: Tsutomu Uchino 
Date:   Mon Jan 26 09:06:52 2015 +

#i98734# store and load ScaleMode property of image control on dialogs

Suggested by: Frank Schönheit 

diff --git a/toolkit/source/helper/property.cxx 
b/toolkit/source/helper/property.cxx
index 830cc32..aeb4c37 100644
--- a/toolkit/source/helper/property.cxx
+++ b/toolkit/source/helper/property.cxx
@@ -217,7 +217,7 @@ ImplPropertyInfo* ImplGetPropertyInfos( sal_uInt16& 
rElementCount )
 DECL_PROP_2 ( "AutoRepeat", AUTO_REPEAT,
sal_Bool,   BOUND, MAYBEDEFAULT ),
 DECL_PROP_2 ( "RepeatDelay",REPEAT_DELAY,   
sal_Int32,  BOUND, MAYBEDEFAULT ),
 DECL_PROP_2 ( "ScaleImage", SCALEIMAGE, 
bool,   BOUND, MAYBEDEFAULT ),
-DECL_PROP_2 ( "ScaleMode",  IMAGE_SCALE_MODE,   
sal_Int16,  BOUND, MAYBEDEFAULT ),
+DECL_DEP_PROP_2 ( "ScaleMode",  IMAGE_SCALE_MODE,   
sal_Int16,  BOUND, MAYBEDEFAULT ),
 DECL_DEP_PROP_3 ( "ScrollValue",SCROLLVALUE,
sal_Int32,  BOUND, MAYBEDEFAULT, MAYBEVOID ),
 DECL_PROP_2 ( "ScrollValueMax", SCROLLVALUE_MAX,
sal_Int32,  BOUND, MAYBEDEFAULT ),
 DECL_PROP_2 ( "ScrollValueMin", SCROLLVALUE_MIN,
sal_Int32,  BOUND, MAYBEDEFAULT ),
diff --git a/xmlscript/dtd/dialog.dtd b/xmlscript/dtd/dialog.dtd
index 56525f0..414521e 100644
--- a/xmlscript/dtd/dialog.dtd
+++ b/xmlscript/dtd/dialog.dtd
@@ -247,6 +247,7 @@
 
 
diff --git a/xmlscript/source/xmldlg_imexp/exp_share.hxx 
b/xmlscript/source/xmldlg_imexp/exp_share.hxx
index 37ea633a..1e2bdaa 100644
--- a/xmlscript/source/xmldlg_imexp/exp_share.hxx
+++ b/xmlscript/source/xmldlg_imexp/exp_share.hxx
@@ -153,6 +153,8 @@ public:
 ::rtl::OUString const & rPropName, ::rtl::OUString const & rAttrName );
 void readSelectionTypeAttr(
 ::rtl::OUString const & rPropName, ::rtl::OUString const & rAttrName );
+void readImageScaleModeAttr(
+::rtl::OUString const & rPropName, ::rtl::OUString const & rAttrName );
 //
 inline void addBoolAttr(
 ::rtl::OUString const & rAttrName, sal_Bool bValue )
diff --git a/xmlscript/source/xmldlg_imexp/imp_share.hxx 
b/xmlscript/source/xmldlg_imexp/imp_share.hxx
index 1ef84a0..922e485 100644
--- a/xmlscript/source/xmldlg_imexp/imp_share.hxx
+++ b/xmlscript/source/xmldlg_imexp/imp_share.hxx
@@ -447,6 +447,9 @@ public:
 bool importSelectionTypeProperty(
 ::rtl::OUString const & rPropName, ::rtl::OUString const & rAttrName,
 css::uno::Reference const & xAttributes 
);
+bool importImageScaleModeProperty(
+::rtl::OUString const & rPropName, ::rtl::OUString const & rAttrName,
+css::uno::Reference const & xAttributes 
);
 };
 
 
//==
diff --git a/xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx 
b/xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx
index 46b1b01..a021e19 100644
--- a/xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx
+++ b/xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx
@@ -591,6 +591,8 @@ void ElementDescriptor::readImageControlModel( StyleBag * 
all_styles )
 readDefaults();
 readBoolAttr( OUString( RTL_CONSTASCII_USTRINGPARAM("ScaleImage") ),
   OUString( RTL_CONSTASCII_USTRINGPARAM(XMLNS_DIALOGS_PREFIX 
":scale-image") ) );
+readImageScaleModeAttr( OUString( RTL_CONSTASCII_USTRINGPARAM("ScaleMode") 
),
+   OUString( RTL_CONSTASCII_USTRINGPARAM(XMLNS_DIALOGS_PREFIX 
":scale-mode") ) );
 readStringAttr( OUString( RTL_CONSTASCII_USTRINGPARAM("ImageURL") ),
 OUString( RTL_CONSTASCII_USTRINGPARAM(XMLNS_DIALOGS_PREFIX 
":src") ) );
 readBoolAttr( OUString( RTL_CONSTASCII_USTRINGPARAM("Tabstop") ),
diff --git a/xmlscript/source/xmldlg_imexp/xmldlg_export.cxx 
b/xmlscript/source/xmldlg_imexp/xmldlg_export.cxx
index 3485138..64ca41a 100644
--- a/xmlscript/source/xmldlg_imexp/xmldlg_export.cxx
+++ b/xmlscript/source/xmldlg_imexp/xmldlg_export.cxx
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -968,6 +969,36 @@ void ElementDescriptor::readSel

Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Tom Davies]

Hi :)
Yeh i think Sophie did such a brilliant job of summarising all the
points that no-one had anything to argue against.

My main concern was about automating the bits that could be automated
in some sensible way - preferably some way that each language could
select to opt into or out of.  In wiki-editing people are encouraged
to write a summary, like a subject-line in an email, for changes
beyond just a couple of characters.  Something like that might help
with the automation.

I really liked the point about having some way of identifying trivial
but frequent changes and minor grammer corrections that most
translators will already have dealt with in order to make sense in
their own language(s).

There was a lot of other interesting things in Sophie's post but i
just agree with all of them and that makes it difficult to discuss ;(
It seems like just about everyone here feels the same way.

Regards from
Tom :)



On 26 January 2015 at 09:32, Sveinn í Felli  wrote:
> Þann mán 26.jan 2015 09:25, skrifaði Mihovil Stanić:
>>
>> Not sure what can we add here?
>>
>> You summed it up nicely in those 3 points.
>> As far as I'm concerned, en_us can be changed/improved as much as anyone
>> wants... only if they provide script for automatic update for all other
>> affected languages.
>>
>> New strings - OK
>> Edited strings with changed meaning, fixed typos - OK
>> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
>> different quote styles I don't even have on my keyboard) and anything
>> similliar - NOT OK if you don't script it for all languages
>> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
>> change just for en_us, don't change my strings and don't even notify me
>> you did it in en_us
>
>
> May I add here:
>
> XML/HTML entities and such ( to ) - NOT OK, scripted for
> all languages (if possible)
>
> Sveinn í Felli
>
>> Mihovil
>>
>>
>> 26.01.2015 u 09:33, Sophie je napisao/la:
>>>
>>>
>>> To conclude, what l10n team would like to see is:
>>> - a review process of the strings before they are committed and make
>>> sure they respect the en_US standards (capitals, grammar, punctuation,
>>> typography). Maybe adding the Gnome HIG book to our pages [like 2] if
>>> not already.
>>>
>>> - if there is a way to script changes, script them otherwise wait until
>>> there is a script available to commit them
>>>
>>> - any time there are heavy changes that pop up in someone's mind (like
>>> changing ... for …) discuss it with the l10n team before committing
>>> those changes.
>>>
>>>
>>
>>
>
>
> --
> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be
> deleted
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

-fnothrow-opt

[Stephan Bergmann]

In case anybody ever wonders: -fnothrow-opt (treating "throw ()" like 
"noexcept", 
; 
only available in GCC, not in Clang) would appear to not buy us anything 
for LO:  For one, it has zero effect on the generated code with 
-fno-enforce-eh-specs (enabled for --disable-dbgutil; only available in 
GCC, not in Clang).  For another, even if we used -fenforce-eh-specs, my 
GCC 4.9.2 --disable-dbgutil Linux master build would only shrink instdir 
by 20 bytes (from 1,817,288 to 1,817,268).

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

[Libreoffice-commits] core.git: Changes to 'feature/barcode'

[Michael Meeks]

New branch 'feature/barcode' available with the following commits:
commit fd9ab498690ec2bcee31d0d97492fb317432e1a4
Author: Michael Meeks 
Date:   Sun Jan 25 21:29:46 2015 +

barcodes: initial attempt to use zint to render bar-codes.

We create a plug-able CustomShape engine; currently no UI for
editing (add draw:engine="org.libreoffice.draw.barcode"
draw:data="baa code" to your draw:custom-shape in the ODF).

Change-Id: Ibcc7e6e068402a0aa37dfb858fa2aafe5e7c94c8

commit 93f6fb68d0702afe936fe53cdb54ad28d5e4e0f8
Author: Michael Meeks 
Date:   Sun Jan 25 18:57:48 2015 +

zint-barcode: add optional internal barcode functionality from zint.

Rather a useful chunk of code, but no sane release management
up-stream, and a choice of several forks up-stream. So no 'system'
version until that is fixed.

Change-Id: I063f1e5b36548102350e7200c7f622d237268471

commit 18ad06e44533c29832b5ec8779de1d1e5c32d4ed
Author: Michael Meeks 
Date:   Sun Jan 25 12:27:11 2015 +

xmloff: fix initialization order for custom shape engines.

Initialize needs to be invoked by SdXMLShapeContext::AddShape
before we start setting properties, otherwise we mis-configure
the target SdrObjCustomShape with the  wrong CustomShapeEngine
before we set those.

Change-Id: If5a3922e18f3888e316b51572d6cda996082974c

___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: -fnothrow-opt

[Stephan Bergmann]

On 01/26/2015 11:28 AM, Stephan Bergmann wrote:

In case anybody ever wonders: -fnothrow-opt (treating "throw ()" like
"noexcept",
;
only available in GCC, not in Clang) would appear to not buy us anything
for LO:  For one, it has zero effect on the generated code with
-fno-enforce-eh-specs (enabled for --disable-dbgutil; only available in
GCC, not in Clang).  For another, even if we used -fenforce-eh-specs, my
GCC 4.9.2 --disable-dbgutil Linux master build would only shrink instdir
by 20 bytes (from 1,817,288 to 1,817,268).


kilo-bytes, of course
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Jenkins verification of gerrit patches

[Michael Stahl]

On 26.01.2015 09:57, Miklos Vajna wrote:
> On Mon, Jan 26, 2015 at 05:28:29AM +0100, Lionel Elie Mamane 
>  wrote:
>> Is there some way to get the compilation result? That could be a nice
>> way to verify patches for a platform one does not have a build
>> environment for, and/or to give an experimental version to test to a
>> bug reporter.
> 
> Yes, it's possible, just the Jenkins UI is confusing a bit.
> 
> E.g. you get this link in gerrit:
> 
> http://ci.libreoffice.org/job/lo_gerrit_master/272/
> 
> Now hover your mouse over the interesting platform and click on the
> small black down arrow that appears, and select console output.
> 

i believe Lionel was interested in installation sets, not the build log
(although how to get the latter is indeed unnecessarily obscure).


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

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

[Miklos Vajna]

 libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx |4 
 1 file changed, 4 insertions(+)

New commits:
commit d6587d789ac67daa94677670c6e3a001e45c139d
Author: Miklos Vajna 
Date:   Mon Jan 26 11:40:33 2015 +0100

gtktiledviewer: fix for missing g_info()

Change-Id: I04a91065526b49bacb72c7d4865440efc3b3f7d0

diff --git a/libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx 
b/libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx
index 66c56e7..a12303d 100644
--- a/libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx
+++ b/libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx
@@ -21,6 +21,10 @@
 
 #include 
 
+#ifndef g_info
+#define g_info(...) g_log(G_LOG_DOMAIN, G_LOG_LEVEL_INFO, __VA_ARGS__)
+#endif
+
 static int help()
 {
 fprintf( stderr, "Usage: gtktiledviewer 
 \n" );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Jesper Hertel]

Hi Sophie and everybody else,

Well I didn't answer as I didn't feel like finding out what the "projects@
list" was and joining that list to be able to join the discussion there.

I will answer here.

I did not read the whole previous discussion but did anyone suggest to add
a new en-us translation language in Pootle and let that be the place where
all non-semantic changes to the en-us strings happen? That way the current
strings in the source code will turn into mere translation keys written in
en-us. The final en-us polishing will then happen in the translation files
just like any other language and will of course not affect any of the other
languages.

Any semantic change should of course still happen in the "keys", i.e. the
source code, but non-semantic changes should be prohibited there and
instead made in the en-us translation in Pootle.

This might be something obvious that you already talked a lot about, but I
just want to make sure this option isn't overlooked.

Jesper
Den 26/01/2015 09.34 skrev "Sophie" :

> Hi,
>
> Resending as there was no answer to the proposals :)
> Cheers
> Sophie
> Le 19/01/2015 11:03, Sophie a écrit :
> > Hi all,
> >
> > [Please follow-up the discussion on projects@ list to keep the history
> > of the thread there and ease the discussion, thanks :-)]
> >
> > I would like to open a discussion about the way developers team, UX team
> > and l10n team should interact and work together.
> >
> > There has been a heavy discussion [see this thread 1] during this round
> > of translation. The l10n team was a bit frustrated that there were again
> > so many changes in the en_US version that does not concern the l10n
> > versions (like adding colon at the end or capitals in the middle of the
> > strings).
> >
> > Each time, it seems part of this could be automated or a reflection
> > on how to avoid messing the l10n work should have been introduced before
> > those changes are committed. For example, if I decide to change FR
> > localization to have sentence capitalization in the menu entries, none
> > of the 100 other localizations won't and shouldn't be affected. It
> > should be the same for en_US version or if really impossible, try to
> > find a solution that lower the impact on all localizations.
> >
> > None of the l10n teams is against changing or correcting the UI of the
> > en_US version and none is against the natural evolution of the suite.
> > What is not bearable is when you have 100 000 changes in en_US and only
> > a 1/3 concerns all the other languages and it is repeated over the
> > branches.
> >
> > We are trying to change our workflow to work on master instead of
> > branches. That will allow us to review the strings earlier (to leverage
> > heavy unneeded changes if possible) and have more time to localize. But
> > that will work only if each taking part of the changes take care of the
> > others.
> >
> > To conclude, what l10n team would like to see is:
> > - a review process of the strings before they are committed and make
> > sure they respect the en_US standards (capitals, grammar, punctuation,
> > typography). Maybe adding the Gnome HIG book to our pages [like 2] if
> > not already.
> >
> > - if there is a way to script changes, script them otherwise wait until
> > there is a script available to commit them
> >
> > - any time there are heavy changes that pop up in someone's mind (like
> > changing ... for …) discuss it with the l10n team before committing
> > those changes.
> >
> > I know it may lower the enthusiasm of some contributors, but it will
> > regain the one of our l10n teams for sure :)
> >
> >
> > [1]
> >
> http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
> > [2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en
> >
> > Cheers
> > Sophie
> >
>
>
> --
> Sophie Gautier sophie.gaut...@documentfoundation.org
> Tel:+33683901545
> Co-founder - Release coordinator
> The Document Foundation
>
> --
> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: sal/osl sd/source

[Michael Stahl]

 sal/osl/w32/socket.cxx  |   22 ++
 sal/osl/w32/system.h|1 +
 sd/source/ui/remotecontrol/DiscoveryService.cxx |   11 +++
 3 files changed, 34 insertions(+)

New commits:
commit c106f83da16726506962e19bcbc3d4c25415b81a
Author: Michael Stahl 
Date:   Fri Jan 23 16:38:46 2015 +0100

sal,sd: Windows SDK 8.1 deprecates inet_addr()

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

diff --git a/sal/osl/w32/socket.cxx b/sal/osl/w32/socket.cxx
index 86f455e..a6487fa 100644
--- a/sal/osl/w32/socket.cxx
+++ b/sal/osl/w32/socket.cxx
@@ -584,6 +584,15 @@ oslSocketAddr SAL_CALL osl_createInetBroadcastAddr (
 
 if (strDottedAddr && strDottedAddr->length)
 {
+// the Win32 SDK 8.1 deprecates inet_addr()
+#ifdef _WIN32_WINNT_WINBLUE
+IN_ADDR addr;
+INT ret = InetPtonW(AF_INET, strDottedAddr->buffer, & addr);
+if (1 == ret)
+{
+nAddr = addr.S_un.S_addr;
+}
+#else
 /* Dotted host address for limited broadcast */
 rtl_String *pDottedAddr = NULL;
 
@@ -592,7 +601,9 @@ oslSocketAddr SAL_CALL osl_createInetBroadcastAddr (
 RTL_TEXTENCODING_UTF8, OUSTRING_TO_OSTRING_CVTFLAGS);
 
 nAddr = inet_addr (pDottedAddr->buffer);
+
 rtl_string_release (pDottedAddr);
+#endif
 }
 
 if (nAddr != OSL_INADDR_NONE)
@@ -635,6 +646,16 @@ oslSocketAddr SAL_CALL osl_createInetSocketAddr (
 sal_Int32Port)
 {
 sal_uInt32 Addr;
+
+// the Win32 SDK 8.1 deprecates inet_addr()
+#ifdef _WIN32_WINNT_WINBLUE
+IN_ADDR addr;
+INT ret = InetPtonW(AF_INET, strDottedAddr->buffer, & addr);
+if (1 == ret)
+{
+Addr = addr.S_un.S_addr;
+}
+#else
 rtl_String  *pDottedAddr=NULL;
 
 rtl_uString2String(
@@ -643,6 +664,7 @@ oslSocketAddr SAL_CALL osl_createInetSocketAddr (
 
 Addr= inet_addr (pDottedAddr->buffer);
 rtl_string_release (pDottedAddr);
+#endif
 
 oslSocketAddr pAddr = 0;
 if(Addr != OSL_INADDR_NONE)
diff --git a/sal/osl/w32/system.h b/sal/osl/w32/system.h
index 57a7a0f..e461ad9 100644
--- a/sal/osl/w32/system.h
+++ b/sal/osl/w32/system.h
@@ -68,6 +68,7 @@
 #pragma warning(disable:4917)
 #include 
 #include 
+#include 
 #include 
 #ifndef NO_DEBUG_CRT
 #include 
diff --git a/sd/source/ui/remotecontrol/DiscoveryService.cxx 
b/sd/source/ui/remotecontrol/DiscoveryService.cxx
index 04ef5e7..5cd9907 100644
--- a/sd/source/ui/remotecontrol/DiscoveryService.cxx
+++ b/sd/source/ui/remotecontrol/DiscoveryService.cxx
@@ -122,7 +122,18 @@ void DiscoveryService::setupSockets()
 
 struct ip_mreq multicastRequest;
 
+// the Win32 SDK 8.1 deprecates inet_addr()
+#ifdef _WIN32_WINNT_WINBLUE
+IN_ADDR addr;
+OUString const saddr("239.0.0.1");
+INT ret = InetPtonW(AF_INET, saddr.getStr(), & addr);
+if (1 == ret)
+{
+multicastRequest.imr_multiaddr.s_addr = addr.S_un.S_addr;
+}
+#else
 multicastRequest.imr_multiaddr.s_addr = inet_addr( "239.0.0.1" );
+#endif
 multicastRequest.imr_interface.s_addr = htonl(INADDR_ANY);
 
 rc = setsockopt( mSocket, IPPROTO_IP, IP_ADD_MEMBERSHIP,
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Tom Davies]

Hi :)
Yes that suggestion was put forwards in the previous thread and i
still think it is an excellent idea - or at least has a lot of merit.
I seem to remember there were excellent reasons why it might be
unworkable but i'm not sure if they really are total blockers.
Regards from
Tom :)


On 26 January 2015 at 10:52, Jesper Hertel  wrote:
> Hi Sophie and everybody else,
>
> Well I didn't answer as I didn't feel like finding out what the "projects@
> list" was and joining that list to be able to join the discussion there.
>
> I will answer here.
>
> I did not read the whole previous discussion but did anyone suggest to add
> a new en-us translation language in Pootle and let that be the place where
> all non-semantic changes to the en-us strings happen? That way the current
> strings in the source code will turn into mere translation keys written in
> en-us. The final en-us polishing will then happen in the translation files
> just like any other language and will of course not affect any of the other
> languages.
>
> Any semantic change should of course still happen in the "keys", i.e. the
> source code, but non-semantic changes should be prohibited there and
> instead made in the en-us translation in Pootle.
>
> This might be something obvious that you already talked a lot about, but I
> just want to make sure this option isn't overlooked.
>
> Jesper
> Den 26/01/2015 09.34 skrev "Sophie" :
>
>> Hi,
>>
>> Resending as there was no answer to the proposals :)
>> Cheers
>> Sophie
>> Le 19/01/2015 11:03, Sophie a écrit :
>> > Hi all,
>> >
>> > [Please follow-up the discussion on projects@ list to keep the history
>> > of the thread there and ease the discussion, thanks :-)]
>> >
>> > I would like to open a discussion about the way developers team, UX team
>> > and l10n team should interact and work together.
>> >
>> > There has been a heavy discussion [see this thread 1] during this round
>> > of translation. The l10n team was a bit frustrated that there were again
>> > so many changes in the en_US version that does not concern the l10n
>> > versions (like adding colon at the end or capitals in the middle of the
>> > strings).
>> >
>> > Each time, it seems part of this could be automated or a reflection
>> > on how to avoid messing the l10n work should have been introduced before
>> > those changes are committed. For example, if I decide to change FR
>> > localization to have sentence capitalization in the menu entries, none
>> > of the 100 other localizations won't and shouldn't be affected. It
>> > should be the same for en_US version or if really impossible, try to
>> > find a solution that lower the impact on all localizations.
>> >
>> > None of the l10n teams is against changing or correcting the UI of the
>> > en_US version and none is against the natural evolution of the suite.
>> > What is not bearable is when you have 100 000 changes in en_US and only
>> > a 1/3 concerns all the other languages and it is repeated over the
>> > branches.
>> >
>> > We are trying to change our workflow to work on master instead of
>> > branches. That will allow us to review the strings earlier (to leverage
>> > heavy unneeded changes if possible) and have more time to localize. But
>> > that will work only if each taking part of the changes take care of the
>> > others.
>> >
>> > To conclude, what l10n team would like to see is:
>> > - a review process of the strings before they are committed and make
>> > sure they respect the en_US standards (capitals, grammar, punctuation,
>> > typography). Maybe adding the Gnome HIG book to our pages [like 2] if
>> > not already.
>> >
>> > - if there is a way to script changes, script them otherwise wait until
>> > there is a script available to commit them
>> >
>> > - any time there are heavy changes that pop up in someone's mind (like
>> > changing ... for …) discuss it with the l10n team before committing
>> > those changes.
>> >
>> > I know it may lower the enthusiasm of some contributors, but it will
>> > regain the one of our l10n teams for sure :)
>> >
>> >
>> > [1]
>> >
>> http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
>> > [2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en
>> >
>> > Cheers
>> > Sophie
>> >
>>
>>
>> --
>> Sophie Gautier sophie.gaut...@documentfoundation.org
>> Tel:+33683901545
>> Co-founder - Release coordinator
>> The Document Foundation
>>
>> --
>> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
>> Problems?
>> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
>> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
>> List archive: http://listarchives.libreoffice.org/global/l10n/
>> All messages sent to this list will be publicly archived and cannot be
>> deleted
>>
>
> --
> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
> Problems? 
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/

[Libreoffice-commits] core.git: 44 commits - filter/source rsc/source sc/inc sc/source sfx2/source starmath/source svtools/source svx/source sw/source tools/source vcl/source

[Caolán McNamara]

 filter/source/msfilter/svdfppt.cxx  |8 +
 rsc/source/rsc/rsc.cxx  |6 
 sc/inc/document.hxx |2 -
 sc/inc/table.hxx|2 -
 sc/source/core/data/document.cxx|   13 +
 sc/source/core/data/table2.cxx  |   11 +---
 sc/source/core/tool/interpr1.cxx|5 +++
 sc/source/core/tool/interpr4.cxx|3 --
 sc/source/filter/excel/xeformula.cxx|   13 +
 sc/source/filter/excel/xiescher.cxx |   12 +++-
 sc/source/ui/dbgui/pvfundlg.cxx |3 +-
 sc/source/ui/view/viewfun4.cxx  |4 +-
 sfx2/source/dialog/templdlg.cxx |3 +-
 starmath/source/cursor.cxx  |2 +
 starmath/source/mathtype.cxx|   16 +--
 starmath/source/mathtype.hxx|2 -
 svtools/source/dialogs/roadmapwizard.cxx|6 ++--
 svx/source/tbxctrls/Palette.cxx |2 -
 svx/source/xml/xmlgrhlp.cxx |6 ++--
 sw/source/core/crsr/trvltbl.cxx |4 +-
 sw/source/core/doc/doctxm.cxx   |6 ++--
 sw/source/core/doc/tblafmt.cxx  |   28 ++--
 sw/source/core/doc/tblrwcl.cxx  |2 -
 sw/source/core/layout/frmtool.cxx   |   29 ++---
 sw/source/core/layout/trvlfrm.cxx   |2 -
 sw/source/core/undo/unattr.cxx  |2 -
 sw/source/filter/ww8/rtfattributeoutput.cxx |   10 ---
 sw/source/filter/ww8/wrtw8nds.cxx   |4 +-
 sw/source/filter/ww8/ww8par3.cxx|   17 +++-
 sw/source/uibase/docvw/edtwin.cxx   |1 
 sw/source/uibase/shells/basesh.cxx  |   38 +---
 sw/source/uibase/shells/drawsh.cxx  |5 ++-
 sw/source/uibase/uiview/view2.cxx   |7 +++--
 sw/source/uibase/uiview/viewmdi.cxx |2 -
 tools/source/generic/poly2.cxx  |   18 +
 vcl/source/control/longcurr.cxx |2 +
 vcl/source/gdi/cvtsvm.cxx   |9 ++
 vcl/source/gdi/jobset.cxx   |   10 +--
 vcl/source/gdi/metaact.cxx  |   10 ++-
 vcl/source/gdi/regionband.cxx   |3 --
 40 files changed, 225 insertions(+), 103 deletions(-)

New commits:
commit 22fe039000e57c156e5a4317f899987a9a043974
Author: Caolán McNamara 
Date:   Mon Jan 26 11:53:55 2015 +

coverity#1266484 rework to scrutinze mnLen

Change-Id: I8fb6d555a7f7afe02b4c0297d3fe4e456ba41dd0

diff --git a/vcl/source/gdi/metaact.cxx b/vcl/source/gdi/metaact.cxx
index a60e8fd..9dbcce0 100644
--- a/vcl/source/gdi/metaact.cxx
+++ b/vcl/source/gdi/metaact.cxx
@@ -1289,7 +1289,7 @@ void MetaTextArrayAction::Read( SvStream& rIStm, 
ImplMetaReadData* pData )
 sal_Int32 nAryLen(0);
 rIStm.ReadInt32(nAryLen);
 
-if ( mnIndex + mnLen > maStr.getLength() )
+if (mnLen > maStr.getLength() - mnIndex)
 {
 mnIndex = 0;
 mpDXAry = 0;
commit bbc17bc8ac9132379d1348de761793bf2961d96b
Author: Caolán McNamara 
Date:   Mon Jan 26 11:42:22 2015 +

coverity#704347 Logically dead code

const bool bSelectUp = ( bVert && !bRow );
...
if ( bSelectUp )
...
else
bVert ? (bRow ? 0 : 3) : (bRow ? 2 : 1)

the bRow is only queried on the non-bSelectUp path
if bVert is true then bRow must be also true, because
if bVert is true and bRow is false we would be in
the other branch

Change-Id: I784b41dbfda1afaf574fd8259eff3ab5cc5550fe

diff --git a/sw/source/core/crsr/trvltbl.cxx b/sw/source/core/crsr/trvltbl.cxx
index 2eabdde..fd0d20c 100644
--- a/sw/source/core/crsr/trvltbl.cxx
+++ b/sw/source/core/crsr/trvltbl.cxx
@@ -218,9 +218,9 @@ bool SwCrsrShell::_SelTblRowOrCol( bool bRow, bool 
bRowSimple )
 else
 {
 // will become point of table cursor
-pStt = aCells[ bVert ? (bRow ? 0 : 3) : (bRow ? 2 : 1) 
]->GetTabBox();
+pStt = aCells[bVert ? 0 : (bRow ? 2 : 1)]->GetTabBox();
 // will become mark of table cursor
-pEnd = aCells[ bVert ? (bRow ? 3 : 0) : (bRow ? 1 : 2) 
]->GetTabBox();
+pEnd = aCells[bVert ? 3 : (bRow ? 1 : 2)]->GetTabBox();
 }
 }
 
commit 1d687e81769a42540b1fe4206dd58a2d3236f47e
Author: Caolán McNamara 
Date:   Mon Jan 26 11:40:58 2015 +

coverity#708424 Uninitialized scalar field

Change-Id: I96d4c457f8eb64de7d2009b6d6b78fda4a15a4d8

diff --git a/sw/source/core/layout/frmtool.cxx 
b/sw/source/core/layout/frmtool.cxx
index 352dadd..7145ef7 100644
--- a/sw/source/core/layout/frmtool.cxx
+++ b/sw/source/core/layout/frmtool.cxx
@@ -1817,18 +1817,29 @@ void MakeFrms( SwDoc *pDoc, const SwNodeIndex &rSttIdx,
 bObjsDirect = true;
 }
 
-SwBorderAttrs::SwBorderAttrs( const SwModify *pMod, const SwFrm *pConstructor 
) :
- 

Re: New Defects reported by Coverity Scan for LibreOffice

[Caolán McNamara]

On Sun, 2015-01-25 at 05:23 -0800, scan-ad...@coverity.com wrote:
> Hi,
> 
> Please find the latest report on new defect(s) introduced to LibreOffice 
> found with Coverity Scan.
> 
> 70 new defect(s) introduced to LibreOffice found with Coverity Scan.
> 503 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
> recent build analyzed by Coverity Scan.

We're now using the latest coverity release of 7.6.0 which comes with
extra warnings. So what's going on here with the +70 is newly detected
warnings with old code. and the -503 is because the previous build
failed to build ~500 cxx files under coverity 7.5.0 with some unknown
parse error which prompted to upgrade to 7.6.0 which worked again.

C.

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

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

[Luboš Luňák]

 vcl/workben/vcldemo.cxx |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

New commits:
commit 1854a92340bb46d892d24265d28b9781309c1d6b
Author: Luboš Luňák 
Date:   Thu Dec 18 11:47:28 2014 +0100

there's no bigger or smaller half

Change-Id: Ida0e92abd806d017d17365fa2ac53b4f7cb2ebad

diff --git a/vcl/workben/vcldemo.cxx b/vcl/workben/vcldemo.cxx
index 888c7b1..a932c06 100644
--- a/vcl/workben/vcldemo.cxx
+++ b/vcl/workben/vcldemo.cxx
@@ -251,6 +251,10 @@ public:
 };
 for (size_t i = 0; i < aRegions.size(); i++)
 {
+// Half of them not-anti-aliased ..
+if (i >= aRegions.size()/2)
+rDev.SetAntialiasing(nOldAA);
+
 static const struct {
 double nX, nY;
 } aPoints[] = {
@@ -265,10 +269,6 @@ public:
aSub.Top()  + 
aSub.GetHeight() * aPoints[j].nY));
 }
 rDev.DrawPolyLine(aPoly, aLineWidths[i], eJoins[i], 
eLineCaps[i]);
-
-// Half of them not-anti-aliased ..
-if (i > aRegions.size()/2)
-rDev.SetAntialiasing(nOldAA);
 }
 }
 else
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Miklos Vajna]

 libreofficekit/source/gtk/lokdocview.c |4 
 1 file changed, 4 insertions(+)

New commits:
commit 64235bc9896911b4abfca47089ac1e71056afea7
Author: Miklos Vajna 
Date:   Mon Jan 26 14:08:45 2015 +0100

lokdocview: fix for missing gtk_table_get_size()

Change-Id: Ib3f9849c2f28375a7e8bcd6575a6c3da0860d4fb

diff --git a/libreofficekit/source/gtk/lokdocview.c 
b/libreofficekit/source/gtk/lokdocview.c
index 7264563..372fa9d 100644
--- a/libreofficekit/source/gtk/lokdocview.c
+++ b/libreofficekit/source/gtk/lokdocview.c
@@ -163,10 +163,14 @@ void renderDocument(LOKDocView* pDocView, GdkRectangle* 
pPartial)
 // Same as nRows / nColumns, but from the previous renderDocument() 
call.
 guint nOldRows, nOldColumns;
 
+#if GTK_CHECK_VERSION(2,22,0)
 gtk_table_get_size(GTK_TABLE(pDocView->pTable), &nOldRows, 
&nOldColumns);
 if (nOldRows != nRows || nOldColumns != nColumns)
 // Can't do partial rendering, document size changed.
 pPartial = NULL;
+#else
+pPartial = NULL;
+#endif
 }
 if (!pPartial)
 {
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Jesper Hertel]

2015-01-26 12:15 GMT+01:00 Tom Davies :

> Hi :)
>

Hi Tom!


> Yes that suggestion was put forwards in the previous thread


Good! And thank you for telling me that.


> and i still think it is an excellent idea - or at least has a lot of merit.
>

I absolutely agree ;-).


> I seem to remember there were excellent reasons why it might be
> unworkable


I am curious to see those reasons. Guess I will have to browse through the
discussion to find it. But it is rather long, so I might not do that right
now.


> but i'm not sure if they really are total blockers.
>

I can't see how they could be total blockers. LibreOffice comes in hundreds
of languages, so this would just be a new language like any other, and
adding new languages has never seemed to be a big problem before.

There could even still be a language-simplistic version of LibreOffice with
only the unpolished source code keys used and no translation to polished
en-us (if anybody prefer such a version?), but people that want the
language to be polished and correct would just pick up the en-us
translation like everybody else picks up the translation for their own
local language. Why should en-us have any special status in the
construction of the final product?

It doesn't solve the problems with adding colons etc. to existing strings –
changes like that should of course still be automated. But it would solve
problems resulting from changes in style, correction of non-semantic typos,
etc.

And everybody working in Pootle could still add the polished and correct
en-us translation as one of their "alternative source languages" (you can
do that in the settings [1]) and we could all therefore still use the
polished, correct en-us translation as the basis of our translations if we
prefer that over the more coarse, non-polished key strings from the source
code.

Of course I might be repeating arguments that have already been stated in
the earlier discussion. If anyone can find the right part of the original
discussion (perhaps because they know what to search for because they
remember the discussion) they are more than welcome to point it out to me.

[1]: https://translations.documentfoundation.org/accounts/edit/

Regards from
Jesper

Regards from
> Tom :)
>
>
> On 26 January 2015 at 10:52, Jesper Hertel 
> wrote:
> > Hi Sophie and everybody else,
> >
> > Well I didn't answer as I didn't feel like finding out what the
> "projects@
> > list" was and joining that list to be able to join the discussion there.
> >
> > I will answer here.
> >
> > I did not read the whole previous discussion but did anyone suggest to
> add
> > a new en-us translation language in Pootle and let that be the place
> where
> > all non-semantic changes to the en-us strings happen? That way the
> current
> > strings in the source code will turn into mere translation keys written
> in
> > en-us. The final en-us polishing will then happen in the translation
> files
> > just like any other language and will of course not affect any of the
> other
> > languages.
> >
> > Any semantic change should of course still happen in the "keys", i.e. the
> > source code, but non-semantic changes should be prohibited there and
> > instead made in the en-us translation in Pootle.
> >
> > This might be something obvious that you already talked a lot about, but
> I
> > just want to make sure this option isn't overlooked.
> >
> > Jesper
> > Den 26/01/2015 09.34 skrev "Sophie" :
> >
> >> Hi,
> >>
> >> Resending as there was no answer to the proposals :)
> >> Cheers
> >> Sophie
> >> Le 19/01/2015 11:03, Sophie a écrit :
> >> > Hi all,
> >> >
> >> > [Please follow-up the discussion on projects@ list to keep the
> history
> >> > of the thread there and ease the discussion, thanks :-)]
> >> >
> >> > I would like to open a discussion about the way developers team, UX
> team
> >> > and l10n team should interact and work together.
> >> >
> >> > There has been a heavy discussion [see this thread 1] during this
> round
> >> > of translation. The l10n team was a bit frustrated that there were
> again
> >> > so many changes in the en_US version that does not concern the l10n
> >> > versions (like adding colon at the end or capitals in the middle of
> the
> >> > strings).
> >> >
> >> > Each time, it seems part of this could be automated or a reflection
> >> > on how to avoid messing the l10n work should have been introduced
> before
> >> > those changes are committed. For example, if I decide to change FR
> >> > localization to have sentence capitalization in the menu entries, none
> >> > of the 100 other localizations won't and shouldn't be affected. It
> >> > should be the same for en_US version or if really impossible, try to
> >> > find a solution that lower the impact on all localizations.
> >> >
> >> > None of the l10n teams is against changing or correcting the UI of the
> >> > en_US version and none is against the natural evolution of the suite.
> >> > What is not bearable is when you have 100 000 changes in e

Re: Jenkins verification of gerrit patches

[Lionel Elie Mamane]

On Mon, Jan 26, 2015 at 11:40:33AM +0100, Michael Stahl wrote:
> On 26.01.2015 09:57, Miklos Vajna wrote:
>> On Mon, Jan 26, 2015 at 05:28:29AM +0100, Lionel Elie Mamane 
>>  wrote:

>>> Is there some way to get the compilation result? That could be a
>>> nice way to verify patches for a platform one does not have a
>>> build environment for, and/or to give an experimental version to
>>> test to a bug reporter.

>> Yes, it's possible, just the Jenkins UI is confusing a bit.

>> E.g. you get this link in gerrit:

>> http://ci.libreoffice.org/job/lo_gerrit_master/272/

>> Now hover your mouse over the interesting platform and click on the
>> small black down arrow that appears, and select console output.

> I believe Lionel was interested in installation sets, not the build
> log

Indeed.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 60739] cut/paste coding redux

[bugzilla-daemon]

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

--- Comment #10 from Michaël Lefèvre  ---
Factorise FN_WORDCOUNT_DIALOG case in https://gerrit.libreoffice.org/14182 .

More cases could be cleaned up :
FN_FORMAT_FOOTNOTE_DLG
FN_NUMBERING_OUTLINE_DLG:
SID_OPEN_XML_FILTERSETTINGS
...

I'm planning to change the other ones, referencing this bug. Any objection ?

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

Re: New Defects reported by Coverity Scan for LibreOffice

[Stephan Bergmann]

On 01/25/2015 02:23 PM, scan-ad...@coverity.com wrote:

*** CID 1266445:  Explicit null dereferenced  (FORWARD_NULL)
/cppuhelper/source/component_context.cxx: 747 in 
cppu::ComponentContext::disposing()()
741 &envs, &envCount, &rtl_allocateMemory, OUString("java").pData);
742 assert(envCount >= 0);
743 assert(envCount == 0 || envs != nullptr);
744 for (sal_Int32 i = 0; i != envCount; ++i) {
745 assert(envs[i] != nullptr);
746 assert(envs[i]->dispose != nullptr);

 CID 1266445:  Explicit null dereferenced  (FORWARD_NULL)
 Dereferencing null pointer "envs".

747 (*envs[i]->dispose)(envs[i]);


What was the state of these builds again, they're implicitly 
--disable-debug, --disable-assert-always-abort, and making them 
--enable-debug would run out of resources?  Could they be made 
--enable-assert-always-abort, in the hope that that would silence the 
above false positive (or would that need some explicit coverity comment 
annotation anyway)?

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

Re: New Defects reported by Coverity Scan for LibreOffice

[Caolán McNamara]

On Mon, 2015-01-26 at 14:49 +0100, Stephan Bergmann wrote:
> What was the state of these builds again, they're implicitly 
> --disable-debug, --disable-assert-always-abort, and making them 
> --enable-debug would run out of resources?  Could they be made 
> --enable-assert-always-abort, in the hope that that would silence the 
> above false positive (or would that need some explicit coverity comment 
> annotation anyway)?

I'll add --enable-assert-always-abort for the next run to see what
happens.

Coverity allows us two slots every 7 days (next slot is Jan 29). Each
build+upload+analysis takes about a day. There is/was some (unknown)
timeout on the coverity side for the analysis, something like 12-16
hours and a few times in the past we've hit it, nearly always at
weekends. Quite possibly a bunch of projects have a "run coverity
automatically at the w/e process" making us vulnerable that the coverity
servers don't have enough capacity to complete our analysis before the
timeout if we submit at those times.

IIRC I hit the timeout with an --enable-dbgutil build every time I tried
it. But it might be that an --enable-debug would work ok (I'm not even
sure if there would be a difference to what coverity would scrape out of
our source between --enable-assert-always-abort and --enable-debug) and
I can experiment again but it's a bit like trying to steer a
supertanker.

C.

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

[Libreoffice-commits] core.git: 9 commits - drawinglayer/source external/boost external/cppunit external/harfbuzz external/icu external/libodfgen filter/source include/com include/registry include/rtl

[Stephan Bergmann]

 RepositoryExternal.mk|2 
 drawinglayer/source/drawinglayeruno/xprimitive2drenderer.cxx |1 
 external/boost/UnpackedTarball_boost.mk  |1 
 external/boost/rtti.patch.0  |   20 +
 external/cppunit/UnpackedTarball_cppunit.mk  |1 
 external/cppunit/rtti.patch.0|   15 +++
 external/harfbuzz/ubsan.patch|   42 +++
 external/icu/UnpackedTarball_icu.mk  |1 
 external/icu/rtti.patch.0|   11 ++
 external/libodfgen/ExternalProject_libodfgen.mk  |2 
 external/libodfgen/UnpackedTarball_libodfgen.mk  |1 
 external/libodfgen/rtti.patch|   11 ++
 filter/source/graphicfilter/ipict/ipict.cxx  |3 
 include/com/sun/star/uno/Any.h   |2 
 include/com/sun/star/uno/Reference.h |2 
 include/com/sun/star/uno/Sequence.h  |2 
 include/com/sun/star/uno/Type.h  |2 
 include/registry/regtype.h   |6 -
 include/rtl/alloc.h  |2 
 include/rtl/string.hxx   |2 
 include/rtl/unload.h |2 
 include/rtl/ustring.h|2 
 include/rtl/ustring.hxx  |2 
 include/sfx2/childwin.hxx|8 +-
 include/tools/ref.hxx|2 
 include/typelib/typedescription.h|6 -
 include/uno/any2.h   |2 
 include/uno/dispatcher.h |2 
 include/uno/environment.h|4 -
 include/uno/mapping.h|2 
 package/source/xstor/xfactory.cxx|3 
 sal/textenc/tenchelp.hxx |2 
 sc/inc/filter.hxx|2 
 sc/source/ui/view/tabvwsh.cxx|3 
 scripting/source/vbaevents/service.cxx   |6 -
 sd/source/filter/eppt/eppt.cxx   |7 +
 sd/source/filter/html/HtmlOptionsDialog.cxx  |1 
 svl/source/uno/pathservice.cxx   |1 
 svtools/source/control/asynclink.cxx |8 --
 sw/qa/extras/ooxmlexport/data/fdo79822-SPECIAL.docx  |binary
 sw/source/uibase/web/wdocsh.cxx  |3 
 sw/source/uibase/web/wformsh.cxx |3 
 sw/source/uibase/web/wfrmsh.cxx  |3 
 sw/source/uibase/web/wgrfsh.cxx  |3 
 sw/source/uibase/web/wlistsh.cxx |3 
 sw/source/uibase/web/wtabsh.cxx  |3 
 sw/source/uibase/web/wtextsh.cxx |3 
 sw/source/uibase/web/wview.cxx   |3 
 vcl/inc/salframe.hxx |4 -
 vcl/inc/unx/desktops.hxx |6 +
 vcl/source/components/dtranscomp.cxx |1 
 vcl/source/components/fontident.cxx  |1 
 vcl/unx/generic/plugadapt/salplug.cxx|   11 ++
 xmloff/source/chart/SchXMLExport.cxx |1 
 xmloff/source/draw/animationimport.cxx   |1 
 xmloff/source/meta/MetaImportComponent.cxx   |1 
 xmloff/source/transform/OOo2Oasis.cxx|1 
 xmloff/source/transform/Oasis2OOo.cxx|1 
 58 files changed, 202 insertions(+), 44 deletions(-)

New commits:
commit 6de91546198e5bfbe0399274284114b550e2f030
Author: Stephan Bergmann 
Date:   Mon Jan 26 15:16:48 2015 +0100

Make sure _nEventId gets reset after calling RemoveUserEvent

Change-Id: I8f90fb809d5275e8a74964776f01f4d563f2e657

diff --git a/svtools/source/control/asynclink.cxx 
b/svtools/source/control/asynclink.cxx
index 1efd934..ca745b2 100644
--- a/svtools/source/control/asynclink.cxx
+++ b/svtools/source/control/asynclink.cxx
@@ -48,13 +48,7 @@ bAllowDoubles
 DBG_ASSERT( bAllowDoubles ||
 ( !_nEventId && ( !_pIdle || !_pIdle->IsActive() ) ),
 "Schon ein Call unterwegs" );
-if( _nEventId )
-{
-if( _pMutex ) _pMutex->acquire();
-Application::RemoveUserEvent( _nEventId );
-if( _pMutex ) _pMutex->release();
-   

Re: Workflow between dev, UX and l10n teams

[Jan Holesovsky]

Hi Sophie, Mihovil,

Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:

> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those 
> different quote styles I don't even have on my keyboard) and anything 
> similliar - NOT OK if you don't script it for all languages
> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all, 
> change just for en_us, don't change my strings and don't even notify me 
> you did it in en_us

I see 2 problems here:

1) There is no tool that would detect these trivial changes, and would
   act accordingly.

2) The texts for translations are updated in big 'code' drops, without
   possibility for translators to affect the process in any way - for
   them it is too late.

Regarding 1) - I thought that Pootle is detecting the trivial changes
some way, and offering the original translation.  Is it not?  What can
be done to improve that, so that for translators it is just a matter of
checking; not a matter of translating?  [Or even what you suggest - that
it would just update the source strings without touching the
translations?]

Regarding 2) - I'm glad that you say that the strings will be now
getting to Pootle immediately after the code / string changes in master.
I think it is important that the translators will be able to deal with
the changes immediately, not several months later, so that they can
cooperate, and not only react.

In general, I don't think that setting extremely strict rules works,
unless you have means how to enforce them - like via a commit hook or so
(and it is extremely unpopular way to do things).

It is always much better to communicate - if you see a developer who
commits a change that causes you grief, please _do_ tell _him/her_
immediately, and - if possible - in a friendly way.  I'm sure he/she
will do much better the next time.

Unfortunately I did not see any signs of notice that this or that change
was problematic for localization on the development mailing list - were
there such warnings there?  Like "commit XY caused AB - please don't do
such things, unless we agree how to do that effectively / without pain"?
Or was it impossible so far because the strings in Pootle were not
synced with master?

Also - should we have a 'Localization' recurring topic in the ESC?  Who
would be the right representative there, please?

All the best,
Kendy

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

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

[László Németh]

 sc/inc/address.hxx  |3 ++
 sc/source/core/tool/address.cxx |   45 
 sc/source/filter/excel/xestream.cxx |   10 
 sc/source/filter/excel/xetable.cxx  |   14 ---
 sc/source/filter/inc/xestream.hxx   |2 +
 5 files changed, 71 insertions(+), 3 deletions(-)

New commits:
commit 0d2ce71afe0cb2657a6919e641e54c8fc9ba288c
Author: László Németh 
Date:   Mon Jan 26 15:45:05 2015 +0100

fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX export

Change-Id: Ie6a024463e7ee9b0f4492b2431533708a578faf0

diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index 06c450b..aa05a58 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,6 +325,9 @@ public:
 ExternalInfo* pExtInfo = NULL,
 const css::uno::Sequence* 
pExternalLinks = NULL );
 
+SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
+  const ScDocument* pDocument = NULL,
+  const Details& rDetails = detailsOOOa1) 
const;
 SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
   const ScDocument* pDocument = NULL,
   const Details& rDetails = detailsOOOa1) 
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 39fc9a4..886b866 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,6 +1745,51 @@ static OUString getFileNameFromDoc( const ScDocument* 
pDoc )
 return sFileName;
 }
 
+/** Tries to obtain a simple address without OUString/OString allocation
+ *
+ *  @returns TRUE at success (it is enough to call OUString Format() at FALSE)
+ *
+ */
+
+bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
+   const Details& rDetails) const
+{
+if( nFlags & SCA_VALID )
+nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
+if(( pDoc && (nFlags & SCA_VALID_TAB ) && ( nTab >= pDoc->GetTableCount() 
|| ( nFlags & SCA_TAB_3D ))) ||
+ ! (nFlags & SCA_VALID_COL) || ! (nFlags & SCA_VALID_ROW) ||
+(nFlags & SCA_COL_ABSOLUTE) != 0 || (nFlags & SCA_ROW_ABSOLUTE) != 
0 )
+{
+   return false;
+}
+
+switch( rDetails.eConv )
+{
+default :
+// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following 
simple addresses
+case formula::FormulaGrammar::CONV_OOO:
+case formula::FormulaGrammar::CONV_XL_A1:
+case formula::FormulaGrammar::CONV_XL_OOX:
+if (nCol >= 26 * 26)
+// TODO: extend it for full column range
+return false;
+if( nCol < 26 )
+*s = 'A' + nCol;
+else
+{
+*s = 'A' + nCol / 26 - 1;
+s++;
+*s = 'A' + nCol % 26;
+}
+sprintf(s + 1, "%d", nRow + 1);
+break;
+case formula::FormulaGrammar::CONV_XL_R1C1:
+// not used in XLSX export
+return false;
+}
+return true;
+}
+
 OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details& rDetails) const
 {
diff --git a/sc/source/filter/excel/xestream.cxx 
b/sc/source/filter/excel/xestream.cxx
index e5ff50c..188fcd6 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,6 +718,11 @@ OString XclXmlUtils::ToOString( const OUString& s )
 return OUStringToOString( s, RTL_TEXTENCODING_UTF8  );
 }
 
+bool XclXmlUtils::TryToChar( char * s, const ScAddress& rAddress )
+{
+return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1));
+}
+
 OString XclXmlUtils::ToOString( const ScAddress& rAddress )
 {
 OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1)));
@@ -760,6 +765,11 @@ static ScAddress lcl_ToAddress( const XclAddress& rAddress 
)
 return aAddress;
 }
 
+bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress& rAddress )
+{
+return TryToChar( s, lcl_ToAddress( rAddress ));
+}
+
 OString XclXmlUtils::ToOString( const XclAddress& rAddress )
 {
 return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx 
b/sc/source/filter/excel/xetable.cxx
index 70f3373..dd527d3 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,6 +41,11 @@ using namespace ::oox;
 
 namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
 
+// max string length of simple addresses (eg. ABC100\0)
+#if MAXROWCOUNT_DEFINE < 999
+#define SIMPLEADDRESSLEN 11
+#endif
+
 // Helper records for cell records
 
 XclExpStringRec::XclExpStringRec( const XclExpRoot& rRoot, const OUString& 
rResult ) :
@@ -630,9 +635,10 @@ static OString lcl_GetStyleId( XclExpXmlStream& rStrm, 
const XclExpCellBase& rCe
 
 void XclExpNumberCell::S

Re: Workflow between dev, UX and l10n teams

[Sophie]

Hi Kendy,
Le 26/01/2015 15:43, Jan Holesovsky a écrit :
> Hi Sophie, Mihovil,
> 
> Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:
> 
>> Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those 
>> different quote styles I don't even have on my keyboard) and anything 
>> similliar - NOT OK if you don't script it for all languages
>> Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all, 
>> change just for en_us, don't change my strings and don't even notify me 
>> you did it in en_us
> 
> I see 2 problems here:
> 
> 1) There is no tool that would detect these trivial changes, and would
>act accordingly.
> 
> 2) The texts for translations are updated in big 'code' drops, without
>possibility for translators to affect the process in any way - for
>them it is too late.
> 
> Regarding 1) - I thought that Pootle is detecting the trivial changes
> some way, and offering the original translation.  Is it not?  What can
> be done to improve that, so that for translators it is just a matter of
> checking; not a matter of translating?  [Or even what you suggest - that
> it would just update the source strings without touching the
> translations?]

Pootle will show you a modified string, even if it doesn't affect your
translation you will have to validate the string again to have it on a
translated state. Also we don't all work on Pootle, several of us are
working off line and Pootle is only a repository for our files.

That's why we were thinking of a en_US version as a real language and
different from the sources and also about scripting changes when
possible (like the substitution of ~ by _)
> 
> Regarding 2) - I'm glad that you say that the strings will be now
> getting to Pootle immediately after the code / string changes in master.
> I think it is important that the translators will be able to deal with
> the changes immediately, not several months later, so that they can
> cooperate, and not only react.

yes, that's much better, even if we have to be cautious about the workflow.

> 
> In general, I don't think that setting extremely strict rules works,
> unless you have means how to enforce them - like via a commit hook or so
> (and it is extremely unpopular way to do things).
> 
> It is always much better to communicate - if you see a developer who
> commits a change that causes you grief, please _do_ tell _him/her_
> immediately, and - if possible - in a friendly way.  I'm sure he/she
> will do much better the next time.

Translators are for most of them non technical people and will not see a
commit, but only the result on Pootle, sometimes months later. In the
same way the developer who is doing tons of changes for en_US is invited
to discuss them with the l10n team :)
> 
> Unfortunately I did not see any signs of notice that this or that change
> was problematic for localization on the development mailing list - were
> there such warnings there?  Like "commit XY caused AB - please don't do
> such things, unless we agree how to do that effectively / without pain"?
> Or was it impossible so far because the strings in Pootle were not
> synced with master?

Yes, I think it was too late and when the l10n team is at work, it's the
rush i.e RC time for developers, so not the best period to discuss hot
topics ;) That's why I've waited to open this discussion.
Also, even if I've discussed as much as possible about l10n on issues
concerning UI changes, it's a lot of work to follow each commit that
could have an effect. Sharing the effort between developers/UX/l10n
teams should be possible. As we follow Gnome HIG, adding it as
pre-requisite for UI changes/adds may prevent to have to rewrite dialogs
for example.
> 
> Also - should we have a 'Localization' recurring topic in the ESC?  Who
> would be the right representative there, please?

Maybe not as a recurring topic, but something that should be in mind of
UX team and developers when they commit or check for commits that have a
huge impact on l10n.

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Caolán McNamara]

 unotools/qa/unit/testGetEnglishSearchName.cxx |7 +++
 unotools/source/misc/fontdefs.cxx |2 --
 vcl/generic/fontmanager/fontcache.cxx |2 +-
 3 files changed, 4 insertions(+), 7 deletions(-)

New commits:
commit 15e1c881684c0127c0ca989924bbf2508b4fd780
Author: Caolán McNamara 
Date:   Mon Jan 26 15:00:29 2015 +

don't strip font names of apparent script suffixes anymore

e.g. "CM Roman CE" should be left alone.

bump font cache id to invalidate old cached lists

I think this practice stems from Window 3.1/Word 95 where the encoding was
included in the font name
http://www.webcenter.ru/~kazarn/eng/fonts_ttf.htm#charsettbl Microsoft 
Office
still generates RTF files with weird-ass Win 3.1 style fontnames but any 
actual
existing fonts that happen to have names that fall into that pattern should 
be
left alone now.

Change-Id: Ibb704048d63b33ce510d6b1076700c6e94a0af2a

diff --git a/unotools/qa/unit/testGetEnglishSearchName.cxx 
b/unotools/qa/unit/testGetEnglishSearchName.cxx
index dbc8b17..c9d8e1f 100644
--- a/unotools/qa/unit/testGetEnglishSearchName.cxx
+++ b/unotools/qa/unit/testGetEnglishSearchName.cxx
@@ -39,12 +39,11 @@ void Test::testSingleElement()
 //trailingWhitespaces
 test1 = GetEnglishSearchFontName( "Symbol" );
 CPPUNIT_ASSERT_EQUAL(OUString("symbol"),test1);
-//removing Skripts
+//no longer remove script suffixes
 test1 = GetEnglishSearchFontName( "Symbol(SIP)" );
 CPPUNIT_ASSERT_EQUAL(OUString("symbol(sip)"),test1);
-//remove Whitespaces between
-test1 = GetEnglishSearchFontName( "Symbol (thai)" );
-CPPUNIT_ASSERT_EQUAL( OUString("symbol"),test1);
+test1 = GetEnglishSearchFontName( "CM Roman CE" );
+CPPUNIT_ASSERT_EQUAL( OUString("cmromance"),test1);
 //remove special characters; leave semicolon, numbers
 test1 = GetEnglishSearchFontName( "sy;mb?=ol129" );
 CPPUNIT_ASSERT_EQUAL( OUString("sy;mbol129"),test1);
diff --git a/unotools/source/misc/fontdefs.cxx 
b/unotools/source/misc/fontdefs.cxx
index f368cc6..04c6fc4 100644
--- a/unotools/source/misc/fontdefs.cxx
+++ b/unotools/source/misc/fontdefs.cxx
@@ -367,8 +367,6 @@ OUString GetEnglishSearchFontName(const OUString& rInName)
 if ( i != nLen )
  rName.truncate(i);
 
-// Remove Script at the end
-rName = StripScriptFromName(rName.toString());
 nLen = rName.getLength();
 
 // remove all whitespaces and converts to lower case ASCII
diff --git a/vcl/generic/fontmanager/fontcache.cxx 
b/vcl/generic/fontmanager/fontcache.cxx
index 56a15bf..e978eb7 100644
--- a/vcl/generic/fontmanager/fontcache.cxx
+++ b/vcl/generic/fontmanager/fontcache.cxx
@@ -38,7 +38,7 @@
 #endif
 
 #define FONTCACHEFILE "/user/psprint/pspfontcache"
-#define CACHE_MAGIC "LibreOffice PspFontCacheFile format 5"
+#define CACHE_MAGIC "LibreOffice PspFontCacheFile format 6"
 
 using namespace std;
 using namespace psp;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Workflow between dev, UX and l10n teams

[Jan Holesovsky]

Hi Sophie,

Sophie píše v Po 26. 01. 2015 v 16:19 +0100:

> Pootle will show you a modified string, even if it doesn't affect your
> translation you will have to validate the string again to have it on a
> translated state. Also we don't all work on Pootle, several of us are
> working off line and Pootle is only a repository for our files.

But the offline files are taken from Pootle too - right?  So if fixes
are done at the time of uploading to Pootle, everybody gets them -
correct?

> That's why we were thinking of a en_US version as a real language and
> different from the sources and

But at some stage this will have to apply to the sources - and at that
time, it will be even worse than now :-(  I'm afraid having en_US as a
separate language will make the situation worse, not better.

>  also about scripting changes when
> possible (like the substitution of ~ by _)

Sure - so I think this was something that could have been automatized
with a trivial script; when this was noticed for the first time, please?
Pity that it was not brought to the ESC as a problem...

> Translators are for most of them non technical people and will not see a
> commit, but only the result on Pootle, sometimes months later.

The "months later" is the problem, not the non-technicality :-)  It is
enough to send "something happened yesterday - please check what's up";
similarly to how people are checking the daily builds.

> > Also - should we have a 'Localization' recurring topic in the ESC?  Who
> > would be the right representative there, please?
> 
> Maybe not as a recurring topic, but something that should be in mind of
> UX team and developers when they commit or check for commits that have a
> huge impact on l10n.

Well - if it's not recurring, it's easy to forget ;-)  Also I think it
will be more effective to discuss this there - are you able to join this
Thursday?

All the best,
Kendy

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

Re: Workflow between dev, UX and l10n teams

[Sophie]

Hi Kendy,
Le 26/01/2015 16:40, Jan Holesovsky a écrit :
> Hi Sophie,
> 
> Sophie píše v Po 26. 01. 2015 v 16:19 +0100:
> 
>> Pootle will show you a modified string, even if it doesn't affect your
>> translation you will have to validate the string again to have it on a
>> translated state. Also we don't all work on Pootle, several of us are
>> working off line and Pootle is only a repository for our files.
> 
> But the offline files are taken from Pootle too - right?  So if fixes
> are done at the time of uploading to Pootle, everybody gets them -
> correct?

yes, I'll have a meeting with Dwayne (Pootle developer) during Fosdem
and will discuss with him about that.
> 
>> That's why we were thinking of a en_US version as a real language and
>> different from the sources and
> 
> But at some stage this will have to apply to the sources - and at that
> time, it will be even worse than now :-(  I'm afraid having en_US as a
> separate language will make the situation worse, not better.

Yes, I'm not sure either
> 
>>  also about scripting changes when
>> possible (like the substitution of ~ by _)
> 
> Sure - so I think this was something that could have been automatized
> with a trivial script; when this was noticed for the first time, please?
> Pity that it was not brought to the ESC as a problem...

It was brought on the dev list, but when the l10n team discovered it, it
was too late. Cloph has already scripted several changes, but he can't
do it all.
> 
>> Translators are for most of them non technical people and will not see a
>> commit, but only the result on Pootle, sometimes months later.
> 
> The "months later" is the problem, not the non-technicality :-)  It is
> enough to send "something happened yesterday - please check what's up";
> similarly to how people are checking the daily builds.

that will be possible now that some of us are translating on master
> 
>>> Also - should we have a 'Localization' recurring topic in the ESC?  Who
>>> would be the right representative there, please?
>>
>> Maybe not as a recurring topic, but something that should be in mind of
>> UX team and developers when they commit or check for commits that have a
>> huge impact on l10n.
> 
> Well - if it's not recurring, it's easy to forget ;-)  Also I think it
> will be more effective to discuss this there - are you able to join this
> Thursday?

Thanks for the invitation and yes, let me know the time and I'll join.

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Alexander Thurgood]

Le 26/01/2015 10:49, Miklos Vajna a écrit :

Hi Miklos,
> 
> https://wiki.documentfoundation.org/Development/ReleaseBuilds documents
> that the gdrive flags are also used for TDF builds, so they are
> available for the general public.
> 

Thanks, but that page references x86 builds for MacOSX and not x86_64.
Is it still applicable for our 64bit OSX releases ?

Alex


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

Re: Jenkins verification of gerrit patches

[Norbert Thiebaud]

On Mon, Jan 26, 2015 at 7:28 AM, Lionel Elie Mamane  wrote:
> On Mon, Jan 26, 2015 at 11:40:33AM +0100, Michael Stahl wrote:
>> On 26.01.2015 09:57, Miklos Vajna wrote:
>>> On Mon, Jan 26, 2015 at 05:28:29AM +0100, Lionel Elie Mamane 
>>>  wrote:
>
 Is there some way to get the compilation result? That could be a
 nice way to verify patches for a platform one does not have a
 build environment for, and/or to give an experimental version to
 test to a bug reporter.
>
>>> Yes, it's possible, just the Jenkins UI is confusing a bit.
>
>>> E.g. you get this link in gerrit:
>
>>> http://ci.libreoffice.org/job/lo_gerrit_master/272/
>
>>> Now hover your mouse over the interesting platform and click on the
>>> small black down arrow that appears, and select console output.
>
>> I believe Lionel was interested in installation sets, not the build
>> log
>
> Indeed.

is it 'possible' ?, yes in theory, no in practice as long as I
physically host a bunch of the slaves, since I absolutely do not have
the upload bandwidth to support this.

longer term I envision to have the mac mini shipped to a hoster and
move the windows slave into VMs in TDF infra...
at which point it should be possible to have them upload 'build artifacts'

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

[Libreoffice-commits] core.git: 5 commits - basic/source i18npool/inc i18npool/source i18npool/util include/unotools offapi/com offapi/UnoApi_offapi.mk svl/qa svl/source unotools/source

[Eike Rathke]

 basic/source/runtime/methods1.cxx |   20 
 i18npool/inc/calendarImpl.hxx |   14 
 i18npool/inc/calendar_gregorian.hxx   |4 
 i18npool/source/calendar/calendarImpl.cxx |   23 
 i18npool/source/calendar/calendar_gregorian.cxx   |   34 +
 i18npool/source/registerservices/registerservices.cxx |3 
 i18npool/util/i18npool.component  |1 
 include/unotools/calendarwrapper.hxx  |   18 
 offapi/UnoApi_offapi.mk   |2 
 offapi/com/sun/star/i18n/LocaleCalendar2.idl  |   27 
 offapi/com/sun/star/i18n/XCalendar.idl|   12 
 offapi/com/sun/star/i18n/XCalendar4.idl   |   57 +
 svl/qa/unit/svl.cxx   |  561 +-
 svl/source/numbers/zforfind.cxx   |6 
 unotools/source/i18n/calendarwrapper.cxx  |   47 -
 15 files changed, 726 insertions(+), 103 deletions(-)

New commits:
commit 58da9ef3f19643e20b9b22c3a3f0855c62c0d199
Author: Eike Rathke 
Date:   Mon Jan 26 17:59:04 2015 +0100

merge existing date input tests to new unit test, tdf#63230

diff --git a/svl/qa/unit/svl.cxx b/svl/qa/unit/svl.cxx
index 4a9a080..76c3f3f 100644
--- a/svl/qa/unit/svl.cxx
+++ b/svl/qa/unit/svl.cxx
@@ -57,7 +57,6 @@ public:
 void testSharedString();
 void testSharedStringPool();
 void testSharedStringPoolPurge();
-void testFdo44286();
 void testFdo60915();
 void testI116701();
 void testDateInput();
@@ -67,7 +66,6 @@ public:
 CPPUNIT_TEST(testSharedString);
 CPPUNIT_TEST(testSharedStringPool);
 CPPUNIT_TEST(testSharedStringPoolPurge);
-CPPUNIT_TEST(testFdo44286);
 CPPUNIT_TEST(testFdo60915);
 CPPUNIT_TEST(testI116701);
 CPPUNIT_TEST(testDateInput);
@@ -407,32 +405,6 @@ void Test::checkPreviewString(SvNumberFormatter& 
aFormatter,
 CPPUNIT_ASSERT_EQUAL(sExpected, sStr);
 }
 
-void Test::testFdo44286()
-{
-LanguageType eLang = LANGUAGE_ENGLISH_US;
-OUString sCode = "-MM-DD", sExpected;
-double fPreviewNumber;
-SvNumberFormatter aFormatter(m_xContext, eLang);
-{
-
icu::TimeZone::adoptDefault(icu::TimeZone::createTimeZone("America/Sao_Paulo"));
-sExpected = "1902-04-22";
-fPreviewNumber = 843;
-checkPreviewString(aFormatter, sCode, fPreviewNumber, eLang, 
sExpected);
-}
-{
-
icu::TimeZone::adoptDefault(icu::TimeZone::createTimeZone("Europe/Berlin"));
-sExpected = "1790-07-27";
-fPreviewNumber = -39967;
-checkPreviewString(aFormatter, sCode, fPreviewNumber, eLang, 
sExpected);
-}
-{
-
icu::TimeZone::adoptDefault(icu::TimeZone::createTimeZone("US/Mountain"));
-sExpected = "1790-07-26";
-fPreviewNumber = -39968;
-checkPreviewString(aFormatter, sCode, fPreviewNumber, eLang, 
sExpected);
-}
-}
-
 void Test::testFdo60915()
 {
 LanguageType eLang = LANGUAGE_THAI;
@@ -524,6 +496,8 @@ void Test::testDateInput()
 "Europe/Tallinn", "1790-03-01", // i#105864
 "Australia/Perth", "2004-04-11",// i#17222
 "America/Sao_Paulo", "1902-04-22",  // tdf#44286
+"Europe/Berlin", "1790-07-27",
+"US/Mountain", "1790-07-26",
 
 // Data from https://bugs.documentfoundation.org/show_bug.cgi?id=63230
 // https://bugs.documentfoundation.org/attachment.cgi?id=79051
commit ce20ba5d3d6c6a88e0fd469f8bfe07e6decb3b26
Author: Eike Rathke 
Date:   Mon Jan 26 17:51:15 2015 +0100

add older problems to unit test, tdf#63230

Check that various older problems remain fixed.

diff --git a/svl/qa/unit/svl.cxx b/svl/qa/unit/svl.cxx
index 21be933..4a9a080 100644
--- a/svl/qa/unit/svl.cxx
+++ b/svl/qa/unit/svl.cxx
@@ -518,9 +518,15 @@ void Test::testI116701()
 
 void Test::testDateInput()
 {
-// Data from https://bugs.documentfoundation.org/show_bug.cgi?id=63230
-// attachment https://bugs.documentfoundation.org/attachment.cgi?id=79051
 const char* aData[][2] = {
+"Europe/Paris", "1938-10-07",   // i#76623
+"Europe/Moscow", "1919-07-01",  // i#86094
+"Europe/Tallinn", "1790-03-01", // i#105864
+"Australia/Perth", "2004-04-11",// i#17222
+"America/Sao_Paulo", "1902-04-22",  // tdf#44286
+
+// Data from https://bugs.documentfoundation.org/show_bug.cgi?id=63230
+// https://bugs.documentfoundation.org/attachment.cgi?id=79051
 "Africa/Accra", "1800-01-01",
 "Africa/Accra", "1800-04-10",
 "Africa/Addis_Ababa", "1870-01-01",
commit 9a5f4b3b8374da48369ab71e03fbf7713ef198f9
Author: Eike Rathke 
Date:   Mon Jan 26 17:21:57 2015 +0100

add unit test for tdf#63230

All problematic dates of
https://bugs.documentfoundation.org/attachment.cgi?id=79051

Muchas gracias to Isamu Mogi!

diff --git a/svl/qa/unit/svl.cxx b/svl/qa/unit/svl.cxx
index

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Miklos Vajna]

On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood 
 wrote:
> Thanks, but that page references x86 builds for MacOSX and not x86_64.
> Is it still applicable for our 64bit OSX releases ?

Norbert, am I right that just a simple x86 -> 64bit rename is needed at
https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86,
or you use different switches?

Thanks,

Miklos


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

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Norbert Thiebaud]

On Mon, Jan 26, 2015 at 10:16 AM, Alexander Thurgood
 wrote:
> Le 26/01/2015 10:49, Miklos Vajna a écrit :
>
> Hi Miklos,
>>
>> https://wiki.documentfoundation.org/Development/ReleaseBuilds documents
>> that the gdrive flags are also used for TDF builds, so they are
>> available for the general public.
>>
>
> Thanks, but that page references x86 builds for MacOSX and not x86_64.

So?

> Is it still applicable for our 64bit OSX releases ?

why on earth not ?

(for the record the reason mac has a x qualifier on this page is to
distinguish with ppc. there is not distinction betwen the 32 and 64
bits intel setup except of course 32 vs 64 bits)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: "undefined reference to symbol 'dlclose@@GLIBC_2.2.5'"

[Norbert Thiebaud]

On Mon, Jan 26, 2015 at 11:22 AM, Miklos Vajna  wrote:
> On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood 
>  wrote:
>> Thanks, but that page references x86 builds for MacOSX and not x86_64.
>> Is it still applicable for our 64bit OSX releases ?
>
> Norbert, am I right that just a simple x86 -> 64bit rename is needed at
> https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86,
> or you use different switches?

s/x86/Intel/ should be enough. As I said the reason we mention x86 is
to distinguish with ppc... it has never been a 32/64 bits issue.

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

[Libreoffice-commits] core.git: offapi/com

[Eike Rathke]

 offapi/com/sun/star/i18n/LocaleCalendar2.idl |2 +-
 offapi/com/sun/star/i18n/XCalendar4.idl  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 92fd7a6b029e6ebad651a0e4636fa9c9229c931c
Author: Eike Rathke 
Date:   Mon Jan 26 18:43:01 2015 +0100

no hurry to publish XCalendar4 and LocaleCalendar2 now, tdf#63230

Change-Id: I05343a0c541ae2f66eedd7cc033140f810f3b1a2

diff --git a/offapi/com/sun/star/i18n/LocaleCalendar2.idl 
b/offapi/com/sun/star/i18n/LocaleCalendar2.idl
index fd878af..5b31a8d 100644
--- a/offapi/com/sun/star/i18n/LocaleCalendar2.idl
+++ b/offapi/com/sun/star/i18n/LocaleCalendar2.idl
@@ -18,7 +18,7 @@ module com { module sun { module star { module i18n {
 
 @since LibreOffice 4.5
  */
-published service LocaleCalendar2 : XCalendar4;
+service LocaleCalendar2 : XCalendar4;
 
 }; }; }; };
 
diff --git a/offapi/com/sun/star/i18n/XCalendar4.idl 
b/offapi/com/sun/star/i18n/XCalendar4.idl
index 4a1cffa..47f6d55 100644
--- a/offapi/com/sun/star/i18n/XCalendar4.idl
+++ b/offapi/com/sun/star/i18n/XCalendar4.idl
@@ -25,7 +25,7 @@ module com { module sun { module star { module i18n {
 
 @since LibreOffice 4.5
  */
-published interface XCalendar4 : com::sun::star::i18n::XCalendar3
+interface XCalendar4 : com::sun::star::i18n::XCalendar3
 {
 /** Set the local date/time as an offset to the start of the
 calendar at 1-Jan-1970 00:00. The integer part represents the
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[László Németh]

 sc/inc/address.hxx  |3 --
 sc/source/core/tool/address.cxx |   45 
 sc/source/filter/excel/xestream.cxx |   10 
 sc/source/filter/excel/xetable.cxx  |   14 ++-
 sc/source/filter/inc/xestream.hxx   |2 -
 5 files changed, 3 insertions(+), 71 deletions(-)

New commits:
commit 06c752f405ec95c85045632aa41664cc8f34d493
Author: László Németh 
Date:   Mon Jan 26 19:40:17 2015 +0100

Revert "fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX 
export"

Build problem on Android-ARM platform...

This reverts commit 0d2ce71afe0cb2657a6919e641e54c8fc9ba288c.

diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index aa05a58..06c450b 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,9 +325,6 @@ public:
 ExternalInfo* pExtInfo = NULL,
 const css::uno::Sequence* 
pExternalLinks = NULL );
 
-SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
-  const ScDocument* pDocument = NULL,
-  const Details& rDetails = detailsOOOa1) 
const;
 SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
   const ScDocument* pDocument = NULL,
   const Details& rDetails = detailsOOOa1) 
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 886b866..39fc9a4 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,51 +1745,6 @@ static OUString getFileNameFromDoc( const ScDocument* 
pDoc )
 return sFileName;
 }
 
-/** Tries to obtain a simple address without OUString/OString allocation
- *
- *  @returns TRUE at success (it is enough to call OUString Format() at FALSE)
- *
- */
-
-bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
-   const Details& rDetails) const
-{
-if( nFlags & SCA_VALID )
-nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
-if(( pDoc && (nFlags & SCA_VALID_TAB ) && ( nTab >= pDoc->GetTableCount() 
|| ( nFlags & SCA_TAB_3D ))) ||
- ! (nFlags & SCA_VALID_COL) || ! (nFlags & SCA_VALID_ROW) ||
-(nFlags & SCA_COL_ABSOLUTE) != 0 || (nFlags & SCA_ROW_ABSOLUTE) != 
0 )
-{
-   return false;
-}
-
-switch( rDetails.eConv )
-{
-default :
-// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following 
simple addresses
-case formula::FormulaGrammar::CONV_OOO:
-case formula::FormulaGrammar::CONV_XL_A1:
-case formula::FormulaGrammar::CONV_XL_OOX:
-if (nCol >= 26 * 26)
-// TODO: extend it for full column range
-return false;
-if( nCol < 26 )
-*s = 'A' + nCol;
-else
-{
-*s = 'A' + nCol / 26 - 1;
-s++;
-*s = 'A' + nCol % 26;
-}
-sprintf(s + 1, "%d", nRow + 1);
-break;
-case formula::FormulaGrammar::CONV_XL_R1C1:
-// not used in XLSX export
-return false;
-}
-return true;
-}
-
 OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details& rDetails) const
 {
diff --git a/sc/source/filter/excel/xestream.cxx 
b/sc/source/filter/excel/xestream.cxx
index 188fcd6..e5ff50c 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,11 +718,6 @@ OString XclXmlUtils::ToOString( const OUString& s )
 return OUStringToOString( s, RTL_TEXTENCODING_UTF8  );
 }
 
-bool XclXmlUtils::TryToChar( char * s, const ScAddress& rAddress )
-{
-return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1));
-}
-
 OString XclXmlUtils::ToOString( const ScAddress& rAddress )
 {
 OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1)));
@@ -765,11 +760,6 @@ static ScAddress lcl_ToAddress( const XclAddress& rAddress 
)
 return aAddress;
 }
 
-bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress& rAddress )
-{
-return TryToChar( s, lcl_ToAddress( rAddress ));
-}
-
 OString XclXmlUtils::ToOString( const XclAddress& rAddress )
 {
 return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx 
b/sc/source/filter/excel/xetable.cxx
index dd527d3..70f3373 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,11 +41,6 @@ using namespace ::oox;
 
 namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
 
-// max string length of simple addresses (eg. ABC100\0)
-#if MAXROWCOUNT_DEFINE < 999
-#define SIMPLEADDRESSLEN 11
-#endif
-
 // Helper records for cell records
 
 XclExpStringRec::XclExpStringRec( const XclExpRoot& rRoot, const OUString& 
rResult ) :
@@ -635,10 +630,9 @@ static OString lcl_GetStyleId( XclExpXml

[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - sc/inc sc/source

[László Németh]

 sc/inc/address.hxx  |3 ++
 sc/source/core/tool/address.cxx |   45 
 sc/source/filter/excel/xestream.cxx |   10 
 sc/source/filter/excel/xetable.cxx  |   14 ---
 sc/source/filter/inc/xestream.hxx   |2 +
 5 files changed, 71 insertions(+), 3 deletions(-)

New commits:
commit ace8f9c2a31795cc2329c6bb27deacde9f4c18df
Author: László Németh 
Date:   Mon Jan 26 15:45:05 2015 +0100

fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX export

Change-Id: Ie6a024463e7ee9b0f4492b2431533708a578faf0

diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index 06c450b..aa05a58 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,6 +325,9 @@ public:
 ExternalInfo* pExtInfo = NULL,
 const css::uno::Sequence* 
pExternalLinks = NULL );
 
+SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
+  const ScDocument* pDocument = NULL,
+  const Details& rDetails = detailsOOOa1) 
const;
 SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
   const ScDocument* pDocument = NULL,
   const Details& rDetails = detailsOOOa1) 
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 1efcac7..bb7a1bf 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,6 +1745,51 @@ static OUString getFileNameFromDoc( const ScDocument* 
pDoc )
 return sFileName;
 }
 
+/** Tries to obtain a simple address without OUString/OString allocation
+ *
+ *  @returns TRUE at success (it is enough to call OUString Format() at FALSE)
+ *
+ */
+
+bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
+   const Details& rDetails) const
+{
+if( nFlags & SCA_VALID )
+nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
+if(( pDoc && (nFlags & SCA_VALID_TAB ) && ( nTab >= pDoc->GetTableCount() 
|| ( nFlags & SCA_TAB_3D ))) ||
+ ! (nFlags & SCA_VALID_COL) || ! (nFlags & SCA_VALID_ROW) ||
+(nFlags & SCA_COL_ABSOLUTE) != 0 || (nFlags & SCA_ROW_ABSOLUTE) != 
0 )
+{
+   return false;
+}
+
+switch( rDetails.eConv )
+{
+default :
+// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following 
simple addresses
+case formula::FormulaGrammar::CONV_OOO:
+case formula::FormulaGrammar::CONV_XL_A1:
+case formula::FormulaGrammar::CONV_XL_OOX:
+if (nCol >= 26 * 26)
+// TODO: extend it for full column range
+return false;
+if( nCol < 26 )
+*s = 'A' + nCol;
+else
+{
+*s = 'A' + nCol / 26 - 1;
+s++;
+*s = 'A' + nCol % 26;
+}
+sprintf(s + 1, "%d", nRow + 1);
+break;
+case formula::FormulaGrammar::CONV_XL_R1C1:
+// not used in XLSX export
+return false;
+}
+return true;
+}
+
 OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details& rDetails) const
 {
diff --git a/sc/source/filter/excel/xestream.cxx 
b/sc/source/filter/excel/xestream.cxx
index e5ff50c..188fcd6 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,6 +718,11 @@ OString XclXmlUtils::ToOString( const OUString& s )
 return OUStringToOString( s, RTL_TEXTENCODING_UTF8  );
 }
 
+bool XclXmlUtils::TryToChar( char * s, const ScAddress& rAddress )
+{
+return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1));
+}
+
 OString XclXmlUtils::ToOString( const ScAddress& rAddress )
 {
 OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1)));
@@ -760,6 +765,11 @@ static ScAddress lcl_ToAddress( const XclAddress& rAddress 
)
 return aAddress;
 }
 
+bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress& rAddress )
+{
+return TryToChar( s, lcl_ToAddress( rAddress ));
+}
+
 OString XclXmlUtils::ToOString( const XclAddress& rAddress )
 {
 return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx 
b/sc/source/filter/excel/xetable.cxx
index 23adf6e..f32cdce 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,6 +41,11 @@ using namespace ::oox;
 
 namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
 
+// max string length of simple addresses (eg. ABC100\0)
+#if MAXROWCOUNT_DEFINE < 999
+#define SIMPLEADDRESSLEN 11
+#endif
+
 // Helper records for cell records
 
 XclExpStringRec::XclExpStringRec( const XclExpRoot& rRoot, const OUString& 
rResult ) :
@@ -630,9 +635,10 @@ static OString lcl_GetStyleId( XclExpXmlStream& rStrm, 
const XclExpCellBase& rCe
 
 void XclExpNumberCell::S

[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - sc/inc sc/source

[Németh László]

 sc/inc/address.hxx  |3 --
 sc/source/core/tool/address.cxx |   45 
 sc/source/filter/excel/xestream.cxx |   10 
 sc/source/filter/excel/xetable.cxx  |   14 ++-
 sc/source/filter/inc/xestream.hxx   |2 -
 5 files changed, 3 insertions(+), 71 deletions(-)

New commits:
commit 8820d21f81a9b6f89e40216f2191c019651cfe4d
Author: Németh László 
Date:   Mon Jan 26 19:13:53 2015 +

Revert "fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX 
export"

This reverts commit ace8f9c2a31795cc2329c6bb27deacde9f4c18df.

(Interestingly, reverting the original patch in the master pushed this one 
in libreoffice-4-4 automatically, sorry.)

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

diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index aa05a58..06c450b 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,9 +325,6 @@ public:
 ExternalInfo* pExtInfo = NULL,
 const css::uno::Sequence* 
pExternalLinks = NULL );
 
-SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
-  const ScDocument* pDocument = NULL,
-  const Details& rDetails = detailsOOOa1) 
const;
 SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
   const ScDocument* pDocument = NULL,
   const Details& rDetails = detailsOOOa1) 
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index bb7a1bf..1efcac7 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,51 +1745,6 @@ static OUString getFileNameFromDoc( const ScDocument* 
pDoc )
 return sFileName;
 }
 
-/** Tries to obtain a simple address without OUString/OString allocation
- *
- *  @returns TRUE at success (it is enough to call OUString Format() at FALSE)
- *
- */
-
-bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
-   const Details& rDetails) const
-{
-if( nFlags & SCA_VALID )
-nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
-if(( pDoc && (nFlags & SCA_VALID_TAB ) && ( nTab >= pDoc->GetTableCount() 
|| ( nFlags & SCA_TAB_3D ))) ||
- ! (nFlags & SCA_VALID_COL) || ! (nFlags & SCA_VALID_ROW) ||
-(nFlags & SCA_COL_ABSOLUTE) != 0 || (nFlags & SCA_ROW_ABSOLUTE) != 
0 )
-{
-   return false;
-}
-
-switch( rDetails.eConv )
-{
-default :
-// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following 
simple addresses
-case formula::FormulaGrammar::CONV_OOO:
-case formula::FormulaGrammar::CONV_XL_A1:
-case formula::FormulaGrammar::CONV_XL_OOX:
-if (nCol >= 26 * 26)
-// TODO: extend it for full column range
-return false;
-if( nCol < 26 )
-*s = 'A' + nCol;
-else
-{
-*s = 'A' + nCol / 26 - 1;
-s++;
-*s = 'A' + nCol % 26;
-}
-sprintf(s + 1, "%d", nRow + 1);
-break;
-case formula::FormulaGrammar::CONV_XL_R1C1:
-// not used in XLSX export
-return false;
-}
-return true;
-}
-
 OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details& rDetails) const
 {
diff --git a/sc/source/filter/excel/xestream.cxx 
b/sc/source/filter/excel/xestream.cxx
index 188fcd6..e5ff50c 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,11 +718,6 @@ OString XclXmlUtils::ToOString( const OUString& s )
 return OUStringToOString( s, RTL_TEXTENCODING_UTF8  );
 }
 
-bool XclXmlUtils::TryToChar( char * s, const ScAddress& rAddress )
-{
-return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1));
-}
-
 OString XclXmlUtils::ToOString( const ScAddress& rAddress )
 {
 OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details( 
FormulaGrammar::CONV_XL_A1)));
@@ -765,11 +760,6 @@ static ScAddress lcl_ToAddress( const XclAddress& rAddress 
)
 return aAddress;
 }
 
-bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress& rAddress )
-{
-return TryToChar( s, lcl_ToAddress( rAddress ));
-}
-
 OString XclXmlUtils::ToOString( const XclAddress& rAddress )
 {
 return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx 
b/sc/source/filter/excel/xetable.cxx
index f32cdce..23adf6e 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,11 +41,6 @@ using namespace ::oox;
 
 namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
 
-// max string length of simple addresses (eg. ABC100\0)

[Libreoffice-commits] dev-tools.git: cppcheck/cppcheck-report.sh

[Maarten Hoes]

 cppcheck/cppcheck-report.sh |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

New commits:
commit d7c8e6f5c3993dd3bea2dce1e983c7259f8db7c6
Author: Maarten Hoes 
Date:   Mon Jan 26 09:09:10 2015 +0100

set LANG and LC_* to fix 'UnicodeEncodeError' when running from cron.

Change-Id: Ibff06172c10a73048871f8569b083e39526828fd
Reviewed-on: https://gerrit.libreoffice.org/14181
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/cppcheck/cppcheck-report.sh b/cppcheck/cppcheck-report.sh
index 64706c4..67e8166 100755
--- a/cppcheck/cppcheck-report.sh
+++ b/cppcheck/cppcheck-report.sh
@@ -205,7 +205,22 @@ SENDEMAIL=~/source/buildbot/bin/sendEmail
 EMAIL_BODY=~/tmp/email_body
 # Dont forget to set SMTP_PWD in your ~/.cppcheckrc !
 SMTP_PWD=
-export PYTHONIOENCODING=utf-8
+export PYTHONIOENCODING=UTF-8
+
+export LANG=en_US.UTF-8
+export LC_CTYPE="en_US.UTF-8"
+export LC_NUMERIC="en_US.UTF-8"
+export LC_TIME="en_US.UTF-8"
+export LC_COLLATE="en_US.UTF-8"
+export LC_MONETARY="en_US.UTF-8"
+export LC_MESSAGES="en_US.UTF-8"
+export LC_PAPER="en_US.UTF-8"
+export LC_NAME="en_US.UTF-8"
+export LC_ADDRESS="en_US.UTF-8"
+export LC_TELEPHONE="en_US.UTF-8"
+export LC_MEASUREMENT="en_US.UTF-8"
+export LC_IDENTIFICATION="en_US.UTF-8"
+export LC_ALL=en_US.UTF-8
 
 if [ -f ~/.cppcheckrc ]; then
 # override all default vars with entries in ~/.cppcheckrc
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Stephan Bergmann]

 unotools/source/i18n/calendarwrapper.cxx |2 --
 1 file changed, 2 deletions(-)

New commits:
commit 7f003e70973a4ed31bb32adf1cac3d5a0c0b6ba9
Author: Stephan Bergmann 
Date:   Mon Jan 26 21:54:18 2015 +0100

-Werror,-Wunused-const-variable

Change-Id: I526feb77b85607438dd9816ad02e06a2c7720fc8

diff --git a/unotools/source/i18n/calendarwrapper.cxx 
b/unotools/source/i18n/calendarwrapper.cxx
index 27c1b47..2f861fb 100644
--- a/unotools/source/i18n/calendarwrapper.cxx
+++ b/unotools/source/i18n/calendarwrapper.cxx
@@ -26,8 +26,6 @@ using namespace ::com::sun::star;
 using namespace ::com::sun::star::i18n;
 using namespace ::com::sun::star::uno;
 
-const double MILLISECONDS_PER_DAY = 1000.0 * 60.0 * 60.0 * 24.0;
-
 CalendarWrapper::CalendarWrapper(
 const Reference< uno::XComponentContext > & rxContext
 )
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Caolán McNamara]

 vcl/source/gdi/pdfwriter_impl.cxx |   27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

New commits:
commit 37dc4bdbf25847c95f1668553dbae3e2dc885816
Author: Caolán McNamara 
Date:   Mon Jan 26 20:35:48 2015 +

Resolves: rhbz#1177022 no width set on space glyph with CM Typewriter fonts

Change-Id: I0dfb044b8a339fa6c473e42f31fc28c200cd03ea

diff --git a/vcl/source/gdi/pdfwriter_impl.cxx 
b/vcl/source/gdi/pdfwriter_impl.cxx
index ad79eb2..528a74c 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -3119,15 +3119,24 @@ std::map< sal_Int32, sal_Int32 > 
PDFWriterImpl::emitEmbeddedFont( const Physical
 memset( pEncToUnicodeIndex, 0, sizeof(pEncToUnicodeIndex) );
 for( Ucs2SIntMap::const_iterator it = pEncoding->begin(); it != 
pEncoding->end(); ++it )
 {
-if( it->second != -1 )
-{
-sal_Int32 nCode = (sal_Int32)(it->second & 0x00ff);
-nEncoding[ nCode ] = static_cast( nCode );
-nEncodedCodes[ nCode ] = it->first;
-pEncToUnicodeIndex[ nCode ] = 
static_cast(aUnicodes.size());
-aUnicodes.push_back( it->first );
-pUnicodesPerGlyph[ nCode ] = 1;
-}
+if(it->second == -1)
+continue;
+sal_Int32 nCode = (sal_Int32)(it->second & 0x00ff);
+//We're not doing this right here. We have taken a 
unicode-to-font_index map
+//and are trying to generate a font_index-to-unicode mapping from 
it
+//Which assumes that there is a 1-to-1 mapping there, but that 
might not be
+//true.
+//
+//Instead perhaps we could try and get the GetFontCharMap and loop
+//over sal_UCS4 GetCharFromIndex( int nCharIndex ) const from 0 to 
255
+//to build it up
+if (nEncodedCodes[nCode] != 0)
+continue;
+nEncodedCodes[ nCode ] = it->first;
+nEncoding[ nCode ] = static_cast( nCode );
+pEncToUnicodeIndex[ nCode ] = 
static_cast(aUnicodes.size());
+aUnicodes.push_back( it->first );
+pUnicodesPerGlyph[ nCode ] = 1;
 }
 }
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

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

[Stephan Bergmann]

 svl/qa/unit/svl.cxx |  994 ++--
 1 file changed, 497 insertions(+), 497 deletions(-)

New commits:
commit 6744fe62973edbc2a4108905192fce4b2854ac39
Author: Stephan Bergmann 
Date:   Mon Jan 26 22:25:03 2015 +0100

-Werror,-Wmissing-braces

Change-Id: I86f9b9ada62687e8159497bf428e18be1442c8a6

diff --git a/svl/qa/unit/svl.cxx b/svl/qa/unit/svl.cxx
index 76c3f3f..b65460d 100644
--- a/svl/qa/unit/svl.cxx
+++ b/svl/qa/unit/svl.cxx
@@ -491,506 +491,506 @@ void Test::testI116701()
 void Test::testDateInput()
 {
 const char* aData[][2] = {
-"Europe/Paris", "1938-10-07",   // i#76623
-"Europe/Moscow", "1919-07-01",  // i#86094
-"Europe/Tallinn", "1790-03-01", // i#105864
-"Australia/Perth", "2004-04-11",// i#17222
-"America/Sao_Paulo", "1902-04-22",  // tdf#44286
-"Europe/Berlin", "1790-07-27",
-"US/Mountain", "1790-07-26",
+{ "Europe/Paris", "1938-10-07" },  // i#76623
+{ "Europe/Moscow", "1919-07-01" }, // i#86094
+{ "Europe/Tallinn", "1790-03-01" },// i#105864
+{ "Australia/Perth", "2004-04-11" },   // i#17222
+{ "America/Sao_Paulo", "1902-04-22" }, // tdf#44286
+{ "Europe/Berlin", "1790-07-27" },
+{ "US/Mountain", "1790-07-26" },
 
 // Data from https://bugs.documentfoundation.org/show_bug.cgi?id=63230
 // https://bugs.documentfoundation.org/attachment.cgi?id=79051
-"Africa/Accra", "1800-01-01",
-"Africa/Accra", "1800-04-10",
-"Africa/Addis_Ababa", "1870-01-01",
-"Africa/Addis_Ababa", "1936-05-05",
-"Africa/Algiers", "1956-01-29",
-"Africa/Algiers", "1981-05-01",
-"Africa/Asmara", "1936-05-05",
-"Africa/Asmera", "1936-05-05",
-"Africa/Bujumbura", "1890-01-01",
-"Africa/Casablanca", "1984-03-16",
-"Africa/Ceuta", "1984-03-16",
-"Africa/Dar_es_Salaam", "1931-01-01",
-"Africa/Dar_es_Salaam", "1961-01-01",
-"Africa/Djibouti", "1911-07-01",
-"Africa/Douala", "1912-01-01",
-"Africa/El_Aaiun", "1934-01-01",
-"Africa/Freetown", "1913-06-01",
-"Africa/Gaborone", "1885-01-01",
-"Africa/Johannesburg", "1903-03-01",
-"Africa/Kampala", "1928-07-01",
-"Africa/Kampala", "1948-01-01",
-"Africa/Kampala", "1957-01-01",
-"Africa/Lagos", "1919-09-01",
-"Africa/Libreville", "1912-01-01",
-"Africa/Luanda", "1911-05-26",
-"Africa/Lubumbashi", "1897-11-09",
-"Africa/Lusaka", "1903-03-01",
-"Africa/Malabo", "1963-12-15",
-"Africa/Maseru", "1903-03-01",
-"Africa/Mogadishu", "1957-01-01",
-"Africa/Monrovia", "1919-03-01",
-"Africa/Nairobi", "1928-07-01",
-"Africa/Nairobi", "1940-01-01",
-"Africa/Nairobi", "1960-01-01",
-"Africa/Niamey", "1960-01-01",
-"Africa/Porto-Novo", "1934-02-26",
-"Africa/Tripoli", "1920-01-01",
-"Africa/Tripoli", "1959-01-01",
-"Africa/Tripoli", "1990-05-04",
-"Africa/Tunis", "1911-03-11",
-"Africa/Windhoek", "1892-02-08",
-"Africa/Windhoek", "1903-03-01",
-"America/Antigua", "1912-03-02",
-"America/Argentina/Buenos_Aires", "1894-10-31",
-"America/Argentina/Catamarca", "1991-10-20",
-"America/Argentina/Catamarca", "2004-06-01",
-"America/Argentina/ComodRivadavia", "1991-10-20",
-"America/Argentina/ComodRivadavia", "2004-06-01",
-"America/Argentina/Cordoba", "1991-10-20",
-"America/Argentina/Jujuy", "1991-10-06",
-"America/Argentina/La_Rioja", "2004-06-01",
-"America/Argentina/Mendoza", "1992-10-18",
-"America/Argentina/Mendoza", "2004-05-23",
-"America/Argentina/Rio_Gallegos", "2004-06-01",
-"America/Argentina/Salta", "1991-10-20",
-"America/Argentina/San_Juan", "2004-05-31",
-"America/Argentina/San_Luis", "2004-05-31",
-"America/Argentina/San_Luis", "2008-01-21",
-"America/Argentina/Tucuman", "1991-10-20",
-"America/Argentina/Tucuman", "2004-06-01",
-"America/Argentina/Ushuaia", "2004-05-30",
-"America/Asuncion", "1931-10-10",
-"America/Asuncion", "1974-04-01",
-"America/Bahia", "1914-01-01",
-"America/Bahia_Banderas", "1930-11-15",
-"America/Bahia_Banderas", "1931-10-01",
-"America/Bahia_Banderas", "1942-04-24",
-"America/Bahia_Banderas", "1949-01-14",
-"America/Barbados", "1932-01-01",
-"America/Belize", "1912-04-01",
-"America/Blanc-Sablon", "1884-01-01",
-"America/Bogota", "1914-11-23",
-"America/Buenos_Aires", "1894-10-31",
-"America/Cambridge_Bay", "2000-11-05",
-"America/Campo_Grande", "1914-01-01",
-"America/Caracas", "1912-02-12",
-"America/Catamarca", "1991-10-20",
-"America

feature/barcode feedback sought ...

[Michael Meeks]

Hi guys,

So - I just checked some initial QR code integration into the
feature/barcode branch; it sort of works ;-) but it raises a number of
interesting questions and/or opportunities; and I'd love some quick
directional input from someone clueful =)

First - what is it so far:

* I hacked an existing smiley to add the (existing but
  apparently un-used / buggy) custom draw:engine pieces thus:


...


It -looks- like this code was intended to add a rather sexy extension
point for custom shapes via the drawing::XCustomShapeEngine IDL file.
Usually I love to hate UNO - but in this case it looks like what could
be possible there is rather sexy.

My -hope- is that this with minimal tweaking would allow me to have
arbitrary python plugins rendering interesting document content - and
also serializing their rendered state as an OLE-style preview to the
XML.

Of course - I'd love to have some feedback on my sanity - quite
possibly this is utterly crazy; quite possibly there are 3x easier &
better ways to achieve the same thing (?) =)

Known problems:

* for QR codes (but prolly not bar-codes) the idea of
  representing a bitmap as a ton of polypolygons is prolly
  not the greatest idea.
+ but while you can put arbitrary XShape's in there
  I suspect serializing that into an attribute is
  unlikely to work well.

* no UI yet you need to

* script-ability - I guess we'd want some field / data-driven
  / easy-automation magic:
+ would this work better as a field ?
+ how about as a general draw shape (the svx draw shapes
  seem pretty horrible).

* bar-code specifications:
+ some of the spec's are a bit strict: "no less
  than 2mm between X and Y"
+ that gives some UI / rendering / unit constraints
+ currently not captured.

* zint
+ software quality appears to be dire
+ hint if you are conditionally replacing
  malloc with "alloca" on some platforms
  with no other associated changes - something
  is wrong.
+ horribly un-maintained: pick the best of at least 3x
  under-loved forks.
  http://users.freedesktop.org/~michael/zint.tar.bz2
  has a snapshot. 
+ at least it renders more kinds of bar-codes than
  is sensible

Known bugs:

* ODF / back-compatibility - we re-export the original (in my
  case smiley) custom-shape which shows up as an unhelpful
  fallback for older LibreOffice'n.

* zint is sufficiently bad & closely tied to layout / text
  rendering etc. it's prolly easier to re-write

* no system-zint: we're internal / static only - and this is not
  a good idea; but I'll list it here anyway for completeness.

I have a blog entry with obligatory screenshot here:

https://people.gnome.org/~michael/blog/2015-01-25.html

I'd love to have some clue on how best to fiddle with this / re-work it
somewhere that it fits.

And yes I have seen this plugin:

http://extensions.openoffice.org/en/project/qr-code-generator

which appears to use some google web plugin to render bitmaps
remotely ;-) not great if they contain confidential data etc.

Thanks !

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot


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

[Bug 88205] Adapt uses of css::uno::Sequence to use initializer_list ctor

[bugzilla-daemon]

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

Michael Meeks  changed:

   What|Removed |Added

 CC||michael.me...@collabora.com

--- Comment #1 from Michael Meeks  ---
As Stephan says that's really great for the getSupportedServiceNames cases: a
quick:

$ git grep -5 getSupportedServiceNames

shows you a load of these places (when you get through accessibility) where we
can turn two or often three lines into one like this:

 css::uno::Sequence< OUString >
 BridgeFactory::static_getSupportedServiceNames() {
-OUString name("com.sun.star.bridge.BridgeFactory");
-return css::uno::Sequence< OUString >(&name, 1);
+return css::uno::Sequence{ "com.sun.star.bridge.BridgeFactory"
};
 }

Then again - it's not clear to me that this wouldn't produce rather more
efficient code with a var-arg method that took C strings =) but at least far
more terse.

Thanks !

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

[Bug 88205] Adapt uses of css::uno::Sequence to use initializer_list ctor

[bugzilla-daemon]

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

Michael Meeks  changed:

   What|Removed |Added

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

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

[Libreoffice-commits] core.git: formula/source include/formula sc/inc sc/qa sc/source

[Winfried Donkers]

 formula/source/core/resource/core_resource.src |7 
 include/formula/compiler.hrc   |3 +
 include/formula/opcode.hxx |1 
 sc/inc/helpids.h   |1 
 sc/qa/unit/ucalc.cxx   |1 
 sc/source/core/inc/interpre.hxx|1 
 sc/source/core/tool/interpr4.cxx   |1 
 sc/source/core/tool/interpr7.cxx   |   38 +
 sc/source/filter/excel/xlformula.cxx   |2 -
 sc/source/filter/oox/formulabase.cxx   |2 -
 sc/source/ui/src/scfuncs.src   |   23 +++
 11 files changed, 77 insertions(+), 3 deletions(-)

New commits:
commit 25434372bf56e0ebdb7e7d47ab3c14c68211509f
Author: Winfried Donkers 
Date:   Mon Dec 15 09:45:26 2014 +0100

fdo#76870 Add support for Excel2013 function ENCODEURL

Change-Id: I369bcd58055364757b6a098fc3aa0c0065c79b67
Reviewed-on: https://gerrit.libreoffice.org/13478
Reviewed-by: Eike Rathke 
Tested-by: Eike Rathke 

diff --git a/formula/source/core/resource/core_resource.src 
b/formula/source/core/resource/core_resource.src
index 1e9c312..2f3f2bc 100644
--- a/formula/source/core/resource/core_resource.src
+++ b/formula/source/core/resource/core_resource.src
@@ -427,6 +427,7 @@ Resource RID_STRLIST_FUNCTION_NAMES_ENGLISH_ODFF
 String SC_OPCODE_COLOR { Text = "ORG.LIBREOFFICE.COLOR"; };
 String SC_OPCODE_ERF_MS { Text = "COM.MICROSOFT.ERF.PRECISE" ; };
 String SC_OPCODE_ERFC_MS { Text = "COM.MICROSOFT.ERFC.PRECISE" ; };
+String SC_OPCODE_ENCODEURL { Text = "COM.MICROSOFT.ENCODEURL"; };
 };
 
 /** These function names are used only in the XLSX import. */
@@ -835,6 +836,7 @@ Resource RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML
 String SC_OPCODE_COLOR { Text = "_xlfn.ORG.LIBREOFFICE.COLOR"; };
 String SC_OPCODE_ERF_MS { Text = "_xlfn.ERF.PRECISE" ; };
 String SC_OPCODE_ERFC_MS { Text = "_xlfn.ERFC.PRECISE" ; };
+String SC_OPCODE_ENCODEURL { Text = "_xlfn.ENCODEURL"; };
 };
 
 // DO NOT CHANGE NAMES! Only add functions.
@@ -1245,6 +1247,7 @@ Resource RID_STRLIST_FUNCTION_NAMES_ENGLISH
 String SC_OPCODE_COLOR { Text = "COLOR"; };
 String SC_OPCODE_ERF_MS { Text = "ERF.PRECISE" ; };
 String SC_OPCODE_ERFC_MS { Text = "ERFC.PRECISE" ; };
+String SC_OPCODE_ENCODEURL { Text = "ENCODEURL"; };
 };
 
 Resource RID_STRLIST_FUNCTION_NAMES
@@ -2793,6 +2796,10 @@ Resource RID_STRLIST_FUNCTION_NAMES
 {
 Text [en-US ] = "ERFC.PRECISE" ;
 };
+String SC_OPCODE_ENCODEURL
+{
+Text [ en-US ] = "ENCODEURL";
+};
 };
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/include/formula/compiler.hrc b/include/formula/compiler.hrc
index 2d2dd36..dbbea90 100644
--- a/include/formula/compiler.hrc
+++ b/include/formula/compiler.hrc
@@ -195,7 +195,8 @@
 #define SC_OPCODE_ERF_MS163
 #define SC_OPCODE_ERFC_MS   164
 #define SC_OPCODE_ERROR_TYPE_ODF165
-#define SC_OPCODE_STOP_1_PAR166
+#define SC_OPCODE_ENCODEURL 166
+#define SC_OPCODE_STOP_1_PAR167
 
 /*** Functions with more than one parameters ***/
 #define SC_OPCODE_START_2_PAR   201
diff --git a/include/formula/opcode.hxx b/include/formula/opcode.hxx
index a282dae..3a2af3a 100644
--- a/include/formula/opcode.hxx
+++ b/include/formula/opcode.hxx
@@ -465,6 +465,7 @@ enum OpCode : sal_uInt16
 ocColor = SC_OPCODE_COLOR,
 ocErf_MS= SC_OPCODE_ERF_MS,
 ocErfc_MS   = SC_OPCODE_ERFC_MS,
+ocEncodeURL = SC_OPCODE_ENCODEURL,
 // internal stuff
 ocInternalBegin = SC_OPCODE_INTERNAL_BEGIN,
 ocTTT   = SC_OPCODE_TTT,
diff --git a/sc/inc/helpids.h b/sc/inc/helpids.h
index 9768806..574afb0 100644
--- a/sc/inc/helpids.h
+++ b/sc/inc/helpids.h
@@ -563,6 +563,7 @@
 #define HID_FUNC_BITRSHIFT  
"SC_HID_FUNC_BITRSHIFT"
 #define HID_FUNC_FILTERXML  
"SC_HID_FUNC_FILTERXML"
 #define HID_FUNC_WEBSERVICE 
"SC_HID_FUNC_WEBSERVICE"
+#define HID_FUNC_ENCODEURL  
"SC_HID_FUNC_ENCODEURL"
 #define HID_FUNC_COLOR  
"SC_HID_FUNC_COLOR"
 #define HID_FUNC_COVARIANCE_P   
"SC_HID_FUNC_COVARIANCE_P"
 #define HID_FUNC_COVARIANCE_S   
"SC_HID_FUNC_COVARIANCE_S"
diff --git a/sc/qa/unit/ucalc.cxx b/sc/qa/unit/ucalc.cxx
index eb4454f..b839816 100644
--- a/sc/qa/unit/ucalc.cxx
+++ b/sc/qa/unit/ucalc.cxx
@@ -2669,6 +2669,7 @@ void Test::testFunctionLists()
 "CONCATENATE",
 "DECIMAL",
 "DOLLAR",
+"ENCODEURL",
 "EXACT",
 "FILTERXML",
 "FIND",
diff --git a/sc/source/core/inc/interpre.hxx b/sc/source/core/inc

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

[Eike Rathke]

 sc/source/core/tool/interpr7.cxx |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

New commits:
commit 9266abdb548ce99ebd891080fa263e930c5234e1
Author: Eike Rathke 
Date:   Mon Jan 26 23:13:46 2015 +0100

operate on UTF-8 encoded string, tdf#76870 follow-up

Change-Id: I00088a34a41f8adc4204f490fedee434c96bac67

diff --git a/sc/source/core/tool/interpr7.cxx b/sc/source/core/tool/interpr7.cxx
index a4a8f60..ce69848 100644
--- a/sc/source/core/tool/interpr7.cxx
+++ b/sc/source/core/tool/interpr7.cxx
@@ -225,16 +225,18 @@ void ScInterpreter::ScEncodeURL()
 return;
 }
 
-OStringBuffer aUrlBuf;
-for ( int i = 0; i < aStr.getLength(); i++ )
+OString aUtf8Str( aStr.toUtf8());
+const sal_Int32 nLen = aUtf8Str.getLength();
+OStringBuffer aUrlBuf( nLen );;
+for ( int i = 0; i < nLen; i++ )
 {
-sal_Unicode c = aStr[ i ];
-if ( rtl::isAsciiAlphanumeric( c ) || c == '-' || c == '_' )
-aUrlBuf.append( static_cast( c ) );
+sal_Char c = aUtf8Str[ i ];
+if ( rtl::isAsciiAlphanumeric( static_cast( c ) ) || c 
== '-' || c == '_' )
+aUrlBuf.append( c );
 else
 {
 aUrlBuf.append( '%' );
-aUrlBuf.append( OString::number( static_cast( c ), 
16 ).toAsciiUpperCase() );
+aUrlBuf.append( OString::number( static_cast( c ), 
16 ).toAsciiUpperCase() );
 }
 }
 PushString( OUString::fromUtf8( aUrlBuf.makeStringAndClear() ) );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: feature/barcode feedback sought ...

[Thorsten Behrens]

Michael Meeks wrote:
>   My -hope- is that this with minimal tweaking would allow me to have
> arbitrary python plugins rendering interesting document content -
>
Yep

> and also serializing their rendered state as an OLE-style preview to
> the XML.
> 
Maybe not that easily. And are you storing the original bits (that
then get rendered into QR) somewhere already?

>   Of course - I'd love to have some feedback on my sanity - quite
> possibly this is utterly crazy; quite possibly there are 3x easier &
> better ways to achieve the same thing (?) =)
> 
Yeah, why not sticking in a png or an svg directly into the document?

>   Known problems:
> 
>   * for QR codes (but prolly not bar-codes) the idea of
> representing a bitmap as a ton of polypolygons is prolly
> not the greatest idea.
>
But also not prohibitively expensive - or how large are those QR codes
getting these days? Your example seems 40x40 pixel.

>   * bar-code specifications:
>   + some of the spec's are a bit strict: "no less
> than 2mm between X and Y"
>   + that gives some UI / rendering / unit constraints
>   + currently not captured.
> 
Lock resizing on the XShape?

>   Known bugs:
> 
>   * ODF / back-compatibility - we re-export the original (in my
> case smiley) custom-shape which shows up as an unhelpful
> fallback for older LibreOffice'n.
> 
That one is a bummer. You'd want to add a preview image into some
wrapped draw frame then (like e.g. the svg import did it).

>   I'd love to have some clue on how best to fiddle with this /
> re-work it somewhere that it fits.
> 
See above - I might miss the broader picture, but I think easiest
would be direct embedding of the graphic. Would also solve your bitmap
question.

Cheers,

-- Thorsten


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

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

[Markus Mohrhard]

 connectivity/source/drivers/ado/ADriver.cxx |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

New commits:
commit 19669b2c2d77ddf5d7a07a655ca21d0557e7d603
Author: Markus Mohrhard 
Date:   Sun Jan 25 10:29:49 2015 +0100

fix memory leak when exception is thrown

Change-Id: Ie9702da32f27134f0c2c263fcded417c51a17b2a
Reviewed-on: https://gerrit.libreoffice.org/14167
Tested-by: Jenkins 
Tested-by: Markus Mohrhard 
Reviewed-by: Markus Mohrhard 

diff --git a/connectivity/source/drivers/ado/ADriver.cxx 
b/connectivity/source/drivers/ado/ADriver.cxx
index 69f38d8..3b9907d 100644
--- a/connectivity/source/drivers/ado/ADriver.cxx
+++ b/connectivity/source/drivers/ado/ADriver.cxx
@@ -31,6 +31,8 @@
 
 #include "resource/sharedresources.hxx"
 
+#include 
+
 using namespace connectivity;
 using namespace connectivity::ado;
 using namespace com::sun::star::uno;
@@ -118,10 +120,12 @@ Reference< XConnection > SAL_CALL ODriver::connect( const 
OUString& url, const S
 if ( ! acceptsURL(url) )
 return NULL;
 
-OConnection* pCon = new OConnection(this);
+// we need to wrap the connection as the construct call might throw
+std::unique_ptr pCon(new OConnection(this));
 pCon->construct(url,info);
-Reference< XConnection > xCon = pCon;
-m_xConnections.push_back(WeakReferenceHelper(*pCon));
+OConnection* pPtr = pCon.get();
+Reference< XConnection > xCon = pCon.release();
+m_xConnections.push_back(WeakReferenceHelper(*pPtr));
 
 return xCon;
 }
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: Branch 'feature/orcus-continuous-integration' - 4 commits - sc/source

[Markus Mohrhard]

 sc/source/filter/inc/orcusinterface.hxx |   54 ++
 sc/source/filter/orcus/interface.cxx|  116 
 2 files changed, 169 insertions(+), 1 deletion(-)

New commits:
commit 7833cf026fe2cc740397e9805a0fb7a79a8c42c5
Author: Markus Mohrhard 
Date:   Tue Jan 27 04:31:56 2015 +0100

initial work for conditional formatting import for orcus

Change-Id: If79f58c44072b7c2c20fc2026b2a6eed6d202b63

diff --git a/sc/source/filter/inc/orcusinterface.hxx 
b/sc/source/filter/inc/orcusinterface.hxx
index f997446..e245b08 100644
--- a/sc/source/filter/inc/orcusinterface.hxx
+++ b/sc/source/filter/inc/orcusinterface.hxx
@@ -79,6 +79,52 @@ public:
 virtual size_t commit_segments() SAL_OVERRIDE;
 };
 
+class ScOrcusConditionalFormat : public 
orcus::spreadsheet::iface::import_conditional_format
+{
+public:
+ScOrcusConditionalFormat(SCTAB nTab, ScDocument& rDoc);
+virtual ~ScOrcusConditionalFormat();
+
+virtual void set_color(orcus::spreadsheet::color_elem_t alpha, 
orcus::spreadsheet::color_elem_t red,
+orcus::spreadsheet::color_elem_t green, 
orcus::spreadsheet::color_elem_t blue) SAL_OVERRIDE;
+
+virtual void set_formula(const char* p, size_t n) SAL_OVERRIDE;
+
+virtual void set_condition_type(orcus::spreadsheet::condition_type_t type) 
SAL_OVERRIDE;
+
+virtual void set_date(orcus::spreadsheet::condition_date_type date) 
SAL_OVERRIDE;
+
+virtual void commit_condition() SAL_OVERRIDE;
+
+virtual void set_icon_name(const char* p, size_t n) SAL_OVERRIDE;
+
+virtual void set_databar_gradient(bool gradient) SAL_OVERRIDE;
+
+virtual void set_databar_axis(orcus::spreadsheet::databar_axis_t axis) 
SAL_OVERRIDE;
+
+virtual void set_show_value(bool show) SAL_OVERRIDE;
+
+virtual void set_xf_id(size_t xf) SAL_OVERRIDE;
+
+virtual void set_operator(orcus::spreadsheet::condition_operator_t 
condition_type) SAL_OVERRIDE;
+
+virtual void set_type(orcus::spreadsheet::conditional_format_t type) 
SAL_OVERRIDE;
+
+virtual void commit_entry() SAL_OVERRIDE;
+
+virtual void set_range(const char* p, size_t n) SAL_OVERRIDE;
+
+virtual void set_range(orcus::spreadsheet::row_t row_start, 
orcus::spreadsheet::col_t col_start,
+orcus::spreadsheet::row_t row_end, orcus::spreadsheet::col_t 
col_end) SAL_OVERRIDE;
+
+virtual void commit_format() SAL_OVERRIDE;
+
+private:
+
+SCTAB mnTab;
+ScDocument& mrDoc;
+};
+
 class ScOrcusAutoFilter : public orcus::spreadsheet::iface::import_auto_filter
 {
 public:
@@ -130,6 +176,7 @@ class ScOrcusSheet : public 
orcus::spreadsheet::iface::import_sheet
 sc::SharedFormulaGroups maFormulaGroups;
 ScOrcusAutoFilter maAutoFilter;
 ScOrcusSheetProperties maProperties;
+ScOrcusConditionalFormat maConditionalFormat;
 
 typedef std::map SharedFormulaContainer;
 SharedFormulaContainer maSharedFormulas;
@@ -144,6 +191,7 @@ public:
 virtual orcus::spreadsheet::iface::import_auto_filter* get_auto_filter() 
SAL_OVERRIDE { return &maAutoFilter; }
 virtual orcus::spreadsheet::iface::import_sheet_properties* 
get_sheet_properties() SAL_OVERRIDE;
 virtual orcus::spreadsheet::iface::import_table* get_table() SAL_OVERRIDE;
+virtual orcus::spreadsheet::iface::import_conditional_format* 
get_conditional_format() SAL_OVERRIDE;
 
 // Orcus import interface
 virtual void set_auto(orcus::spreadsheet::row_t row, 
orcus::spreadsheet::col_t col, const char* p, size_t n) SAL_OVERRIDE;
diff --git a/sc/source/filter/orcus/interface.cxx 
b/sc/source/filter/orcus/interface.cxx
index 8655246..e71b967 100644
--- a/sc/source/filter/orcus/interface.cxx
+++ b/sc/source/filter/orcus/interface.cxx
@@ -282,6 +282,98 @@ void ScOrcusSheetProperties::set_merge_cell_range(const 
char* /*p_range*/, size_
 {
 }
 
+ScOrcusConditionalFormat::ScOrcusConditionalFormat(SCTAB nTab, ScDocument& 
rDoc):
+mnTab(nTab),
+mrDoc(rDoc)
+{
+}
+
+ScOrcusConditionalFormat::~ScOrcusConditionalFormat()
+{
+}
+
+void ScOrcusConditionalFormat::set_color(os::color_elem_t /*alpha*/, 
os::color_elem_t /*red*/,
+os::color_elem_t /*green*/, os::color_elem_t /*blue*/)
+{
+SAL_INFO("sc.orcus.condformat", "set_color");
+}
+
+void ScOrcusConditionalFormat::set_condition_type(os::condition_type_t 
/*type*/)
+{
+SAL_INFO("sc.orcus.condformat", "set_condition_type");
+}
+
+void ScOrcusConditionalFormat::set_formula(const char* /*p*/, size_t /*n*/)
+{
+SAL_INFO("sc.orcus.condformat", "set_formula");
+}
+
+void ScOrcusConditionalFormat::set_date(os::condition_date_type /*date*/)
+{
+SAL_INFO("sc.orcus.condformat", "set_date");
+}
+
+void ScOrcusConditionalFormat::commit_condition()
+{
+SAL_INFO("sc.orcus.condformat", "commit_condition");
+}
+
+void ScOrcusConditionalFormat::set_icon_name(const char* /*p*/, size_t /*n*/)
+{
+SAL_INFO("sc.orcus.condformat", "set_icon_name");
+}
+
+void ScOrcusConditionalFormat::set_databar_gradient(bool /*gradient*/)
+{
+