date:20110909

Hi Cor,

On Friday, 2011-09-09 10:26:05 +0200, Cor Nouws wrote:

 Start spreadsheet
 type 8 or so
   position is to heigh

I assume this is due to
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3364fefe1e2dec522211040f2f9ea37bf5cd7466

AFAIK Kohei is doing some work to adapt default row heights in Calc.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


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

Re: [Libreoffice] master: position to heigh while typing data in a cell

2011-09-09 Thread Caolán McNamara

On Fri, 2011-09-09 at 15:54 +0200, Eike Rathke wrote:
 Hi Cor,
 
 On Friday, 2011-09-09 10:26:05 +0200, Cor Nouws wrote:
 
  Start spreadsheet
  type 8 or so
position is to heigh
 
 I assume this is due to
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=3364fefe1e2dec522211040f2f9ea37bf5cd7466

I think this is probably a bad idea to leave in as default for now,
might be a better idea to wrap the new rules inside the experimental
flag or behind a getenv or something.

C.

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

[Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

2011-09-09 Thread Peter Foley


I've attached an updated patch to convert Mesa to gbuild and add it to 
tail_build. I've tested it with SYSTEM_MESA_HEADERS YES and NO.

PeterFrom af6ae8a30ebea0f86ec2cb33bb94500cfbd3e027 Mon Sep 17 00:00:00 2001
From: Peter Foley pefol...@verizon.net
Date: Thu, 8 Sep 2011 20:48:59 -0400
Subject: [PATCH] convert Mesa to gbuild and add to tail_build

---
 Mesa/Makefile |   38 ++
 Mesa/Module_Mesa.mk   |   35 +++
 Mesa/Package_inc.mk   |   40 
 Mesa/prj/build.lst|5 ++---
 Mesa/prj/d.lst|3 ---
 Mesa/prj/makefile.mk  |   40 
 Module_tail_build.mk  |1 +
 RepositoryExternal.mk |   13 +
 RepositoryModule_ooo.mk   |1 +
 slideshow/Library_OGLTrans.mk |4 
 solenv/gbuild/LinkTarget.mk   |4 
 tail_build/prj/build.lst  |2 +-
 12 files changed, 179 insertions(+), 7 deletions(-)
 create mode 100644 Mesa/Makefile
 create mode 100644 Mesa/Module_Mesa.mk
 create mode 100644 Mesa/Package_inc.mk
 delete mode 100644 Mesa/prj/d.lst
 create mode 100644 Mesa/prj/makefile.mk

diff --git a/Mesa/Makefile b/Mesa/Makefile
new file mode 100644
index 000..90947b2
--- /dev/null
+++ b/Mesa/Makefile
@@ -0,0 +1,38 @@
+#*
+#
+# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+# 
+# Copyright 2000, 2011 Oracle and/or its affiliates.
+#
+# OpenOffice.org - a multi-platform office productivity suite
+#
+# This file is part of OpenOffice.org.
+#
+# OpenOffice.org is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License version 3
+# only, as published by the Free Software Foundation.
+#
+# OpenOffice.org is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Lesser General Public License version 3 for more details
+# (a copy is included in the LICENSE file that accompanied this code).
+#
+# You should have received a copy of the GNU Lesser General Public License
+# version 3 along with OpenOffice.org.  If not, see
+# http://www.openoffice.org/license.html
+# for a copy of the LGPLv3 License.
+#
+#*
+
+ifeq ($(strip $(SOLARENV)),)
+$(error No environment set!)
+endif
+
+gb_PARTIALBUILD := T
+GBUILDDIR := $(SOLARENV)/gbuild
+include $(GBUILDDIR)/gbuild.mk
+
+$(eval $(call gb_Module_make_global_targets,$(shell ls $(dir $(realpath 
$(firstword $(MAKEFILE_LIST/Module*.mk)))
+
+# vim: set noet sw=4 ts=4:
diff --git a/Mesa/Module_Mesa.mk b/Mesa/Module_Mesa.mk
new file mode 100644
index 000..fc70e59
--- /dev/null
+++ b/Mesa/Module_Mesa.mk
@@ -0,0 +1,35 @@
+#
+#  Version: MPL 1.1 / GPLv3+ / LGPLv3+
+#
+#  The contents of this file are subject to the Mozilla Public License Version
+#  1.1 (the License); you may not use this file except in compliance with
+#  the License or as specified alternatively below. You may obtain a copy of
+#  the License at http://www.mozilla.org/MPL/
+#
+#  Software distributed under the License is distributed on an AS IS basis,
+#  WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+#  for the specific language governing rights and limitations under the
+#  License.
+#
+#  Major Contributor(s):
+#  Copyright (C) 2011 Peter Foley pefol...@verizon.net (initial developer)
+#
+#  All Rights Reserved.
+#
+#  For minor contributions see the git repository.
+#
+#  Alternatively, the contents of this file may be used under the terms of
+#  either the GNU General Public License Version 3 or later (the GPLv3+), or
+#  the GNU Lesser General Public License Version 3 or later (the LGPLv3+),
+#  in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
+#  instead of those above.
+
+$(eval $(call gb_Module_Module,Mesa))
+
+ifeq ($(SYSTEM_MESA_HEADERS),NO)
+
+$(eval $(call gb_Module_add_targets,Mesa,Package_inc))
+
+endif
+
+# vim: set noet sw=4:
diff --git a/Mesa/Package_inc.mk b/Mesa/Package_inc.mk
new file mode 100644
index 000..e9e215b
--- /dev/null
+++ b/Mesa/Package_inc.mk
@@ -0,0 +1,40 @@
+#
+# Version: MPL 1.1 / GPLv3+ / LGPLv3+
+#
+#  The contents of this file are subject to the Mozilla Public License Version
+#  1.1 (the License); you may not use this file except in compliance with
+#  the License or as specified alternatively below. You may obtain a copy of
+#  the License at http://www.mozilla.org/MPL/
+#
+#  Software distributed under the License is distributed on an AS IS basis,
+#  WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+#  for the specific language governing rights and limitations under the
+#  License.
+#
+#

Re: [Libreoffice] master: position to heigh while typing data in a cell

Hi Caolán,

On Friday, 2011-09-09 16:00:20 +0100, Caolán McNamara wrote:

   Start spreadsheet
   type 8 or so
 position is to heigh
  
  I assume this is due to
  http://cgit.freedesktop.org/libreoffice/core/commit/?id=3364fefe1e2dec522211040f2f9ea37bf5cd7466
 
 I think this is probably a bad idea to leave in as default for now,
 might be a better idea to wrap the new rules inside the experimental
 flag or behind a getenv or something.

Yup, I'll do that.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

On Fri, Sep 9, 2011 at 10:09 AM, Peter Foley pefol...@verizon.net wrote:

 I've attached an updated patch to convert Mesa to gbuild and add it to
 tail_build. I've tested it with SYSTEM_MESA_HEADERS YES and NO.

diff --git a/Mesa/prj/d.lst b/Mesa/prj/d.lst
deleted file mode 100644
index 9690bd4..000
--- a/Mesa/prj/d.lst
+++ /dev/null
@@ -1,3 +0,0 @@
-mkdir: %_DEST%\inc\GL
-
-..\inc\*.h %_DEST%\inc\GL\*.h

That is wrong.. you need to keep an empty d.lst or Mesa won't be able
to be built independently, via build
iow cd Mesa; build --all will fail.

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

Re: [Libreoffice] master: position to heigh while typing data in a cell

2011-09-09 Thread Cor Nouws


Eike Rathke wrote (09-09-11 15:54)

I assume this is due to
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3364fefe1e2dec522211040f2f9ea37bf5cd7466

AFAIK Kohei is doing some work to adapt default row heights in Calc.


That's what swiftly passed my mind too.
So experimental or not - might be good to fix ;-)

--
 - Cor
 - http://nl.libreoffice.org

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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

diff --git a/slideshow/Library_OGLTrans.mk b/slideshow/Library_OGLTrans.mk
index f3dd316..9e31c16 100644
--- a/slideshow/Library_OGLTrans.mk
+++ b/slideshow/Library_OGLTrans.mk
@@ -63,6 +63,10 @@ $(eval $(call gb_Library_add_linked_libs,OGLTrans,\
 $(gb_STDLIBS) \
 ))

+ifeq ($(SYSTEM_MESA_HEADERS),NO)
+$(eval $(call gb_Library_use_external,OGLTrans,Mesa))
+endif
+

that is unnecessary. because

--- a/RepositoryExternal.mk
+++ b/RepositoryExternal.mk
@@ -36,6 +36,19 @@
 # in the system case, no libraries should be registered, but the target-local
 # variable LIBS should be set to FOO_LIBS, and INCLUDES to FOO_CFLAGS.

+ifeq ($(SYSTEM_MESA_HEADERS),YES)
+
+gb_LinkTarget__use_Mesa:=
+
+else
+
+define gb_LinkTarget__use_Mesa
+$(eval $(call gb_LinkTarget_add_external_headers,$(1),Mesa_inc))
+
+endef
+
+endif
+

should take care of that (altough the test above is not precise
enough. on MacOSX for instance SYSTEM_MESA_HEADERS is unset, but that
means YES)
I think the cleaner solution would be to change configure.in to make
sure that SYSTEM_MESA_HEADERS is always set with a sane value...

Note: yes the ifeq in slideshow do work.. but I'd rather hide these in
RepositoryExternal.mk rather than polluting the module level makefile
with too many ifeq/fdef...

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

Re: [Libreoffice] ccache support

On Tue, 2011-08-30 at 12:56 -0500, Norbert Thiebaud wrote:

 2/ I had a spike in IRC questions/confusions from new tentative
 contributors on that topic, so I wanted to make it as newbie friendly
 as possible. iow a 'just fscking work' approach.

Cache compression is advertised as saving space in the cache in return
for a modest increase in compilation time.  For me, it is the clear
choice: I see the improved cache usage, and I do not notice the
increased time.

I wonder if any of our hackers using ccache would have the contrary
opinion.  IOW, should our configuration enable compression
unconditionally?  As an option to autogen.sh?  (FWIW, I have changed
my local set_soenv.in to enable compression unconditionally, and I
have completed one successful build.)

Terry.


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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

2011-09-09 Thread Peter Foley

On Fri, 9 Sep 2011, Norbert Thiebaud wrote:

 diff --git a/slideshow/Library_OGLTrans.mk b/slideshow/Library_OGLTrans.mk
 index f3dd316..9e31c16 100644
 --- a/slideshow/Library_OGLTrans.mk
 +++ b/slideshow/Library_OGLTrans.mk
 @@ -63,6 +63,10 @@ $(eval $(call gb_Library_add_linked_libs,OGLTrans,\
  $(gb_STDLIBS) \
  ))
 
 +ifeq ($(SYSTEM_MESA_HEADERS),NO)
 +$(eval $(call gb_Library_use_external,OGLTrans,Mesa))
 +endif
 +
 
 that is unnecessary. because
 
 --- a/RepositoryExternal.mk
 +++ b/RepositoryExternal.mk
 @@ -36,6 +36,19 @@
  # in the system case, no libraries should be registered, but the target-local
  # variable LIBS should be set to FOO_LIBS, and INCLUDES to FOO_CFLAGS.
 
 +ifeq ($(SYSTEM_MESA_HEADERS),YES)
 +
 +gb_LinkTarget__use_Mesa:=
 +
 +else
 +
 +define gb_LinkTarget__use_Mesa
 +$(eval $(call gb_LinkTarget_add_external_headers,$(1),Mesa_inc))
 +
 +endef
 +
 +endif
 +
 
 should take care of that (altough the test above is not precise
 enough. on MacOSX for instance SYSTEM_MESA_HEADERS is unset, but that
 means YES)
 I think the cleaner solution would be to change configure.in to make
 sure that SYSTEM_MESA_HEADERS is always set with a sane value...
 
 Note: yes the ifeq in slideshow do work.. but I'd rather hide these in
 RepositoryExternal.mk rather than polluting the module level makefile
 with too many ifeq/fdef...
 
 Norbert
 

Without the ifeq and with SYSTEM_MESA_HEADERS=YES I got this error.

/root/libreoffice/slideshow/Library_OGLTrans.mk:66: *** 
gb_LinkTarget_use_external: unknown external: Mesa.  Stop.

I'm not sure what a better way to fix this would be.

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

Re: [Libreoffice] master: position to heigh while typing data in a cell

Hi,

On Friday, 2011-09-09 15:54:55 +0200, Eike Rathke wrote:

  Start spreadsheet
  type 8 or so
position is to heigh
 
 I assume this is due to
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=3364fefe1e2dec522211040f2f9ea37bf5cd7466

With
http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f181dad89ad34d90513bc9dcd3e3239727933
the new interline spacing / line height is used only if
SAL_USE_NEW_LINEHEIGHT=1 is set in the environment.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


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

Re: [Libreoffice] ccache support

On Fri, Sep 9, 2011 at 11:10 AM, Terrence Enger ten...@iseries-guru.com wrote:
 On Tue, 2011-08-30 at 12:56 -0500, Norbert Thiebaud wrote:

 2/ I had a spike in IRC questions/confusions from new tentative
 contributors on that topic, so I wanted to make it as newbie friendly
 as possible. iow a 'just fscking work' approach.

 Cache compression is advertised as saving space in the cache in return
 for a modest increase in compilation time.  For me, it is the clear
 choice: I see the improved cache usage, and I do not notice the
 increased time.

Well, my boxes are usually cpu bound (even with a fully hot ccache)
and I have plenty of space for my ccache, so that is not that clear a
choice to me.


 I wonder if any of our hackers using ccache would have the contrary
 opinion.  IOW, should our configuration enable compression
 unconditionally?  As an option to autogen.sh?  (FWIW, I have changed
 my local set_soenv.in to enable compression unconditionally, and I
 have completed one successful build.)

you can set that up with an env variable right ? so you can easily
make ccache behave the way you want, 'automatically', for you. (i.e
export CCACHE_COMPRESS=1 in your bashrc)

I don't do that in configure for the same reason we don't change
CCACHE_DIR or the cache dir size.
Using ccache if available is one thing... but trying to
'auto-magically' optimize ccache is another can of worms altogether...


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

Re: [Libreoffice] Bringing some sanity to interline spacing

Hi Khaled,

On Friday, 2011-09-02 18:21:50 +0200, Khaled Hosny wrote:

MSWord is not known for its sane handling of font metrics, and I have
been told recent (2007-) broke it even further.

Hum, ending up with .docs, .docxs, .rtfs that layout even further from
their original how-they-layout-in-word, while pre-existing .odts and so
forth also change layout sounds somewhat worrying :-). We may have to
cook up a use-old-school-metrics compatibility flag or something like
that along the lines of some similar flags we already have. I might try
and play around the area.

This would even be better. With my font developer hat on I'd prefer
enforcing standard compliance (old behaviour is against OpenType
recommendation), but as long as there is a way to get the correct
behaviour I'm fine.

With
http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f181dad89ad34d90513bc9dcd3e3239727933
the new spacing is used only if SAL_USE_NEW_LINEHEIGHT=1 is set in the
environment, else the old metrics are used.

Khaled (who is suffering right now from this very same issue with MS Word)

Which indicates even more that we can't switch just like that to the new
metrics.

Eike

--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD

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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

On Fri, Sep 9, 2011 at 11:20 AM, Peter Foley pefol...@verizon.net wrote:


 Without the ifeq and with SYSTEM_MESA_HEADERS=YES I got this error.

 /root/libreoffice/slideshow/Library_OGLTrans.mk:66: *** 
 gb_LinkTarget_use_external: unknown external: Mesa.  Stop.

what happen if you change the RepositoryExternal.mk part to

+ifeq ($(SYSTEM_MESA_HEADERS),YES)
+
+define gb_LinkTarget__use_Mesa
+endef
+
+else
+
+define gb_LinkTarget__use_Mesa
+$(eval $(call gb_LinkTarget_add_external_headers,$(1),Mesa_inc))
+
+endef
+
+endif
+

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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

oh and I forgot to ask: what is the value of SYSTEM_MESA_HEADERS in
you EnvHost.sh ?

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

[Libreoffice] [PATCH] Re: Bringing some sanity to interline spacing

Hi,

Can someone with Windows please test the attached patch from Khaled?

Please don't push as is, this needs to be encapsulated in the new
SAL_USE_NEW_LINEHEIGHT=1 environment, so both old and new handling need
to be available.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
---BeginMessage---
On Thu, Sep 01, 2011 at 10:31:14AM +0200, Khaled Hosny wrote:
 It shouldn't be hard to adapt GetFontMetric implementation in
 vcl/win/source/gdi/salgdi3.cxx to use the new function and have the same
 logic as the unix code.

Here is a patch that, hopefully, does this, but I couldn't test it and
it might not even compile.

Regards,
 Khaled

-- 
 Khaled Hosny
 Egyptian
 Arab
From 0743024ea07abd98b19eaf1ffecd6bb111681c58 Mon Sep 17 00:00:00 2001
From: Khaled Hosny khaledho...@eglug.org
Date: Fri, 2 Sep 2011 10:24:16 +0200
Subject: [PATCH] Use GetOutlineTextMetrics instead of GetTextMetrics

Follow up of commit 3364fef

GetOutlineTextMetrics returns an OUTLINETEXTMETRIC struct containing
typographic ascent/descent among other font metrics.

The CKJ external leading hack have been removed as well.
---
 vcl/win/source/gdi/salgdi3.cxx |   51 +++-
 1 files changed, 14 insertions(+), 37 deletions(-)

diff --git a/vcl/win/source/gdi/salgdi3.cxx b/vcl/win/source/gdi/salgdi3.cxx
index fdb9296..ad8dbe0 100644
--- a/vcl/win/source/gdi/salgdi3.cxx
+++ b/vcl/win/source/gdi/salgdi3.cxx
@@ -1764,24 +1764,24 @@ void WinSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbackLe
 pMetric-maName = reinterpret_castconst sal_Unicode*(aFaceName);
 
 // get the font metric
-TEXTMETRICA aWinMetric;
-const bool bOK = GetTextMetricsA( mhDC, aWinMetric );
+OUTLINETEXTMETRICA aWinMetric;
+const bool bOK = GetOutlineTextMetricsA( mhDC, aWinMetric );
 // restore the HDC to the font in the base level
 SelectFont( mhDC, hOldFont );
 if( !bOK )
 return;
 
 // device independent font attributes
-pMetric-meFamily   = ImplFamilyToSal( aWinMetric.tmPitchAndFamily );;
-pMetric-mbSymbolFlag   = (aWinMetric.tmCharSet == SYMBOL_CHARSET);
-pMetric-meWeight   = ImplWeightToSal( aWinMetric.tmWeight );
-pMetric-mePitch= ImplMetricPitchToSal( aWinMetric.tmPitchAndFamily );
-pMetric-meItalic   = aWinMetric.tmItalic ? ITALIC_NORMAL : ITALIC_NONE;
+pMetric-meFamily   = ImplFamilyToSal( aWinMetric.otmTextMetrics.tmPitchAndFamily );;
+pMetric-mbSymbolFlag   = (aWinMetric.otmTextMetrics.tmCharSet == SYMBOL_CHARSET);
+pMetric-meWeight   = ImplWeightToSal( aWinMetric.otmTextMetrics.tmWeight );
+pMetric-mePitch= ImplMetricPitchToSal( aWinMetric.otmTextMetrics.tmPitchAndFamily );
+pMetric-meItalic   = aWinMetric.otmTextMetrics.tmItalic ? ITALIC_NORMAL : ITALIC_NONE;
 pMetric-mnSlant= 0;
 
 // device dependend font attributes
-pMetric-mbDevice   = (aWinMetric.tmPitchAndFamily  TMPF_DEVICE) != 0;
-pMetric-mbScalableFont = (aWinMetric.tmPitchAndFamily  (TMPF_VECTOR|TMPF_TRUETYPE)) != 0;
+pMetric-mbDevice   = (aWinMetric.otmTextMetrics.tmPitchAndFamily  TMPF_DEVICE) != 0;
+pMetric-mbScalableFont = (aWinMetric.otmTextMetrics.tmPitchAndFamily  (TMPF_VECTOR|TMPF_TRUETYPE)) != 0;
 if( pMetric-mbScalableFont )
 {
 // check if there are kern pairs
@@ -1798,34 +1798,11 @@ void WinSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbackLe
 }
 
 // transformation dependend font metrics
-pMetric-mnWidth= static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmAveCharWidth );
-pMetric-mnIntLeading   = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmInternalLeading );
-pMetric-mnExtLeading   = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmExternalLeading );
-pMetric-mnAscent   = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmAscent );
-pMetric-mnDescent  = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmDescent );
-
-// #107888# improved metric compatibility for Asian fonts...
-// TODO: assess workaround below for CWS = extleading
-// TODO: evaluate use of aWinMetric.sTypo* members for CJK
-if( mpWinFontData[nFallbackLevel]  mpWinFontData[nFallbackLevel]-SupportsCJK() )
-{
-pMetric-mnIntLeading += pMetric-mnExtLeading;
-
-// #109280# The line height for Asian fonts is too small.
-// Therefore we add half of the external leading to the
-// ascent, the other half is added to the descent.
-const long nHalfTmpExtLeading = pMetric-mnExtLeading / 2;
-const long nOtherHalfTmpExtLeading = pMetric-mnExtLeading - nHalfTmpExtLeading;
-
-// #110641# external leading for Asian fonts.
-// The factor 0.3 has been confirmed with experiments.
-long nCJKExtLeading =

Re: [Libreoffice] ccache support

Talking about compression of the ccache cache, ...
On Fri, 2011-09-09 at 11:35 -0500, Norbert Thiebaud wrote:
 
 Well, my boxes are usually cpu bound (even with a fully hot ccache)
 and I have plenty of space for my ccache, so that is not that clear a
 choice to me.

So, unconditional compression is no good.

 you can set that up with an env variable right ? so you can easily
 make ccache behave the way you want, 'automatically', for you. (i.e
 export CCACHE_COMPRESS=1 in your bashrc)

Yes, it is the existence of the envvar that controls.

Setting it in .bashrc makes a lot of sense in that the relative
availability of I/O capacity vs. CPU capacity does not depend on what
product the user is building.  The use of .bashrc is so easy and
natural (thank you for reminding me about it!) that I think LO should
not even provide a configuration option for compression.

I notice, BTW, that How to build LibreOffice
http://wiki.documentfoundation.org/Development/How_to_build no
longer says that we automatically enable ccache if it is found on the
system.  Should that statement be added back to the page, now that it
is true?

 
 I don't do that in configure for the same reason we don't change
 CCACHE_DIR or the cache dir size.
 Using ccache if available is one thing... but trying to
 'auto-magically' optimize ccache is another can of worms altogether...

Agree.  Especially so, considering that sometimes a cache may be
shared between different users and different systems.


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

Re: [Libreoffice] ccache support

On Fri, Sep 9, 2011 at 12:35 PM, Terrence Enger ten...@iseries-guru.com wrote:
 I notice, BTW, that How to build LibreOffice
 http://wiki.documentfoundation.org/Development/How_to_build no
 longer says that we automatically enable ccache if it is found on the
 system.
  Should that statement be added back to the page, now that it
 is true?

Sure.

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

Re: [Libreoffice] Bringing some sanity to interline spacing

2011-09-09 Thread Khaled Hosny

On Fri, Sep 09, 2011 at 06:39:52PM +0200, Eike Rathke wrote:
Hi Khaled,

On Friday, 2011-09-02 18:21:50 +0200, Khaled Hosny wrote:

MSWord is not known for its sane handling of font metrics, and I have
been told recent (2007-) broke it even further.

Thanks, though I was expecting a friendlier UI option, but I won't insist
on that :)

Khaled (who is suffering right now from this very same issue with MS Word)

Which indicates even more that we can't switch just like that to the new
metrics.

There is a use typo metrics bit in OS/2 table that was introduced as a
way for font developer to really opt for using typo metrics, I omitted
checking for it for the sake of simplification. Now thinking more of it,
I think we should check it and don't use the new method if it isn't set,
however this does not really solve the combat ability issue since since
many fonts already set it.

Regards,
Khaled

--
Khaled Hosny
Egyptian
Arab

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

Re: [Libreoffice] ccache support

2011-09-09 Thread Lubos Lunak

On Friday 09 of September 2011, Norbert Thiebaud wrote:
 On Fri, Sep 9, 2011 at 11:10 AM, Terrence Enger ten...@iseries-guru.com 
wrote:
  On Tue, 2011-08-30 at 12:56 -0500, Norbert Thiebaud wrote:
  2/ I had a spike in IRC questions/confusions from new tentative
  contributors on that topic, so I wanted to make it as newbie friendly
  as possible. iow a 'just fscking work' approach.
 
  Cache compression is advertised as saving space in the cache in return
  for a modest increase in compilation time.  For me, it is the clear
  choice: I see the improved cache usage, and I do not notice the
  increased time.

 Well, my boxes are usually cpu bound (even with a fully hot ccache)
 and I have plenty of space for my ccache, so that is not that clear a
 choice to me.

 Since there (AFAIR) haven't been any actual data presented in the discussion 
about enabling ccache, let me present some. I admit they are somewhat 
special, but they are real nevertheless. So, the build setup is Intel Xeon 
@2.53GHz (4 cores), 12G RAM, quite powerful icecream network 
(--with-max-jobs=40) and HDD with 120MB/s speed reported by hdparm (but it's 
not SSD, so the seek time is awful as it is with HDDs). I also build 
with --enable-debug.

- cd svx; make clean; make  (just to make the disk caches hot)
- make clean; time make  (i.e. no ccache)
real0m52.378s
user1m37.430s
sys 0m21.630s
- make clean; ccache -C; time cmakeset make (cmakeset enables ccache use here)
real1m1.170s
user1m58.422s
sys 0m27.661s
- make clean; time cmakeset make
real0m14.562s
user0m28.270s
sys 0m6.972s

 So if ccache has 0% hit ratio, there is 17% overhead in this specific case. 
With 100% hit ratio, 73% is saved. That, if my math is right, means at least 
19% ccache hit ratio is required for breaking even.

 My ccache -s reports
cache hit (direct)173894
cache hit (preprocessed)   43418
cache miss323627

 which is 40% hit ratio, but this is with using ccache only explicitly for 
full rebuilds (i.e. when I develop e.g. in sw/ and build just there, it's 
without ccache). I'm also not sure how many hits come from rebuilding 
everything from scratch, which is not something people without this powerful 
build setup would do that easily (I sometimes just give up on a problem and 
rebuilding everything, and after pull -r I usually also rebuild from scratch 
in another dir before switching to it). Finally, it doesn't say anything 
about how many of those hits are tiny .c files and how many of the misses are 
huge .cxx files, which are more likely to be misses because of having more 
dependencies.

 Could somebody else, preferably with a somewhat more common system :), post 
their results, so that we can compare? I assume the ccache overhead (caused 
by I/O I'd say) is exceptionally high here, but I still doubt ccache warrants 
being enabled by default just like that.

 I don't do that in configure for the same reason we don't change
 CCACHE_DIR or the cache dir size.
 Using ccache if available is one thing... but trying to
 'auto-magically' optimize ccache is another can of worms altogether...

 I think the case above shows that there are some worms even in the one thing.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] ccache support

On Fri, 2011-09-09 at 12:47 -0500, Norbert Thiebaud wrote:
 On Fri, Sep 9, 2011 at 12:35 PM, Terrence Enger ten...@iseries-guru.com 
 wrote:
  I notice, BTW, that How to build LibreOffice
  http://wiki.documentfoundation.org/Development/How_to_build no
  longer says that we automatically enable ccache if it is found on the
  system.
   Should that statement be added back to the page, now that it
  is true?
 
 Sure.

Uh oh.  That page is restricted to administrators.

Just as well, as I would have had to send a message to the
discuss list saying that I do not know anything about the
Mac and so had not restored the simultaneously deleted text
about the Mac, and inviting someone who knows something to
write something.

Terry.


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

Re: [Libreoffice] ccache support

On Fri, Sep 9, 2011 at 1:53 PM, Terrence Enger ten...@iseries-guru.com wrote:
 On Fri, 2011-09-09 at 12:47 -0500, Norbert Thiebaud wrote:
 On Fri, Sep 9, 2011 at 12:35 PM, Terrence Enger ten...@iseries-guru.com 
 wrote:
  I notice, BTW, that How to build LibreOffice
  http://wiki.documentfoundation.org/Development/How_to_build no
  longer says that we automatically enable ccache if it is found on the
  system.
   Should that statement be added back to the page, now that it
  is true?

 Sure.

 Uh oh.  That page is restricted to administrators.

no it is not. you just need to register to the wiki... but there is no
special restriction on that.

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

[Libreoffice] How to get LVS spellchk dict into distribution

2011-09-09 Thread Jānis


Hi!

I's like to know how can I get Latvian spellchecker dictionary into  
distribution.


Regards
Janis Eisaks

developer of lv_LV and ltg_LV dics
--
http://dict.dv.lv

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

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

2011-09-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Bug 35673 depends on bug 37390, which changed state.

Bug 37390 Summary: LibreOffice does not create valid ODF.
https://bugs.freedesktop.org/show_bug.cgi?id=37390

   What|Old Value   |New Value

 Resolution|FIXED   |
 Status|RESOLVED|REOPENED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [Libreoffice] ccache support

On Fri, Sep 9, 2011 at 1:22 PM, Lubos Lunak l.lu...@suse.cz wrote:
  So if ccache has 0% hit ratio, there is 17% overhead in this specific case.
 With 100% hit ratio, 73% is saved. That, if my math is right, means at least
 19% ccache hit ratio is required for breaking even.

I'm am gathering numbers, in the mean time
http://tinderbox.libreoffice.org/MASTER/status.html give me some good
data about the ccache hit.
by looking at the time it take for each build iteration... most of
them show that the hit ration is almost always very very high (90%+),
unless some commit touch a commonly included header.

Now granted, once we can reliably do incremental build, the question
of the effectiveness of ccache will be much more acute.
presumable incremental build only try to compile stuff that _need_ to
be compiled and therefore should be a ccache miss... so with perfect
incremental build the ccache hit should be 0%

when that is true, we could indeed change the default for ccache to disable

FYI: my ccachs -s for my MacOSX buildbot is

n_th@tpamac ~/.ssh $ccache -s
cache directory /Volumes/ccache_ramdisk
cache hit (direct)481347
cache hit (preprocessed)   19049
cache miss 28588
called for link25314
multiple source files102
compile failed  8524
preprocessor error  4318
bad compiler arguments  1768
unsupported source language  408
autoconf compile/link  35802
unsupported compiler option60295
no input file   7446
files in cache 43163
cache size   1.8 Gbytes
max cache size   2.3 Gbytes


so a hit ration of  94.6%  (481347 + 19049) / (481347 + 19049 + 25588)

(note that cache had been wiped out about 2 days ago due to an IPL of
the box -- the cache is in ramdisk, so it does not survive a reboot)

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

Re: [Libreoffice] [PATCH] convert Mesa to gbuild

2011-09-09 Thread Michael Stahl

On 08.09.2011 02:40, Norbert Thiebaud wrote:
 On Wed, Sep 7, 2011 at 7:23 PM, Norbert Thiebaud nthieb...@gmail.com wrote:

 I suppose that to be perfect that should bu tuck under
 gb_LinkTarget_use_Mesa in RepositoryExternal.mk to properly deal with
 the case when using system-mesa vs internal-mesa...

 and then just add Mesa to the list of 'use_externals' of OGLTrans ...

 
 BTW. bjorn, michael,
 
 How should we deal with optional 'external' Module like that ?
 just wrap the whole 'Module_Mesa.mk' into a ifeq ($(SYSTEM_MESA_HEADERS),NO) ?

sounds reasonable.

this could cause warning that no target is registered or something like
that, but a module with only $(eval $(call gb_Module_Module,foo)) is
valid IIRC.

 Norbert


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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

2011-09-09 Thread Peter Foley

On Fri, 9 Sep 2011, Norbert Thiebaud wrote:

 On Fri, Sep 9, 2011 at 11:20 AM, Peter Foley pefol...@verizon.net wrote:
 
 
  Without the ifeq and with SYSTEM_MESA_HEADERS=YES I got this error.
 
  /root/libreoffice/slideshow/Library_OGLTrans.mk:66: *** 
  gb_LinkTarget_use_external: unknown external: Mesa.  Stop.
 
 what happen if you change the RepositoryExternal.mk part to
 
 +ifeq ($(SYSTEM_MESA_HEADERS),YES)
 +
 +define gb_LinkTarget__use_Mesa
 +endef
 +
 +else
 +
 +define gb_LinkTarget__use_Mesa
 +$(eval $(call gb_LinkTarget_add_external_headers,$(1),Mesa_inc))
 +
 +endef
 +
 +endif
 +
 
 Norbert
 


I got the same error when SYSTEM_MESA_HEADERS=YES. But it worked when 
SYSTEM_MESA_HEADERS=NO.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] ccache support

On Fri, 2011-09-09 at 20:22 +0200, Lubos Lunak wrote:
 On Friday 09 of September 2011, Norbert Thiebaud wrote:
 
  Could somebody else, preferably with a somewhat more common system :), post 
 their results, so that we can compare? I assume the ccache overhead (caused 
 by I/O I'd say) is exceptionally high here, but I still doubt ccache warrants 
 being enabled by default just like that.
 
  I don't do that in configure for the same reason we don't change
  CCACHE_DIR or the cache dir size.
  Using ccache if available is one thing... but trying to
  'auto-magically' optimize ccache is another can of worms altogether...
 
  I think the case above shows that there are some worms even in the one thing.
 
 

Well, let me throw some more numbers on the pile, about
space, number of cached files, and hits.  Short version:
cache compression reduces cache size by very roughly a
factor of 5.

My RAM is so small, at 512MB, that I omit timings; besides I
kept using the system for other things at the same time.
All compiles yesterday were with cache compression turned on.

Size is in KB as reported by `du --summarize ~/.ccache`.
Files, hits, and misses are from `ccache -s`.

I started yesterday with a cache holding files from a number
of previous builds of LibreOffice, some of them compressed,
but lots not (just because I keep forgetting to set
CCACHE_COMPRESS; yes, I have now added that to my .bashrc):
size   : 9563228
files  : 79453
hits   : 54662 + 510
misses : 39198
I calculate average file size 120.02KB

After some unsuccessful attempts to rebuild:
size   : 9618256
files  : 81585
hits   : 54874 + 629
misses : 39990
I calculate average file size 117.85KB and average size
21.03KB for the 2184 new files.

After successful complete build, which cleaned out part of
the cache:
size   : 9123940
files  : 99112
hits   : 62377 + 3080
misses : 48614
I calculate average file size 92.06KB.

FWIW, and HTH
Terry.


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

Re: [Libreoffice] How to get LVS spellchk dict into distribution

2011-09-09 Thread Andras Timar

Hi,

2011/9/9 Jānis ja...@dv.lv:
 Hi!

 I's like to know how can I get Latvian spellchecker dictionary into
 distribution.

Please give us the link to your spellchecker files and tell us about
its license. From technical point of view it's a no-brainer to include
it into our source tree. I can do that.

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [Libreoffice-commits] .: sal/inc

2011-09-09 Thread Stephan Bergmann


On 09/07/2011 02:56 PM, Bjoern Michaelsen wrote:

  sal/inc/sal/types.h |   16 
  1 file changed, 16 insertions(+)

New commits:
commit de290e726ed2aa5a4c007d61a7db1042c45d43db
Author: Bjoern Michaelsenbjoern.michael...@canonical.com
Date:   Wed Sep 7 12:37:08 2011 +0200

 introduce SAL_DEPRECATED macro


Is it true that __declspec must go before the return type for MSC (i.e., 
that the return type must go within the SAL_DEPRECATED argument)?  Then, 
SAL_DEPRECATED suffers from the multiple-argument template return type 
unpleasantness described at 
http://stackoverflow.com/questions/295120/c-mark-as-deprecated/295229#295229. 
 :(


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

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

2011-09-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=35673

--- Comment #201 from rpr.nos...@gmail.com 2011-09-09 12:46:16 PDT ---
Nominating Bug 40482 - Non-printing characters become invisible. This is a
rather annoying regression in Writer (LibO ver. 3.4.3).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] [Bug 35673] LibreOffice 3.4 most annoying bugs

2011-09-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=35673

rpr.nos...@gmail.com changed:

   What|Removed |Added

 Depends on||40482

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [Libreoffice] o3tl/cow_wrapper.hxx not found

2011-09-09 Thread Simon Brouwer

Hi Matus, all,

I made that change, did make clean in o3tl and then make, now there is
another error:

C:/cygwin/home/Simon/git/libo
/workdir/wntmsci12.pro/CxxObject/o3tl/qa/cow_wrapp
er_clients.o C:/cygwin/home/Simon/git/libo
/workdir/wntmsci12.pro/CxxObject/o3tl
/qa/test-cow_wrapper.o C:/cygwin/home/Simon/git/libo
/workdir/wntmsci12.pro/CxxO
bject/o3tl/qa/test-heap_ptr.o C:/cygwin/home/Simon/git/libo
/workdir/wntmsci12.p
ro/CxxObject/o3tl/qa/test-range.o C:/cygwin/home/Simon/git/libo
/workdir/wntmsci
12.pro/CxxObject/o3tl/qa/test-vector_pool.o
LINK : warning LNK4044: unrecognized option
'/workdir/wntmsci12.pro/CxxObject/o3
tl/qa/cow_wrapper_clients.o'; ignored
LINK : warning LNK4044: unrecognized option
'/workdir/wntmsci12.pro/CxxObject/o3
tl/qa/test-cow_wrapper.o'; ignored
LINK : warning LNK4044: unrecognized option
'/workdir/wntmsci12.pro/CxxObject/o3
tl/qa/test-heap_ptr.o'; ignored
LINK : warning LNK4044: unrecognized option
'/workdir/wntmsci12.pro/CxxObject/o3
tl/qa/test-range.o'; ignored
LINK : warning LNK4044: unrecognized option
'/workdir/wntmsci12.pro/CxxObject/o3
tl/qa/test-vector_pool.o'; ignored
LINK : fatal error LNK1181: cannot open input file
'C:/cygwin/home/Simon/git/lib
o.obj'
make: ***
[/home/Simon/git/libo/workdir/wntmsci12.pro/LinkTarget/CppunitTest/ite
st_o3tl_tests.lib] Error 157

Sorry for the formatting, I need to use webmail on my build machine.

I guess I better move the libo tree to another directory out of the cygwin
tree and start building from the beginning. If I moved git\libo\... from
C:/cygwin/home/Simon/ to C:/ would that be OK? I suppose I need to run
autogen.sh and/or make clean after moving the tree?

Best regards,
Simon




MatÃºÅ¡ Kukan schreef:
 On 9 September 2011 09:19, Tor Lillqvist t...@iki.fi wrote:
 (re-formatting the make output for clarity)

 [ build CXX ] o3tl/qa/cow_wrapper_clients
 R=c:/cygwin/home/Simon/git 
 O=$R/libo/solver/wntmsci12.pro 
 W=$R/libo/workdir/wntmsci12.pro 
 S=$R/libo 

 Here the build mechanism sets some shell variables that will then be
 used later on the same command line. (Yeah, weird, but apparently this
 *is* a good idea, I don't know or recall the details.)

 mkdir -p $W/CxxObject/o3tl/qa/$W/Dep/CxxObject/o3tl/qa/ 
 /cygdrive/c/PROGRA~1/MICROS~1.0/VC/bin/cl.exe
 -DBOOST_MEM_FN_ENABLE_CDECL -DCPPU_ENV=msci -DCUI -DENABLE_GRAPHITE
 -DENABLE_GTK

 [...], looks fine so far

 -IC:/cygwin$O/inc/stl
 -IC:/cygwin$O/inc/external -IC:/cygwin$O/inc
 -IC:/cygwin$S/solenv/wntmsci12/inc
 -IC:/cygwin$S/solenv/inc
 -IC:/cygwin$S/res

 But these are all screwed up, the $O and $S shell variables are not
 expanded, and even if they were, they are used in locations that don't
 make sense.

 I had the same problem and was wondering why I'm the only one.

 You are supposed to see -I flags with the $O and $S expanded. In your
 case O=c:/cygwin/home/Simon/git/libo/solver/wntmsci12.pro and
 S=c:/cygwin/home/Simon/git/libo as far as I can see).

 For instance the first -I option there, -IC:/cygwin$O/inc/stl , would
 with $O expanded be
 -IC:/cygwinc:/cygwin/home/Simon/git/libo/solver/wntmsci12.pro/inc/stl
 which of course makes no sense.

 There must be something wrong in the gbuild make function mechanisms
 that mishandles your case. I wonder if it is the fact that you are
 building in your home directory, does the fact that the build location
 starts with c:/cygwin confuse some substitution pattern, or something?
 I will try to investigate.

 --- a/solenv/gbuild/platform/windows.mk
 +++ b/solenv/gbuild/platform/windows.mk
 @@ -234,10 +234,10 @@ endef
  endif

  # Helper class
 -gb_Helper_SRCDIR_NATIVE := $(shell cygpath -m $(SRCDIR) | $(gb_AWK)
 -- '{ print tolower(substr($$0,1,1)) substr($$0,2) }')
 -gb_Helper_WORKDIR_NATIVE := $(shell cygpath -m $(WORKDIR) | $(gb_AWK)
 -- '{ print tolower(substr($$0,1,1)) substr($$0,2) }')
 -gb_Helper_OUTDIR_NATIVE := $(shell cygpath -m $(OUTDIR) | $(gb_AWK)
 -- '{ print tolower(substr($$0,1,1)) substr($$0,2) }')
 -gb_Helper_REPODIR_NATIVE := $(shell cygpath -m $(REPODIR) | $(gb_AWK)
 -- '{ print tolower(substr($$0,1,1)) substr($$0,2) }')
 +gb_Helper_SRCDIR_NATIVE := $(shell cygpath -m $(SRCDIR))
 +gb_Helper_WORKDIR_NATIVE := $(shell cygpath -m $(WORKDIR))
 +gb_Helper_OUTDIR_NATIVE := $(shell cygpath -m $(OUTDIR))
 +gb_Helper_REPODIR_NATIVE := $(shell cygpath -m $(REPODIR))

 Has solved problem for me I think. There was something else maybe (but
 only warnings, I'm not sure now what exactly), but this helped to
 continue building.

 HTH,

 MatÃºÅ¡




-- 
Vriendelijke groet,

Simon Brouwer
-*- nl.openoffice.org -*- http://www.opentaal.org -*-

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

Re: [Libreoffice] [PATCH v2] convert Mesa to gbuild and add to tail_build

2011-09-09 Thread Michael Stahl

On 09.09.2011 21:28, Peter Foley wrote:
 On Fri, 9 Sep 2011, Norbert Thiebaud wrote:
 
 On Fri, Sep 9, 2011 at 11:20 AM, Peter Foley pefol...@verizon.net wrote:


 Without the ifeq and with SYSTEM_MESA_HEADERS=YES I got this error.

 /root/libreoffice/slideshow/Library_OGLTrans.mk:66: *** 
 gb_LinkTarget_use_external: unknown external: Mesa.  Stop.

 what happen if you change the RepositoryExternal.mk part to

 +ifeq ($(SYSTEM_MESA_HEADERS),YES)
 +
 +define gb_LinkTarget__use_Mesa
 +endef
 +
 +else
 +
 +define gb_LinkTarget__use_Mesa
 +$(eval $(call gb_LinkTarget_add_external_headers,$(1),Mesa_inc))
 +
 +endef
 +
 +endif
 +

 Norbert

 
 
 I got the same error when SYSTEM_MESA_HEADERS=YES. But it worked when 
 SYSTEM_MESA_HEADERS=NO.

the problem is this:

define gb_LinkTarget_use_external
$(if $(value gb_LinkTarget__use_$(2)),\
  $(call gb_LinkTarget__use_$(2),$(1)),\
  $(error gb_LinkTarget_use_external: unknown external: $(2)))
endef

the if is just intended to check that there actually is a variable
defined, but what it actually checks is whether there is a variable
defined that has a non-empty value.

until this Mesa case nobody noticed  :)

can you try the following patch:

diff --git a/solenv/gbuild/LinkTarget.mk b/solenv/gbuild/LinkTarget.mk
index 69683c5..d003455 100644
--- a/solenv/gbuild/LinkTarget.mk
+++ b/solenv/gbuild/LinkTarget.mk
@@ -1069,9 +1069,9 @@ endef
 # this forwards to functions that must be defined in RepositoryExternal.mk.
 # $(eval $(call gb_LinkTarget_use_external,library,external))
 define gb_LinkTarget_use_external
-$(if $(value gb_LinkTarget__use_$(2)),\
-  $(call gb_LinkTarget__use_$(2),$(1)),\
-  $(error gb_LinkTarget_use_external: unknown external: $(2)))
+$(if $(filter undefined,$(origin gb_LinkTarget__use_$(2))),\
+  $(error gb_LinkTarget_use_external: unknown external: $(2)),\
+  $(call gb_LinkTarget__use_$(2),$(1)))
 endef
 
 # $(call gb_LinkTarget_use_externals,library,externals)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] some cleaning for Windows part - need a review

2011-09-09 Thread Pierre-André Jacquod


hello,
liking systematic work, I was cleaning the unreadVariable warning from 
cppchecker.:-) This also let improve my programming knowledge and style...


Here a bunch of changes that touch only Win product,... that I am unable 
to test, having only unix.


Neverless, I did it would it be to reduce the warning noise (also some 
real coding error are popping out sometimes...) Could someone at least 
import and compile it with a Windows box?


By the way, just a question: from which version is Windows supported? 
some function names and comment let think me that some part could be 
deprecated ? (see example below)


Thanks and regards
Pierre-André

static BOOL MoveFileEx9x( LPCSTR lpExistingFileNameA, LPCSTR 
lpNewFileNameA, DWORD dwFlags )

{
BOOLfSuccess = FALSE;   // assume failure

// Windows 9x has a special mechanism to move files after reboot
From 54384140202fb9446b735d6bd5a08b351dc1a2b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= pjacq...@alumni.ethz.ch
Date: Fri, 9 Sep 2011 21:58:21 +0200
Subject: [PATCH 6/6] [cppchecker] unreadVar warning - deleted unread variable

and simplified coding after that since the logic is not needed
anymore.
---
 .../customactions/shellextensions/vistaspecial.cxx |   60 ++--
 1 files changed, 5 insertions(+), 55 deletions(-)

diff --git a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
index aede073..40ff772 100644
--- a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
+++ b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
@@ -96,7 +96,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 bool bDirectoryRemoved = true;
 
-std::_tstring mystr;
 std::_tstring sPattern = sPath + TEXT(\\) + TEXT(*.*);
 WIN32_FIND_DATA aFindData;
 
@@ -114,9 +113,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 std::_tstring sFileName = aFindData.cFileName;
 
-mystr = Current short file:  + sFileName;
-// MessageBox(NULL, mystr.c_str(), Current Content, MB_OK);
-
 if (( strcmp(sFileName.c_str(),sCurrentDir.c_str()) != 0 ) 
 ( strcmp(sFileName.c_str(),sParentDir.c_str()) != 0 ))
 {
@@ -124,31 +120,11 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 
 if ( aFindData.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY )
 {
-bool fSuccess = RemoveCompleteDirectory(sCompleteFileName);
-if ( fSuccess )
-{
-mystr = Successfully removed content of dir  + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), Removed Directory, MB_OK);
-}
-else
-{
-mystr = An error occurred during removing content of  + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), Error removing directory, MB_OK);
-}
+RemoveCompleteDirectory(sCompleteFileName);
 }
 else
 {
-bool fSuccess = DeleteFile( sCompleteFileName.c_str() );
-if ( fSuccess )
-{
-mystr = Successfully removed file  + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), Removed File, MB_OK);
-}
-else
-{
-mystr = An error occurred during removal of file  + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), Error removing file, MB_OK);
-}
+DeleteFile( sCompleteFileName.c_str() );
 }
 }
 
@@ -162,17 +138,9 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 // RemoveDirectory is only successful, if the last handle to the directory is closed
 // - first removing content - closing handle - remove empty directory
 
-bool fRemoveDirSuccess = RemoveDirectory(sPath.c_str());
 
-if ( fRemoveDirSuccess )
-{
-mystr = Successfully removed dir  + sPath;
-// MessageBox(NULL, mystr.c_str(), Removed Directory, MB_OK);
-}
-else
+if( !( RemoveDirectory(sPath.c_str()) ) )
 {
-mystr = An error occurred during removal of empty directory  + sPath;
-// MessageBox(NULL, mystr.c_str(), Error removing directory, MB_OK);
 bDirectoryRemoved = false;
 }
 }
@@ -189,8 +157,6 @@ extern C UINT __stdcall RenamePrgFolder( MSIHANDLE handle )
 std::_tstring sRenameSrc = sOfficeInstallPath + TEXT(program);
 std::_tstring sRenameDst = sOfficeInstallPath + TEXT(program_old);

Re: [Libreoffice] ccache support

On Fri, 2011-09-09 at 14:22 -0500, Norbert Thiebaud wrote:
 
 Now granted, once we can reliably do incremental build, the question
 of the effectiveness of ccache will be much more acute.
 presumable incremental build only try to compile stuff that _need_ to
 be compiled and therefore should be a ccache miss... so with perfect
 incremental build the ccache hit should be 0%

Not quite, I think.  Consider a header file changed within
in #if-skipped region in a way which does not change the
number of skipped lines.  I expect this would trigger a
recompile and that ccache, other things being equal, would
find a hit on the cache.  Does this sound plausible.

Still, I would expect the hit rate to go really close to 0.

Terry.


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

Re: [Libreoffice] ccache support

On Fri, Sep 9, 2011 at 3:55 PM, Terrence Enger ten...@iseries-guru.com wrote:
 On Fri, 2011-09-09 at 14:22 -0500, Norbert Thiebaud wrote:

 Now granted, once we can reliably do incremental build, the question
 of the effectiveness of ccache will be much more acute.
 presumable incremental build only try to compile stuff that _need_ to
 be compiled and therefore should be a ccache miss... so with perfect
 incremental build the ccache hit should be 0%

 Not quite, I think.  Consider a header file changed within
 in #if-skipped region in a way which does not change the
 number of skipped lines.  I expect this would trigger a
 recompile and that ccache, other things being equal, would
 find a hit on the cache.  Does this sound plausible.

 Still, I would expect the hit rate to go really close to 0.

And as Lubos remarked earlier... you need to be in the 20% hit rate to
get your money-back...

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

[Libreoffice] Cppcheck defect when @ is present

2011-09-09 Thread julien2412

Hello,

Following the pb cppcheck duplicateExpression, I found why the
duplicateExpression wasn't detected on salframe.cxx from aqua part.
It's due to the @ use, for example @try, @catch and other things like this.
As soon as the @ parts are commented out, detection works.

I created the ticket 3102 on cppcheck : 
https://sourceforge.net/apps/trac/cppcheck/ticket/3102

Conclusion : I don't know if @ is often used but there could be more
error/warnings cppcheck in aqua parts as soon as this bug will be resolved.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-defect-when-is-present-tp3324103p3324103.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] ccache support