Re: testTdf108947 failure on master

2018-05-03 Thread Stephan van den Akker 
Hi David, Arnaud,

I too get this test failure on openSUSE Leap 42.2 (=old static release),
even after following Arnaud's suggestion of removing and blacklisting
google-roboto-fonts.

BTW: On my openSUSE Tumbleweed systems (=rolling release, so newest stable
versions of everything) blacklisting roboto _did_ work. LO builds there.


2018-05-02 8:15 GMT+02:00 Arnaud Versini :

> Hello,
>
> Did you try to remove google-roboto-fonts package ? I opened a bug about
> this issue on tdf bugzilla
>
> Le mer. 2 mai 2018 à 06:41, David Ostrovsky  a écrit :
>
>>
>> It seems that I need this patch: [1] on most recent master
>> to pass the rtfimport test. All other tests pass. My autogen
>> input file is here: [2]. Build tool chain used:
>>
>> $ gcc --version
>> gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
>>
>> When I open this test document testTdf108947, I'm seeing in
>> fact one single page: [3]. Any clue, what is going on here?
>>
>> [1] http://paste.openstack.org/show/720207
>> [2] http://paste.openstack.org/show/720208
>> [3] https://imgur.com/a/3eQdQDA
>> ___
>> LibreOffice mailing list
>> LibreOffice@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Merging feature/commonsallayout branch

2016-10-18 Thread Stephan van den Akker 
Congratulations when this gets merged! It's a big chunk of work.

One question is on my mind that I was meaning to ask before: Is issue
tdf#66819 "Setting additional spacing between characters does not
prevent automatic ligature substitution." solved in this branch?

Greetings,

Stephan

2016-10-17 21:30 GMT+02:00 Khaled Hosny :
> I believe that feature/commonsallayout (AKA unified text layout) is now
> feature complete with no known major bugs, and should be ready to be
> merged on master. I’ll try merge it tomorrow night and hope for the
> best, unless someone objects loudly.
>
> Currently the new layout is off by default and can be enabled at runtime
> by setting SAL_USE_COMMON_LAYOUT env variable. After merging with
> master, I’m going to wait a week or so for any potential build issues
> then swap the default.
>
> There are too main issues with the new code:
> - Type 1 fonts are not supported. They can be supported with some
>   effort, but Type 1 fonts have been obsolete for more than 15 years and
>   I’d like to use this opportunity to drop support for them and cleanup
>   some of the ugly code we have.
> - We use a bit of DirectWrite to load fonts on Windows, so Windows XP is
>   not supported as well. Again it can be fixed with some effort, but I
>   don’t think anyone will miss XP. Ideally we should do a full switch to
>   DirectWrite and modernise our Windows font rendering, but that is
>   another story.
>
> Regards,
> Khaled
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need help compiling using the --enable-vlc option.

2016-10-04 Thread Stephan van den Akker 
Hi there, Kirk Puppy and Rene,

I'm planning to work on improving the video playback in LO, and I am
interested in your experiences with the vlc option.

Can this be made to work at the same quality level as i.e. the gstreamer plugin?

Are you yourself planning to make code contributions in this area?

Greetings,

Stephan van den Akker
Peutz bv
the Netherlands


2016-09-30 20:03 GMT+02:00 Kirk Puppy <kirkpu...@gmail.com>:
> Wow, that was easy. Thanks for your help Rene!
>
> On Fri, Sep 30, 2016 at 9:11 AM, Rene Engelhard <r...@debian.org> wrote:
>>
>> Hi,
>>
>> On Wed, Sep 28, 2016 at 10:35:39AM -0400, Kirk Puppy wrote:
>> > So I built with --enable-vlc, but libreoffice still seemed to
>> > try and
>> >use gstreamer. When I would try and insert video into Impress I would
>> > get
>> >a gstreamer missing pluggins error on the terminal.
>> > So then I tried compiling with --enable-vlc,
>> > --disable-gstreamer-1-0,
>> >and --disable-gstreamer-0-10. Now when I try to insert video into
>> > impress,
>> >I don't see any errors about gstreamer. But Impress pops up an error
>> >message "The format of the selected file is not supported".  I tried
>> > mp4,
>> >avi, and mkv. All have the same error message. Is there something
>> > else I
>> >need for using VLC? Is Gstreamer required?
>>
>> % grep -ri experimental *
>> source/vlc/vlcuno.cxx:// Experimental for now - code is neither
>> elegant nor well tested.
>> source/vlc/vlcuno.cxx:if (!xContext.is() ||
>> !officecfg::Office::Common::Misc::ExperimentalMode::get(xContext))
>> source/vlc/vlcuno.cxx:// Experimental for now - code is neither
>> elegant nor well tested.
>> source/vlc/vlcuno.cxx:if (!xContext.is() ||
>> !officecfg::Office::Common::Misc::ExperimentalMode::get(xContext))
>>
>> So I guess you want to enable experimental features?
>> (in Tools -> Options -> Advanced)
>>
>> Regards,
>>
>> Rene
>
>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: Branch 'libreoffice-5-0' - test/source vcl/qa vcl/source

2016-03-06 Thread Stephan van den Akker 
 test/source/mtfxmldump.cxx   |   28 ++-
 vcl/qa/cppunit/wmf/wmfimporttest.cxx |   16 +++
 vcl/source/filter/wmf/enhwmf.cxx |   36 +--
 vcl/source/filter/wmf/winmtf.hxx |9 
 4 files changed, 82 insertions(+), 7 deletions(-)

New commits:
commit 4a17335d608c2954c482734ce4912100cb0e7aff
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Wed Mar 2 00:17:03 2016 +0100

Fix the import of line joins and caps from EMF files

Backported fix to 5.0. Note that commit 42f771d6e changed from constant
values for line joins to an enum, but that only got into the 5.1 branch
so have had to use the old constants.

Change-Id: I976336d35366b661e402db484820b4dd9a7b0228
Reviewed-on: https://gerrit.libreoffice.org/22821
Reviewed-by: Tomaž Vajngerl <qui...@gmail.com>
Tested-by: Tomaž Vajngerl <qui...@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/22947
Reviewed-by: Chris Sherlock <chris.sherloc...@gmail.com>
Tested-by: Chris Sherlock <chris.sherloc...@gmail.com>

diff --git a/test/source/mtfxmldump.cxx b/test/source/mtfxmldump.cxx
index 3df33b9..9ca0603 100644
--- a/test/source/mtfxmldump.cxx
+++ b/test/source/mtfxmldump.cxx
@@ -124,6 +124,29 @@ OUString convertLineStyleToString(LineStyle eAlign)
 return OUString();
 }
 
+OUString convertLineJoinToString(basegfx::B2DLineJoin eJoin)
+{
+switch (eJoin)
+{
+default:
+case basegfx::B2DLINEJOIN_NONE:return OUString("none");
+case basegfx::B2DLINEJOIN_BEVEL:   return OUString("bevel");
+case basegfx::B2DLINEJOIN_MITER:   return OUString("miter");
+case basegfx::B2DLINEJOIN_ROUND:   return OUString("round");
+}
+}
+
+OUString convertLineCapToString(css::drawing::LineCap eCap)
+{
+switch (eCap)
+{
+default:
+case css::drawing::LineCap_BUTT:   return OUString("butt");
+case css::drawing::LineCap_ROUND:  return OUString("round");
+case css::drawing::LineCap_SQUARE: return OUString("square");
+}
+}
+
 OUString convertFontWeigthToString(FontWeight eFontWeight)
 {
 enum FontWeight { WEIGHT_DONTKNOW, WEIGHT_THIN, WEIGHT_ULTRALIGHT,
@@ -282,9 +305,12 @@ void MetafileXmlDump::writeXml(const GDIMetaFile& 
rMetaFile, XmlWriter& rWriter)
 rWriter.attribute("style", 
convertLineStyleToString(aLineInfo.GetStyle()));
 rWriter.attribute("width", aLineInfo.GetWidth());
 rWriter.attribute("dashlen", aLineInfo.GetDashLen());
+rWriter.attribute("dashcount", aLineInfo.GetDashCount());
 rWriter.attribute("dotlen", aLineInfo.GetDotLen());
+rWriter.attribute("dotcount", aLineInfo.GetDotCount());
 rWriter.attribute("distance", aLineInfo.GetDistance());
-
+rWriter.attribute("join", 
convertLineJoinToString(aLineInfo.GetLineJoin()));
+rWriter.attribute("cap", 
convertLineCapToString(aLineInfo.GetLineCap()));
 rWriter.endElement();
 }
 break;
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 2a1a341..32c4d90 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -147,23 +147,39 @@ void WmfTest::testEmfLineStyles()
 
 assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dashcount", "1");
 assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
+assertXPath(pDoc, "/metafile/line[1]", "dotcount", "0");
 assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+assertXPath(pDoc, "/metafile/line[1]", "join", "miter");
+assertXPath(pDoc, "/metafile/line[1]", "cap", "butt");
 
 assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dashcount", "0");
 assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "dotcount", "1");
 assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+assertXPath(pDoc, "/metafile/line[2]", "join", "miter");
+as

[Libreoffice-commits] core.git: Branch 'libreoffice-5-1' - test/source vcl/qa vcl/source

2016-03-06 Thread Stephan van den Akker 
 test/source/mtfxmldump.cxx   |   28 ++-
 vcl/qa/cppunit/wmf/wmfimporttest.cxx |   16 ++-
 vcl/source/filter/wmf/enhwmf.cxx |   36 +--
 3 files changed, 76 insertions(+), 4 deletions(-)

New commits:
commit 185194a3d935cb92d4f1d50c8987d1e8d69c5041
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Wed Mar 2 00:17:03 2016 +0100

Fix the import of line joins and caps from EMF files

Backported fix to 5.1

Change-Id: I976336d35366b661e402db484820b4dd9a7b0228
Reviewed-on: https://gerrit.libreoffice.org/22821
Reviewed-by: Tomaž Vajngerl <qui...@gmail.com>
Tested-by: Tomaž Vajngerl <qui...@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/22946
Reviewed-by: Chris Sherlock <chris.sherloc...@gmail.com>
Tested-by: Chris Sherlock <chris.sherloc...@gmail.com>

diff --git a/test/source/mtfxmldump.cxx b/test/source/mtfxmldump.cxx
index f30e727..aa42a08 100644
--- a/test/source/mtfxmldump.cxx
+++ b/test/source/mtfxmldump.cxx
@@ -124,6 +124,29 @@ OUString convertLineStyleToString(LineStyle eAlign)
 return OUString();
 }
 
+OUString convertLineJoinToString(basegfx::B2DLineJoin eJoin)
+{
+switch (eJoin)
+{
+default:
+case basegfx::B2DLineJoin::NONE:return OUString("none");
+case basegfx::B2DLineJoin::Bevel:   return OUString("bevel");
+case basegfx::B2DLineJoin::Miter:   return OUString("miter");
+case basegfx::B2DLineJoin::Round:   return OUString("round");
+}
+}
+
+OUString convertLineCapToString(css::drawing::LineCap eCap)
+{
+switch (eCap)
+{
+default:
+case css::drawing::LineCap_BUTT:   return OUString("butt");
+case css::drawing::LineCap_ROUND:  return OUString("round");
+case css::drawing::LineCap_SQUARE: return OUString("square");
+}
+}
+
 OUString convertFontWeigthToString(FontWeight eFontWeight)
 {
 enum FontWeight { WEIGHT_DONTKNOW, WEIGHT_THIN, WEIGHT_ULTRALIGHT,
@@ -282,9 +305,12 @@ void MetafileXmlDump::writeXml(const GDIMetaFile& 
rMetaFile, XmlWriter& rWriter)
 rWriter.attribute("style", 
convertLineStyleToString(aLineInfo.GetStyle()));
 rWriter.attribute("width", aLineInfo.GetWidth());
 rWriter.attribute("dashlen", aLineInfo.GetDashLen());
+rWriter.attribute("dashcount", aLineInfo.GetDashCount());
 rWriter.attribute("dotlen", aLineInfo.GetDotLen());
+rWriter.attribute("dotcount", aLineInfo.GetDotCount());
 rWriter.attribute("distance", aLineInfo.GetDistance());
-
+rWriter.attribute("join", 
convertLineJoinToString(aLineInfo.GetLineJoin()));
+rWriter.attribute("cap", 
convertLineCapToString(aLineInfo.GetLineCap()));
 rWriter.endElement();
 }
 break;
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 2a1a341..6740446 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -147,23 +147,37 @@ void WmfTest::testEmfLineStyles()
 
 assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dashcount", "1");
 assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
-assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+assertXPath(pDoc, "/metafile/line[1]", "dotcount", "0");
+assertXPath(pDoc, "/metafile/line[1]", "distance", "176");
+assertXPath(pDoc, "/metafile/line[1]", "join", "miter");
+assertXPath(pDoc, "/metafile/line[1]", "cap", "butt");
 
 assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dashcount", "0");
 assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "dotcount", "1");
 assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+assertXPath(pDoc, "/metafile/line[2]", "join", "miter");
+assertXPath(pDoc, "/metafile/line[2]", "cap", "butt");
 
 assertXPath(pDoc, "/metafile

[Libreoffice-commits] core.git: Branch 'libreoffice-5-0' - vcl/qa vcl/source

2016-03-04 Thread Stephan van den Akker 
 vcl/qa/cppunit/wmf/data/line_styles.emf |binary
 vcl/qa/cppunit/wmf/wmfimporttest.cxx|   46 
 vcl/source/filter/wmf/enhwmf.cxx|   36 -
 3 files changed, 70 insertions(+), 12 deletions(-)

New commits:
commit 86b1846bbbd0a7ec84ed9d87fed411910b747765
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Tue Feb 23 11:13:20 2016 +0100

Improve the import of pen styles from EMF files

Change-Id: I643c29befeb29b7b1cdd66375f661f4adb0e6cfa
Reviewed-on: https://gerrit.libreoffice.org/22638
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: David Tardon <dtar...@redhat.com>
(cherry picked from commit 9db34a7712e277389b2041cfbd77a60476d7f7f1)
Reviewed-on: https://gerrit.libreoffice.org/22718
Reviewed-by: Chris Sherlock <chris.sherloc...@gmail.com>

diff --git a/vcl/qa/cppunit/wmf/data/line_styles.emf 
b/vcl/qa/cppunit/wmf/data/line_styles.emf
new file mode 100644
index 000..07b7832
Binary files /dev/null and b/vcl/qa/cppunit/wmf/data/line_styles.emf differ
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 6e595c0..2a1a341 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -43,6 +43,7 @@ public:
 void testNonPlaceableWmf();
 void testSine();
 void testEmfProblem();
+void testEmfLineStyles();
 void testWorldTransformFontSize();
 void testTdf93750();
 
@@ -50,6 +51,7 @@ public:
 CPPUNIT_TEST(testNonPlaceableWmf);
 CPPUNIT_TEST(testSine);
 CPPUNIT_TEST(testEmfProblem);
+CPPUNIT_TEST(testEmfLineStyles);
 CPPUNIT_TEST(testWorldTransformFontSize);
 CPPUNIT_TEST(testTdf93750);
 
@@ -120,6 +122,50 @@ void WmfTest::testEmfProblem()
 assertXPath(pDoc, "/metafile/sectrectclipregion[1]", "right", "1876");
 }
 
+void WmfTest::testEmfLineStyles()
+{
+SvFileStream aFileStream(getFullUrl("line_styles.emf"), StreamMode::READ);
+GDIMetaFile aGDIMetaFile;
+ReadWindowMetafile(aFileStream, aGDIMetaFile);
+
+MetafileXmlDump dumper;
+dumper.filterAllActionTypes();
+dumper.filterActionType(MetaActionType::LINE, false);
+dumper.filterActionType(MetaActionType::LINECOLOR, false);
+xmlDocPtr pDoc = dumper.dumpAndParse(aGDIMetaFile);
+
+CPPUNIT_ASSERT (pDoc);
+
+assertXPath(pDoc, "/metafile/line", 4);
+assertXPath(pDoc, "/metafile/linecolor", 5);
+
+assertXPath(pDoc, "/metafile/linecolor[1]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[2]", "color", "#00ff00");
+assertXPath(pDoc, "/metafile/linecolor[3]", "color", "#408080");
+assertXPath(pDoc, "/metafile/linecolor[4]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[5]", "color", "#ff");
+
+assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
+assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+
+assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+
+assertXPath(pDoc, "/metafile/line[3]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[3]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[3]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[3]", "distance", "90");
+
+assertXPath(pDoc, "/metafile/line[4]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[4]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[4]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[4]", "distance", "50");
+};
+
 void WmfTest::testWorldTransformFontSize()
 {
 SvFileStream aFileStream(getFullUrl("image1.emf"), StreamMode::READ);
diff --git a/vcl/source/filter/wmf/enhwmf.cxx b/vcl/source/filter/wmf/enhwmf.cxx
index f130fad..470e1b2 100644
--- a/vcl/source/filter/wmf/enhwmf.cxx
+++ b/vcl/source/filter/wmf/enhwmf.cxx
@@ -998,20 +998,38 @@ bool EnhWMFReader::ReadEnhWMF()
 aLineInfo.SetWidth( nWidth );

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

2016-03-02 Thread Stephan van den Akker 
 test/source/mtfxmldump.cxx   |   28 ++-
 vcl/qa/cppunit/wmf/wmfimporttest.cxx |   16 +++
 vcl/source/filter/wmf/enhwmf.cxx |   36 +--
 vcl/source/filter/wmf/winmtf.hxx |9 
 4 files changed, 82 insertions(+), 7 deletions(-)

New commits:
commit fe3ac0788666294eff66bb999f68e9cce9c3169e
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Wed Mar 2 00:17:03 2016 +0100

Fix the import of line joins and caps from EMF files

Change-Id: I976336d35366b661e402db484820b4dd9a7b0228
Reviewed-on: https://gerrit.libreoffice.org/22821
Reviewed-by: Tomaž Vajngerl <qui...@gmail.com>
Tested-by: Tomaž Vajngerl <qui...@gmail.com>

diff --git a/test/source/mtfxmldump.cxx b/test/source/mtfxmldump.cxx
index 51264b9..2aab2fa 100644
--- a/test/source/mtfxmldump.cxx
+++ b/test/source/mtfxmldump.cxx
@@ -124,6 +124,29 @@ OUString convertLineStyleToString(LineStyle eAlign)
 return OUString();
 }
 
+OUString convertLineJoinToString(basegfx::B2DLineJoin eJoin)
+{
+switch (eJoin)
+{
+default:
+case basegfx::B2DLineJoin::NONE:return OUString("none");
+case basegfx::B2DLineJoin::Bevel:   return OUString("bevel");
+case basegfx::B2DLineJoin::Miter:   return OUString("miter");
+case basegfx::B2DLineJoin::Round:   return OUString("round");
+}
+}
+
+OUString convertLineCapToString(css::drawing::LineCap eCap)
+{
+switch (eCap)
+{
+default:
+case css::drawing::LineCap_BUTT:   return OUString("butt");
+case css::drawing::LineCap_ROUND:  return OUString("round");
+case css::drawing::LineCap_SQUARE: return OUString("square");
+}
+}
+
 OUString convertFontWeigthToString(FontWeight eFontWeight)
 {
 enum FontWeight { WEIGHT_DONTKNOW, WEIGHT_THIN, WEIGHT_ULTRALIGHT,
@@ -282,9 +305,12 @@ void MetafileXmlDump::writeXml(const GDIMetaFile& 
rMetaFile, XmlWriter& rWriter)
 rWriter.attribute("style", 
convertLineStyleToString(aLineInfo.GetStyle()));
 rWriter.attribute("width", aLineInfo.GetWidth());
 rWriter.attribute("dashlen", aLineInfo.GetDashLen());
+rWriter.attribute("dashcount", aLineInfo.GetDashCount());
 rWriter.attribute("dotlen", aLineInfo.GetDotLen());
+rWriter.attribute("dotcount", aLineInfo.GetDotCount());
 rWriter.attribute("distance", aLineInfo.GetDistance());
-
+rWriter.attribute("join", 
convertLineJoinToString(aLineInfo.GetLineJoin()));
+rWriter.attribute("cap", 
convertLineCapToString(aLineInfo.GetLineCap()));
 rWriter.endElement();
 }
 break;
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 2a1a341..32c4d90 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -147,23 +147,39 @@ void WmfTest::testEmfLineStyles()
 
 assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dashcount", "1");
 assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
+assertXPath(pDoc, "/metafile/line[1]", "dotcount", "0");
 assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+assertXPath(pDoc, "/metafile/line[1]", "join", "miter");
+assertXPath(pDoc, "/metafile/line[1]", "cap", "butt");
 
 assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dashcount", "0");
 assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "dotcount", "1");
 assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+assertXPath(pDoc, "/metafile/line[2]", "join", "miter");
+assertXPath(pDoc, "/metafile/line[2]", "cap", "butt");
 
 assertXPath(pDoc, "/metafile/line[3]", "style", "dash");
 assertXPath(pDoc, "/metafile/line[3]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[3]", "dashcount", "1");
 assert

[Libreoffice-commits] core.git: Branch 'libreoffice-5-1' - vcl/qa vcl/source

2016-03-01 Thread Stephan van den Akker 
 vcl/qa/cppunit/wmf/data/line_styles.emf |binary
 vcl/qa/cppunit/wmf/wmfimporttest.cxx|   46 
 vcl/source/filter/wmf/enhwmf.cxx|   36 -
 3 files changed, 70 insertions(+), 12 deletions(-)

New commits:
commit 39b1a23c09231bb61c0196d7ab24cb3e0cac9afc
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Tue Feb 23 11:13:20 2016 +0100

Improve the import of pen styles from EMF files

Change-Id: I643c29befeb29b7b1cdd66375f661f4adb0e6cfa
Reviewed-on: https://gerrit.libreoffice.org/22638
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: David Tardon <dtar...@redhat.com>
(cherry picked from commit 9db34a7712e277389b2041cfbd77a60476d7f7f1)
Reviewed-on: https://gerrit.libreoffice.org/22714
Reviewed-by: Miklos Vajna <vmik...@collabora.co.uk>

diff --git a/vcl/qa/cppunit/wmf/data/line_styles.emf 
b/vcl/qa/cppunit/wmf/data/line_styles.emf
new file mode 100644
index 000..07b7832
Binary files /dev/null and b/vcl/qa/cppunit/wmf/data/line_styles.emf differ
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 6e595c0..2a1a341 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -43,6 +43,7 @@ public:
 void testNonPlaceableWmf();
 void testSine();
 void testEmfProblem();
+void testEmfLineStyles();
 void testWorldTransformFontSize();
 void testTdf93750();
 
@@ -50,6 +51,7 @@ public:
 CPPUNIT_TEST(testNonPlaceableWmf);
 CPPUNIT_TEST(testSine);
 CPPUNIT_TEST(testEmfProblem);
+CPPUNIT_TEST(testEmfLineStyles);
 CPPUNIT_TEST(testWorldTransformFontSize);
 CPPUNIT_TEST(testTdf93750);
 
@@ -120,6 +122,50 @@ void WmfTest::testEmfProblem()
 assertXPath(pDoc, "/metafile/sectrectclipregion[1]", "right", "1876");
 }
 
+void WmfTest::testEmfLineStyles()
+{
+SvFileStream aFileStream(getFullUrl("line_styles.emf"), StreamMode::READ);
+GDIMetaFile aGDIMetaFile;
+ReadWindowMetafile(aFileStream, aGDIMetaFile);
+
+MetafileXmlDump dumper;
+dumper.filterAllActionTypes();
+dumper.filterActionType(MetaActionType::LINE, false);
+dumper.filterActionType(MetaActionType::LINECOLOR, false);
+xmlDocPtr pDoc = dumper.dumpAndParse(aGDIMetaFile);
+
+CPPUNIT_ASSERT (pDoc);
+
+assertXPath(pDoc, "/metafile/line", 4);
+assertXPath(pDoc, "/metafile/linecolor", 5);
+
+assertXPath(pDoc, "/metafile/linecolor[1]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[2]", "color", "#00ff00");
+assertXPath(pDoc, "/metafile/linecolor[3]", "color", "#408080");
+assertXPath(pDoc, "/metafile/linecolor[4]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[5]", "color", "#ff");
+
+assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
+assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+
+assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+
+assertXPath(pDoc, "/metafile/line[3]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[3]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[3]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[3]", "distance", "90");
+
+assertXPath(pDoc, "/metafile/line[4]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[4]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[4]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[4]", "distance", "50");
+};
+
 void WmfTest::testWorldTransformFontSize()
 {
 SvFileStream aFileStream(getFullUrl("image1.emf"), StreamMode::READ);
diff --git a/vcl/source/filter/wmf/enhwmf.cxx b/vcl/source/filter/wmf/enhwmf.cxx
index 5904e09..af35d6d 100644
--- a/vcl/source/filter/wmf/enhwmf.cxx
+++ b/vcl/source/filter/wmf/enhwmf.cxx
@@ -1008,20 +1008,38 @@ bool EnhWMFReader::ReadEnhWMF()
 aLineInfo.SetWidth( nWidth );

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

2016-02-26 Thread Stephan van den Akker 
 vcl/qa/cppunit/wmf/data/line_styles.emf |binary
 vcl/qa/cppunit/wmf/wmfimporttest.cxx|   46 
 vcl/source/filter/wmf/enhwmf.cxx|   36 -
 3 files changed, 70 insertions(+), 12 deletions(-)

New commits:
commit 9db34a7712e277389b2041cfbd77a60476d7f7f1
Author: Stephan van den Akker <stephanv...@gmail.com>
Date:   Tue Feb 23 11:13:20 2016 +0100

Improve the import of pen styles from EMF files

Change-Id: I643c29befeb29b7b1cdd66375f661f4adb0e6cfa
Reviewed-on: https://gerrit.libreoffice.org/22638
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: David Tardon <dtar...@redhat.com>

diff --git a/vcl/qa/cppunit/wmf/data/line_styles.emf 
b/vcl/qa/cppunit/wmf/data/line_styles.emf
new file mode 100644
index 000..07b7832
Binary files /dev/null and b/vcl/qa/cppunit/wmf/data/line_styles.emf differ
diff --git a/vcl/qa/cppunit/wmf/wmfimporttest.cxx 
b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
index 6e595c0..2a1a341 100644
--- a/vcl/qa/cppunit/wmf/wmfimporttest.cxx
+++ b/vcl/qa/cppunit/wmf/wmfimporttest.cxx
@@ -43,6 +43,7 @@ public:
 void testNonPlaceableWmf();
 void testSine();
 void testEmfProblem();
+void testEmfLineStyles();
 void testWorldTransformFontSize();
 void testTdf93750();
 
@@ -50,6 +51,7 @@ public:
 CPPUNIT_TEST(testNonPlaceableWmf);
 CPPUNIT_TEST(testSine);
 CPPUNIT_TEST(testEmfProblem);
+CPPUNIT_TEST(testEmfLineStyles);
 CPPUNIT_TEST(testWorldTransformFontSize);
 CPPUNIT_TEST(testTdf93750);
 
@@ -120,6 +122,50 @@ void WmfTest::testEmfProblem()
 assertXPath(pDoc, "/metafile/sectrectclipregion[1]", "right", "1876");
 }
 
+void WmfTest::testEmfLineStyles()
+{
+SvFileStream aFileStream(getFullUrl("line_styles.emf"), StreamMode::READ);
+GDIMetaFile aGDIMetaFile;
+ReadWindowMetafile(aFileStream, aGDIMetaFile);
+
+MetafileXmlDump dumper;
+dumper.filterAllActionTypes();
+dumper.filterActionType(MetaActionType::LINE, false);
+dumper.filterActionType(MetaActionType::LINECOLOR, false);
+xmlDocPtr pDoc = dumper.dumpAndParse(aGDIMetaFile);
+
+CPPUNIT_ASSERT (pDoc);
+
+assertXPath(pDoc, "/metafile/line", 4);
+assertXPath(pDoc, "/metafile/linecolor", 5);
+
+assertXPath(pDoc, "/metafile/linecolor[1]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[2]", "color", "#00ff00");
+assertXPath(pDoc, "/metafile/linecolor[3]", "color", "#408080");
+assertXPath(pDoc, "/metafile/linecolor[4]", "color", "#ff");
+assertXPath(pDoc, "/metafile/linecolor[5]", "color", "#ff");
+
+assertXPath(pDoc, "/metafile/line[1]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[1]", "dashlen", "225");
+assertXPath(pDoc, "/metafile/line[1]", "dotlen", "0");
+assertXPath(pDoc, "/metafile/line[1]", "distance", "100");
+
+assertXPath(pDoc, "/metafile/line[2]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[2]", "dashlen", "0");
+assertXPath(pDoc, "/metafile/line[2]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[2]", "distance", "50");
+
+assertXPath(pDoc, "/metafile/line[3]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[3]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[3]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[3]", "distance", "90");
+
+assertXPath(pDoc, "/metafile/line[4]", "style", "dash");
+assertXPath(pDoc, "/metafile/line[4]", "dashlen", "150");
+assertXPath(pDoc, "/metafile/line[4]", "dotlen", "30");
+assertXPath(pDoc, "/metafile/line[4]", "distance", "50");
+};
+
 void WmfTest::testWorldTransformFontSize()
 {
 SvFileStream aFileStream(getFullUrl("image1.emf"), StreamMode::READ);
diff --git a/vcl/source/filter/wmf/enhwmf.cxx b/vcl/source/filter/wmf/enhwmf.cxx
index f8341e3..02eebdf 100644
--- a/vcl/source/filter/wmf/enhwmf.cxx
+++ b/vcl/source/filter/wmf/enhwmf.cxx
@@ -1008,20 +1008,38 @@ bool EnhWMFReader::ReadEnhWMF()
 aLineInfo.SetWidth( nWidth );
 
 bool bTransparent = false;
-sal_uInt16 nDashCount = 0;
-sal_uInt16 nDotCount = 0;
 
 swi

Re: [libreoffice-users] Creating High Res Images in Draw or Impress

2015-09-18 Thread Stephan van den Akker 
There is a direct export option to png:

1: Choose File -> Export... from the main menu
2: Choose the desired image format (jpg, png, eps, etc) from the File
Format drop down list
3: When choosing png a dialog appears where you can set the resolution
4: Mark the Width and Height
5: Increase the resolution to the desired value.
Notice that the width and height are decreased (Developers logic)
6: Set the Width and Height back to the original values
7: Press OK

Voila, a high res image of your drawing!

2015-09-18 12:42 GMT+02:00 Zsolt Varga :
> Hi,
>
> I think the only method getting high resolution images from draw is to
> first export the drawing to pdf with checked option ,,lossles compression".
> Here you can also adjust the real resolution of the output file (75, 150,
> 300. 600, 1200 dpi).
>
> After that you have to import it to Adobe Photoshop or other image
> proccesing program
> and save it as jpg, tiff, etc.
>
> Regards,
> Zsolt
>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Request to modify Commit #7142 about CSV import

2013-12-20 Thread Stephan van den Akker 
Hi Eike,

Thanks for the info. Using csv files in the Netherlands, with a mix of
computers and a mix of software using different locale settings to
write them, is a nightmare. The present csv handling in Calc is a
bright spot that I cherish and love.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Request to modify Commit #7142 about CSV import

2013-12-19 Thread Stephan van den Akker 
Laurent BP stated:
 This is a problem for all locales which uses comma as decimal separator. In
 this cases, even if .CSV files are used, the comma cannot be used as
 column separator.

Eike Rathke replied:
 Not true. The comma can still be used as separator, just the field
 values need to be enquoted if they contain a comma. Which we do.

Enquoting values may be done by LO, but lots of third party programs do not.
Dutch software often produces files with commas for decimal separators and
other characters as field separators (e.g. semicolons).

As stupid as this may seem, even software provided by the Dutch government
(like http://car.infomil.nl) works like this.

I'm afraid Calc will be rendered almost useless for Dutch users if un-enquoted
commas are treated as field separators...
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: callgrind metrics was: Re: minutes of ESC call ...

2013-12-06 Thread Stephan van den Akker 
Good question, Matúš

I have been thinking about that also, and was thinking of asking the
qa people for a list of file load/save complaints from fdo.

The test ods should definitely have a graph in it. That is always a
speed bottleneck in Calc. Unfortunately some of the interpretation of
the graph data is deferred now until the user clicks the graph. That
means that some of the biggest loading bottleneck will not be measured
by loperf.

The idea was once to have loperf produce a single perfomance
indicator, and present that as a graph somewhere of the performance
over time. Only retain the underlying data for a short time for dev's
interested in the causes of performance regressions.

Greetings,

Stephan

2013/12/6 Matúš Kukan matus.ku...@gmail.com:
 On Thu, 2013-12-05 at 17:23 +, Michael Meeks wrote:
 * Pending Action Items:
 + actually produce callgrind performance metrics from VM (Matus)

 So - it's running and producing callgrind profiles - Is it possible
 somebody would be interested in them ? They are deleted after 10 days,
 so that should be enough in that case I hope.

 And the result (attached) is something like:
 date git-commit CEst-for-file1 CEst-for-file2 ..

 What files should it test ?
 Currently it's empty.ods, empty.odt, and sample.xlsx - just some numbers
 in there.
 There can't be too many files nor big ones,  otherwise it takes too much
 time.

 Any ideas how to make this useful for you ?
 Btw. it's in buildbot.git/loperf

 Where should I upload this history.csv ?
 Post to the list once in a week, or..?

 Thanks,
 Matus

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

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

Re: build difficulty

2013-08-29 Thread Stephan van den Akker 
Hi Terry and Kohei,

Running openSUSE 11.4 as well, having the same problem as you two.
Over on #libreoffice-dev the suggestion was that my compiler and my
system boost libs are too old. I'm currently trying their suggestion
of:
1 - building boost 1.47 from source
2 - building LO with this boost version

I chose boost version 1.47 because is is the oldest version that has
all the functionality needed by LO. I is old enough to be compatible
with my compiler.

Kohei: Can you explain what your change does? I might try that too.

2013/8/29 Kohei Yoshida kohei.yosh...@suse.de:
 On 08/29/2013 09:56 AM, dk...@torfree.net wrote:

 I am unable to build (after `make clean`) master 139a7d2 (pulled today
 around 12:30 UTC). The messages are, line-wrapped for e-mail, ...

 /home/terry/lo_hacking/git/libo2/workdir/unxlngi6/UnpackedTarball/
 boost/boost/noncopyable.hpp:27:21:
 error: ‘boost::noncopyable_::noncopyable::noncopyable()’ declared
 with non-public access cannot be defaulted in the class body
 /home/terry/lo_hacking/git/libo2/workdir/unxlngi6/UnpackedTarball/
 boost/boost/noncopyable.hpp:28:22:
 error: ‘boost::noncopyable_::noncopyable::~noncopyable()’
 declared with non-public access cannot be defaulted in the class body

 I have to suspect that this has something to do with commit 4910c54
 Update the bundled boost to 1.54 combined with the fact that I am
 building on an old release, ubuntu-natty (11.04) 32-bit.

 Suggestions welcome.


 Try this change

 diff --git a/solenv/gbuild/platform/com_GCC_defs.mk
 b/solenv/gbuild/platform/com_GCC_defs.mk
 index c9adf88..4b7e413 100644
 --- a/solenv/gbuild/platform/com_GCC_defs.mk
 +++ b/solenv/gbuild/platform/com_GCC_defs.mk
 @@ -66,6 +66,7 @@ gb_CXXFLAGS_COMMON := \
 -fmessage-length=0 \
 -fno-common \
 -pipe \
 + -DBOOST_NO_DEFAULTED_FUNCTIONS \

 ifneq ($(HAVE_THREADSAFE_STATICS),TRUE)
 gb_CXXFLAGS_COMMON += -fno-threadsafe-statics

 I'm having the same issue on my machine running a slightly antiquated
 version of openSUSE (11.4), and this change fixes it for me.

 Kohei

 --
 Kohei Yoshida, LibreOffice Calc hacker, SUSE.


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

Re: build difficulty

2013-08-29 Thread Stephan van den Akker 
Kohei, don't let me down. I spend most of the day educating the masses
on #libreoffice-dev that 11.4 is not *antiquated* of *end of life*,
but beautifully Evergreen.

2013/8/29 Kohei Yoshida kohei.yosh...@suse.de:
 On 08/29/2013 03:30 PM, Kohei Yoshida wrote:

 On 08/29/2013 03:27 PM, Stephan van den Akker wrote:

 Kohei: Can you explain what your change does? I might try that too.

 No idea exactly, other than that it avoids the lines that cause error in
 my build.  I got the idea by reading the offending boost header file
 boost/boost/noncopyable.hpp.


 Having said that, if I were to guess, I think that macro would avoid using
 the new C++11 only syntax that boost now uses by default, and achieves the
 same effect using the pre-C++11 syntax equivalent.

 Normally we would add some sort of configure check for such C++11 syntax and
 take appropriate steps.  But since by my own admission I'm running an OS
 that's considered too old, I just use my local fix to get around this
 problem.  And I really really need to upgrade my openSUSE installation on my
 machine... ;-)


 Kohei

 --
 Kohei Yoshida, LibreOffice Calc hacker, SUSE.

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

Re: [PUSHED] Add NSAXSpy to help debugging OS X accessibility

2013-07-30 Thread Stephan van den Akker 
Cool,

Is this the patch where I can flag any of my colleagues as enemy of the
state from within LO so they get a free trip to a nice bay in Cuba?


2013/7/28 Boris Dušek (via Code Review) ger...@gerrit.libreoffice.org

 Hi,

 Thank you for your patch!  It has been merged to LibreOffice.

 If you are interested in details, please visit

 https://gerrit.libreoffice.org/5160

 Approvals:
   Boris Dušek: Verified; Looks good to me, approved


 --
 To view, visit https://gerrit.libreoffice.org/5160
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: merged
 Gerrit-Change-Id: Ia7f4dbed4924b8f5330726d378eda3601991f404
 Gerrit-PatchSet: 2
 Gerrit-Project: dev-tools
 Gerrit-Branch: master
 Gerrit-Owner: Boris Dušek m...@dusek.me
 Gerrit-Reviewer: Boris Dušek m...@dusek.me

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

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

Re: some file format spec problems with the OOXML chart import/export

2013-05-02 Thread Stephan van den Akker 
Marcus,

If you like, I can test documents for you in MSO 2007 and send screenshots.
It's a version without any service packs installed - the oldest MSO version
that natively reads and writes OOXML.


2013/5/2 Michael Stahl mst...@redhat.com

 On 02/05/13 00:24, Markus Mohrhard wrote:
  Hey,
 
  so I have been fixing some chart OOXML issues recently and there are
  some general problems.
 
  There are a number of comments like (from typegroupcontext.cxx:147)
  // default is 'false', not 'true' as specified
  but testing this in Excel showed that Excel respects the standard in
  contrast to our import and export. Does anyone know why these comments
  have been introduced or does anyone have a reason why we should not
  fix this stuff? I already fixed a few of these problems that made my
  simple test document look awful when being imported into Excel.

 no idea; perhaps it is the case that different versions (or even
 different patch levels) of MSO have different defaults?

  If there is nobody opposing it I will slowly fix these issues in the
  chart import/export where I see them. Sadly there is no way to
  automatically test these things as they are wrong in the import and
  the export filter. The only way is to check the OOXML standard and
  check how our exported documents look in MSO.

 if in doubt i guess it can't hurt to write the explicit value and not
 rely on any defaults.


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

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

Re: [PATCH] fdo#47018 fix Impress crash on modifying bullet

2013-04-12 Thread Stephan van den Akker 
Hi, Cao,

Just checked your patch (Change-Id:
I57d1245db650d12e6b2c05baece379038b673689) merged with:

Version: 4.1.0.0.alpha0+
Build ID: 0b897dd455968862e348de2c5e1c57d4d73640b

This patch indeed fixes all of the problems mentioned in fdo#47018,
including the crash.

Brilliant. Thanks a lot, Cao!

AFAIK the patched code is used in Impress, but also in Calc and Draw. I'll
be running this build at the office for a couple of days. I'll let you know
if I notice any unwanted side effects in other use cases.

Greetings,

Stephan


2013/4/12 Stephan van den Akker stephanv...@gmail.com

 Hi Cao,

 That sounds great!

 Building LO now with your patch. Stay tuned

 Greetings,

 Stephan




 2013/4/12 Cao Cuong Ngo cao.cuong@gmail.com


 Hi Stephan,

 Thanks for taking the time to test it :-)

 I've made a new patch that fixes the crash and the copy/paste action.

 You can try it here

 https://gerrit.libreoffice.org/3352

 Best,
 Cao Cuong Ngo


 On 04/09/2013 05:05 PM, Stephan van den Akker wrote:

   Just tested this patch, applied to:

 Version: 4.1.0.0.alpha0+
 Build ID: 2705fc72df2058332773b5cb04a6b4d207f5e39

  The proposed patch will prevent the crash, but it seems that the
 underlying problem is not solved by this:
 The bullets do not survive the copy / paste action of the
 EditEngineFormat: Copy/paste of bulletted text into an already bulletted
 empty line still makes the bullet disappear.

  So I would say that there is progress, but IMHO the patch doesn't
 warrant the closing of fdo#47018.

  Greetings, and thanks for the good work.

  Stephan van den Akker


 2013/4/9 Stephan van den Akker stephanv...@gmail.com

 Building LO with this patch now. I will report my findings asap.


 2013/4/9 Cao Cuong Ngo (via Code Review) ger...@gerrit.libreoffice.org

 Hi,

 I have submitted a patch for review:

 https://gerrit.libreoffice.org/3285

 To pull it, you can do:

 git pull ssh://gerrit.libreoffice.org:29418/corerefs/changes/85/3285/1

 fdo#47018 fix Impress crash on modifying bullet

 Add verifying of numbering rule to avoid invalidated attribute

 Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 ---
 M sd/source/ui/func/fuolbull.cxx
 1 file changed, 11 insertions(+), 1 deletion(-)



 diff --git a/sd/source/ui/func/fuolbull.cxx
 b/sd/source/ui/func/fuolbull.cxx
 index ae29032..49fd245 100644
 --- a/sd/source/ui/func/fuolbull.cxx
 +++ b/sd/source/ui/func/fuolbull.cxx
 @@ -22,6 +22,7 @@
  #include svl/intitem.hxx
  #include editeng/outliner.hxx
  #include editeng/eeitem.hxx
 +#include editeng/numitem.hxx
  #include sfx2/request.hxx

  #include editeng/editdata.hxx
 @@ -64,7 +65,16 @@

  SfxItemSet aNewAttr( mpViewShell-GetPool(),
   EE_ITEMS_START, EE_ITEMS_END );
 -aNewAttr.Put( aEditAttr, sal_False );
 +
 +// fdo#47018 verify numbering rule
 +const SfxPoolItem* pItem;
 +sal_uInt16 nWhich =
 aEditAttr.GetPool()-GetWhich(SID_ATTR_NUMBERING_RULE);
 +aEditAttr.GetItemState(nWhich, sal_False, pItem);
 +const sal_uInt16 levelCount =
 (*((SvxNumBulletItem*)pItem)-GetNumRule()).GetLevelCount();
 +
 +// check if the attribute is valid
 +if ( levelCount )
 +aNewAttr.Put( aEditAttr, sal_False );

  // create and execute dialog
  SdAbstractDialogFactory* pFact =
 SdAbstractDialogFactory::Create();

 --
 To view, visit https://gerrit.libreoffice.org/3285
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: newchange
 Gerrit-Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 Gerrit-PatchSet: 1
 Gerrit-Project: core
 Gerrit-Branch: master
 Gerrit-Owner: Cao Cuong Ngo cao.cuong@gmail.com

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






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

Re: [PATCH] fdo#47018 fix Impress crash on modifying bullet

2013-04-09 Thread Stephan van den Akker 
Building LO with this patch now. I will report my findings asap.


2013/4/9 Cao Cuong Ngo (via Code Review) ger...@gerrit.libreoffice.org

 Hi,

 I have submitted a patch for review:

 https://gerrit.libreoffice.org/3285

 To pull it, you can do:

 git pull ssh://gerrit.libreoffice.org:29418/corerefs/changes/85/3285/1

 fdo#47018 fix Impress crash on modifying bullet

 Add verifying of numbering rule to avoid invalidated attribute

 Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 ---
 M sd/source/ui/func/fuolbull.cxx
 1 file changed, 11 insertions(+), 1 deletion(-)



 diff --git a/sd/source/ui/func/fuolbull.cxx
 b/sd/source/ui/func/fuolbull.cxx
 index ae29032..49fd245 100644
 --- a/sd/source/ui/func/fuolbull.cxx
 +++ b/sd/source/ui/func/fuolbull.cxx
 @@ -22,6 +22,7 @@
  #include svl/intitem.hxx
  #include editeng/outliner.hxx
  #include editeng/eeitem.hxx
 +#include editeng/numitem.hxx
  #include sfx2/request.hxx

  #include editeng/editdata.hxx
 @@ -64,7 +65,16 @@

  SfxItemSet aNewAttr( mpViewShell-GetPool(),
   EE_ITEMS_START, EE_ITEMS_END );
 -aNewAttr.Put( aEditAttr, sal_False );
 +
 +// fdo#47018 verify numbering rule
 +const SfxPoolItem* pItem;
 +sal_uInt16 nWhich =
 aEditAttr.GetPool()-GetWhich(SID_ATTR_NUMBERING_RULE);
 +aEditAttr.GetItemState(nWhich, sal_False, pItem);
 +const sal_uInt16 levelCount =
 (*((SvxNumBulletItem*)pItem)-GetNumRule()).GetLevelCount();
 +
 +// check if the attribute is valid
 +if ( levelCount )
 +aNewAttr.Put( aEditAttr, sal_False );

  // create and execute dialog
  SdAbstractDialogFactory* pFact =
 SdAbstractDialogFactory::Create();

 --
 To view, visit https://gerrit.libreoffice.org/3285
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: newchange
 Gerrit-Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 Gerrit-PatchSet: 1
 Gerrit-Project: core
 Gerrit-Branch: master
 Gerrit-Owner: Cao Cuong Ngo cao.cuong@gmail.com

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

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

Re: [PATCH] fdo#47018 fix Impress crash on modifying bullet

2013-04-09 Thread Stephan van den Akker 
Just tested this patch, applied to:

Version: 4.1.0.0.alpha0+
Build ID: 2705fc72df2058332773b5cb04a6b4d207f5e39

The proposed patch will prevent the crash, but it seems that the underlying
problem is not solved by this:
The bullets do not survive the copy / paste action of the EditEngineFormat:
Copy/paste of bulletted text into an already bulletted empty line still
makes the bullet disappear.

So I would say that there is progress, but IMHO the patch doesn't warrant
the closing of fdo#47018.

Greetings, and thanks for the good work.

Stephan van den Akker


2013/4/9 Stephan van den Akker stephanv...@gmail.com

 Building LO with this patch now. I will report my findings asap.


 2013/4/9 Cao Cuong Ngo (via Code Review) ger...@gerrit.libreoffice.org

 Hi,

 I have submitted a patch for review:

 https://gerrit.libreoffice.org/3285

 To pull it, you can do:

 git pull ssh://gerrit.libreoffice.org:29418/corerefs/changes/85/3285/1

 fdo#47018 fix Impress crash on modifying bullet

 Add verifying of numbering rule to avoid invalidated attribute

 Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 ---
 M sd/source/ui/func/fuolbull.cxx
 1 file changed, 11 insertions(+), 1 deletion(-)



 diff --git a/sd/source/ui/func/fuolbull.cxx
 b/sd/source/ui/func/fuolbull.cxx
 index ae29032..49fd245 100644
 --- a/sd/source/ui/func/fuolbull.cxx
 +++ b/sd/source/ui/func/fuolbull.cxx
 @@ -22,6 +22,7 @@
  #include svl/intitem.hxx
  #include editeng/outliner.hxx
  #include editeng/eeitem.hxx
 +#include editeng/numitem.hxx
  #include sfx2/request.hxx

  #include editeng/editdata.hxx
 @@ -64,7 +65,16 @@

  SfxItemSet aNewAttr( mpViewShell-GetPool(),
   EE_ITEMS_START, EE_ITEMS_END );
 -aNewAttr.Put( aEditAttr, sal_False );
 +
 +// fdo#47018 verify numbering rule
 +const SfxPoolItem* pItem;
 +sal_uInt16 nWhich =
 aEditAttr.GetPool()-GetWhich(SID_ATTR_NUMBERING_RULE);
 +aEditAttr.GetItemState(nWhich, sal_False, pItem);
 +const sal_uInt16 levelCount =
 (*((SvxNumBulletItem*)pItem)-GetNumRule()).GetLevelCount();
 +
 +// check if the attribute is valid
 +if ( levelCount )
 +aNewAttr.Put( aEditAttr, sal_False );

  // create and execute dialog
  SdAbstractDialogFactory* pFact =
 SdAbstractDialogFactory::Create();

 --
 To view, visit https://gerrit.libreoffice.org/3285
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: newchange
 Gerrit-Change-Id: Ifc3db3f09f9358d272245f1e00fad2802f5881ee
 Gerrit-PatchSet: 1
 Gerrit-Project: core
 Gerrit-Branch: master
 Gerrit-Owner: Cao Cuong Ngo cao.cuong@gmail.com

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



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

Re: XSLX import/export filter funding

2013-03-11 Thread Stephan van den Akker 
Hi Runar,

Currently I am working on a set of test cases for speed testing file
opening and importing in Libre Office. The plan is to have these tests
running on the servers that regularly build LO and provide feedback to the
developers about speed regressions and improvements.

I am very interested in the XLSX files that give you problems. Could you
send them to me? I may be able to incorporate problematic aspects in my
test cases.

Thanks in advance.

Stephan van den Akker


2013/3/8 Runar Ingebrigtsen ru...@rin.no

  Hi everyone,

 I am having the pleasure of deploying LibreOffice to 50 employees at a
 local business.

 Unfortunately, this is hampered by the performance of the xlsx
 import/export filters.
 Meaning that there are some files, even simple ones, that takes extremely
 long time to open.
 The same files opens just fine and in seconds in Calligra, for instance.

 There are several bugs describing this issue or similar ones:
 https://bugs.freedesktop.org/show_bug.cgi?id=30770
 https://bugs.freedesktop.org/show_bug.cgi?id=56259
 https://bugs.freedesktop.org/show_bug.cgi?id=56394
 https://bugs.freedesktop.org/show_bug.cgi?id=61721

 I have started a sponsoring offer for this, and am looking for
 participants:
 http://www.freedomsponsors.org/core/offer/221

 Besides, I am trying to get the local business to join the sponsoring.

 I can provide more test cases with real world documents, but not in public.

 --
 Best Regards
 Runar Ingebrigtsen

 http://rin.no/

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


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

Re: liborcus sources website

2012-12-11 Thread Stephan van den Akker 
Hi John,

If I recall correctly, during make the liborcus source will be pulled in
from a Libre Office server. Just  make sure you have an internet connection.


2012/12/11 John Smith lbalba...@gmail.com

 Hi,


 I see a LibreOffice build has a pre-req for 'liborcus-0.4'. However,
 my Fedora system has no packages for that. Does anyone know what the
 website of that is, so I can download and install the sources ? I
 tried a quick google, but couldnt find it.

 Thanks.


 Regards,


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

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

Re: callgrind / profiling ...

2012-12-06 Thread Stephan van den Akker 
The next couple of days I'll work on the automation of producing a graphing
of this magic number.

Also I'm doing repeat testing now to get a feeling of the kind of spread in
the numbers that cachegrind is producing.

Stephan


2012/12/5 Michael Meeks michael.me...@suse.com

 Hi guys,

 Forwarding Josef's rather interesting mail (with permission) to
 the dev
 list - since it's generally useful :-) Stephan is working on plugging a
 nice callgrinding script into tinderbox building so we can build an
 automated performance tracker that will catch even small - 0.5% type
 performance regressions which can accumulate over time - and do it in a
 reproducible way, independent of the underlying hardware.

 Thanks so much for working on this Stephan; it seems the punch-line
 formula for the magic number should be:

  Actually, what I have in recent versions of {Q,K}Cachegrind is this:
   CEst = Ir + 10 Bm + 10 L1m + 20 Ge + 100 L2m + 100 LLm

 ATB !

 Michael.

  Forwarded Message 

 Hi,

 Am 04.12.2012 15:07, schrieb Julian Seward:
 
  Josef,
  Gruesse.  See below ..
 
  Michael:
  Josef is the expert on this, so forwarding it to him.
 
  It used to be 1 * #insns + 10 * #L1 misses + 100 * #L2 misses,
  but I wouldn't put too much reliance on it.  It was just something
  that (IIRC!) NickN and I kludged up during a coffee break probably
  about a decade ago at cl.cam.ac.uk.  Like so many other bits of
  Valgrind :-) (*)

 AFAIK, Cachegrind always just printed out the raw event numbers.
 Also, nowhere in Callgrind you will find that magic formula ;-)
 I think I actually was the one who came up with that formula as
 a rough Cycle Estimation in KCachegrind ;-)

 Actually, doing a somehow accurate time estimation is quite tricky.
 The rule of thumb should be: If you come up with an optimization
 reducing miss numbers (and also the time estimation formula above),
 always also check against real time.

 In general, any estimation using cache metrics gets more accurate
 the worse the cache behavior of the application, as time needed
 for memory accesses is more predictable and hides any smaller latencies
 within a core, especially with out-of-order execution, and even
 ARM application cores are out-of-order nowadays (Cortex A9/A15).

 The most accurate thing next to real measurement would be cycle-accurate
 simulation, which of course is out of scope. There is some nice work
 on a simpler, yet quite accurate processor timing model using so-called
 interval simulation, as implemented in the Sniper simulator
 (see http://snipersim.org). However, it's roughly an order of magnitude
 slower than Cachegrind/Callgrind.

 The biggest issues with the simple formulas above are:
 (1) Hardware prefetching is not taken into account, which often allows
 streaming of data at maximum bandwidth from memory,
 (2) Latency hiding effects are not included, e.g. it easily can happen
 that with lots of memory accesses, it does not matter if the code
 actually was compiled with -O3 or -O0. Further, it can make
 a huge difference whether two consecutive memory accesses depend on each
 other or not (ie. one hiding the latency of the other or not).
 (3) Saturation effects are not taken into account. E.g. if all cores
 on a multicore chip do memory accesses at the same time, the limited
 bandwidth going off-chip will slow down each of them.

 Thus, the accuracy of the simple formula very much depends on an
 average application behavior, in the hope that the difficult
 effects mentioned above do not play too much of a role each.

 BTW, one can argue whether L1/LL misses on write should appear in
 the formula at all. Writes usually are done by the hardware in the
 background. However, if there is a memcpy operation doing a lot
 of consecutive writes, write buffers will fill up, and will
 throttle execution in the end.

   That said, I am sure it got checked by Josef :-)

 Despite above issues, I still think that it is useful to combine
 the cache simulation results into one value. It makes it easier to
 get an overview regarding the cache behavior.

 The thing is: too make time estimation more accurate, you need to
 extend the model, which results in slower simulation.
 I have some ideas to make the cache model more accurate for time
 estimation, but I am not sure it is worth it (real measurements
 are faster anyway).

 E.g. there is an optional hardware prefetch simulation in Callgrind.
 We can introduce a new event LL miss detected by prefetcher, and
 give this e.g. a much lower penalty, depending on the bandwidth your
 hardware can do: e.g. if you can do 1GB/s on a 1GHz processor, this
 means 1 bytes on average per clock, thus with a 64byte line size
 one line can be fetched every 64 cycles. As every LL miss will also
 be a L1 miss (with penalty of 10), you would go for around 50 for
 the penalty for the new prefetchable memory access event.

 For latency effects, it gets more complicated as

Re: Build failures of LO master on openSUSE

2012-11-30 Thread Stephan van den Akker 
No, but I did use autogen (...) --without-help

And to be more precise: building works, but make dev-install fails, even
on a freshly cloned tree.


2012/11/30 Eike Rathke er...@redhat.com

 Hi Stephan,

 On Wednesday, 2012-11-28 15:21:32 +0100, Stephan van den Akker wrote:

  : WARNING: Source for swriter_en-US.zip not found!
  : WARNING: Source for swriter_en-US.zip not found!
  : WARNING: Using swriter_en-US.zip instead of swriter_en-US.zip was not
  successful
 
  Looks to me like some i18n files are missing. Anyone have an idea how to
  solve this?

 Missing files are help content, e.g. should be built in
 ./helpcontent2/unxlngx6.pro/bin/swriter_en-US.zip

 and delivered to
 ./solver/unxlngx6.pro/pck/swriter_en-US.zip

 Did you by chance configure --without-helppack-integration ?

   Eike

 --
 LibreOffice Calc developer. Number formatter stricken i18n
 transpositionizer.
 GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
 Support the FSFE, care about Free Software!
 https://fsfe.org/support/?erack

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

Re: Build failures of LO master on openSUSE

2012-11-30 Thread Stephan van den Akker 
Magically the dev-install just started working again. Thanks all for the
advice!


2012/11/30 Stephan van den Akker stephanv...@gmail.com

 No, but I did use autogen (...) --without-help

 And to be more precise: building works, but make dev-install fails, even
 on a freshly cloned tree.



 2012/11/30 Eike Rathke er...@redhat.com

 Hi Stephan,

 On Wednesday, 2012-11-28 15:21:32 +0100, Stephan van den Akker wrote:

  : WARNING: Source for swriter_en-US.zip not found!
  : WARNING: Source for swriter_en-US.zip not found!
  : WARNING: Using swriter_en-US.zip instead of swriter_en-US.zip was not
  successful
 
  Looks to me like some i18n files are missing. Anyone have an idea how to
  solve this?

 Missing files are help content, e.g. should be built in
 ./helpcontent2/unxlngx6.pro/bin/swriter_en-US.zip

 and delivered to
 ./solver/unxlngx6.pro/pck/swriter_en-US.zip

 Did you by chance configure --without-helppack-integration ?

   Eike

 --
 LibreOffice Calc developer. Number formatter stricken i18n
 transpositionizer.
 GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
 Support the FSFE, care about Free Software!
 https://fsfe.org/support/?erack



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

Re: Build failures of LO master on openSUSE

2012-11-29 Thread Stephan van den Akker 
Yes, I'm using ./g pull -r

But thanks for checking!

Stephan


2012/11/29 Winfried Donkers w.donk...@dci-electronics.nl

 Hi Stephan,

 Found some lines:
 
 : WARNING: Source for shared_en-US.zip not found!
  ...
 Looks to me like some i18n files are missing. Anyone have an idea how to
 solve this?

 Did you use git pull -r to update or ./g pull -r? The latter also updates
 submodules such as the language packs.
 It solved an identical problem I had in the past.

 HTH, Winfried

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

Re: [ANNOUNCE] Python 3.3 is now bundled with LibreOffice 4.0

2012-11-28 Thread Stephan van den Akker 
Hi all,

I'm having similar problems with my build on 32 bit openSUSE 12.2 and
64-bit openSUSE 11.4. I noticed that early in the build of python 3.3 that
the gcc compiler on both platforms gives error messages complaining about
unknown options (-R on the 32 bit system). This almost certainly means
missing .o or .so files


2012/11/28 Alex Thurgood alex.thurg...@gmail.com

 Le 27/11/2012 17:11, Michael Stahl a écrit :

 Hi Michael,

 
  with the commit 38a22a9026a3d8a67f3e16ec650960a10b527d25 Switch from
  python to python3 Python 3.3 is now bundled with LibreOffice when
  configured --enable-python=internal.
 

 This fails to build for me on master on Linux 32bit Mint 13 KDE. I used
 the default provided, ie. no autogen switch, so it downloads the 3.3
 bundle, but gives the following error when attempting to build the module :

 Python build finished, but the necessary bits to build these modules
 were not found:
 _dbm   _gdbm  _lzma
 _tkinter
 To find the necessary bits, look in setup.py in detect_modules() for the
 module's name.


 Failed to build these modules:
 _elementtree   _sqlite3   pyexpat

 [build PRJ] python3
 /bin/cp: impossible d'évaluer
 «/home/Development/libo/workdir/
 unxlngi6.pro/UnpackedTarball/python3/LO_lib/_elementtree.cpython-33m.so»:
 Aucun fichier ou dossier de ce type
 make[2]: ***
 [/home/Development/libo/solver/
 unxlngi6.pro/lib/python/lib-dynload/_elementtree.cpython-33m.so]
 Erreur 1
 make[2]: *** Attente des tâches non terminées
 make[2]: quittant le répertoire « /home/Development/libo/python3 »
 make[1]: *** [python3] Erreur 2
 make[1]: quittant le répertoire « /home/Development/libo »
 make: *** [python3] Erreur 2


 So for some reason, _elementtree.cpython-33m.so is not being built or
 not being found, possibly due to the other missing python 3 modules ?

 Alex



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

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

Re: [ANNOUNCE] Python 3.3 is now bundled with LibreOffice 4.0

2012-11-28 Thread Stephan van den Akker 
Still getting errors on my 64-bit openSUSE system.

did:

rm solver/unxlngx6.pro/inc/external/expat/expat.h
make python3.clean
make python3

(...)

creating Makefile
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
gcc: unrecognized option '-R/usr/lib64'
/home/stephan/Software/libreoffice-master/core/workdir/
unxlngx6.pro/UnpackedTarball/python3/Modules/_curses_panel.c:17:19: fatal
error: panel.h: No such file or directory
compilation terminated.

(...)

Python build finished, but the necessary bits to build these modules were
not found:
_lzma  _tkinter
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.


Failed to build these modules:
_curses_panel

[build PRJ] python3
[build PKG] python3
[build EPK] python3
[build MOD] python3
[build ALL] top level modules: python3
[build ALL] loaded modules: python3


make[2]: Leaving directory
`/home/stephan/Software/libreoffice-master/core/python3'
make[1]: Leaving directory `/home/stephan/Software/libreoffice-master/core'




2012/11/28 Olivier Hallot olivier.hal...@documentfoundation.org

 Although the fix for expat and element—tree is is removing dirty expat
 from solenv/, Lightproof is not operational. I did a clean dev-install and
 ./soffice console shows the issue.
 Olivier
 Em 27/11/2012 14:11, Michael Stahl mst...@redhat.com escreveu:


 with the commit 38a22a9026a3d8a67f3e16ec650960a10b527d25 Switch from
 python to python3 Python 3.3 is now bundled with LibreOffice when
 configured --enable-python=internal.

 with the commit 602b746330d21ae1b9c0fc60eb0980ed92cd5680 configure:
 switch system Python minimum to 3.3 the minimum version for a system
 Python (when using --enable-python=system) has been raised to 3.3;
 however for a transition period of a few releases it will still be
 possible to use a Python 2 version 2.6 or later, by explicitly setting
 PYTHON, PYTHON_CFLAGS, PYTHON_LIBS variables.

 there are currently no known issues with pyuno (remotely) and Python
 Script Provider when running on Python 3.

 there are still some bits of Python code that are not yet ported to run
 on Python 3, such as the email sending stuff in scripting/source/pyprov/
 and LightProof but hopefully we'll get that done before 4.0 release.

 thanks to Christian Lohmaier for his work to get internal python3
 packaged on Mac OS X, to Laszlo Nemeth for advice in porting the Python
 Script Provider extension, and to Xisco Fauli for porting the Python
 based Wizards.

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


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


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

Re: [ANNOUNCE] Python 3.3 is now bundled with LibreOffice 4.0

2012-11-28 Thread Stephan van den Akker 
Thanks, Alex.

It turns out that the remaining errors have to do with parts of python that
are not needed by LO, so the build continues anyway.

Cheers,

Stephan


2012/11/28 Alex Thurgood alex.thurg...@gmail.com

 Le 28/11/2012 12:53, Stephan van den Akker a écrit :

 Hi Stephan,

  Still getting errors on my 64-bit openSUSE system.
 

 Try clearing your ccache if you are using one :

 ccache -C

 I also did a make clean before rebuilding.

 That did the trick for me.

 Alex


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

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

Re: [PATCH] Fix docx 'absolute' frame position import

2012-09-05 Thread Stephan van den Akker 
Hi Pierre-Eric, All,

Could this be a fix for fdo#53356: FILEOPEN formula in imported DOCX has
wrong vertical position too?


2012/9/5 Gerrit ger...@gerrit.libreoffice.org

 From Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com:

 Pierre-Eric Pelloux-Prayer has uploaded a new change for review.

 Change subject: Fix docx 'absolute' frame position import
 ..

 Fix docx 'absolute' frame position import

 Frames with absolute position style must be vertically placed relative
 to 'Margin', otherwise parent paragraph style may modify their Y coord.

 Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
 ---
 M oox/source/vml/vmlshape.cxx
 1 file changed, 4 insertions(+), 0 deletions(-)


   git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/61/561/1
 --
 To view, visit https://gerrit.libreoffice.org/561
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: newchange
 Gerrit-Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
 Gerrit-PatchSet: 1
 Gerrit-Project: core
 Gerrit-Branch: master
 Gerrit-Owner: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com

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

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

License statement

2012-06-07 Thread Stephan van den Akker 
My previous and all future contributions to LibreOffice, unless
stated otherwise, are licensed under LGPLv3+/MPL

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

[PATCH] proposed fix for fdo#49859

2012-05-25 Thread Stephan van den Akker 
Hi, all!

I believe I found the cause of fdo#49859 FORMATTING, UI: numbering
alignment or
indentation is not applied in Impress

When the Position tab is deactivated,
SvxNumPositionTabPage::DeactivatePage()
is called. This call serves two purposes:

1: To check whether the Tab Page may be deactivated (answer: sal_True)
2: To retrieve the user input from this Tab Page

The Position tab contains two MetricFields: aDistBorderMF and aIndentMF. The
processing of input in these fields is triggered when they lose focus, by:

SvxNumPositionTabPage::DistanceHdl_Impl()

When either aDistBorderMF or aIndentMF has focus when the Position tab is
deactivated, it faithfully triggers a call to DistanceHdl_Impl(). But this
happens AFTER the call to DeactivatePage(). Therefore, the user input
retrieved from DeactivatePage() doesn't reflect the last changes made
in aDistBorderMF or aIndentMF.

I propose an addition to DeactivatePage():

int  SvxNumPositionTabPage::DeactivatePage(SfxItemSet *_pSet)
{
if(_pSet)
{
if(aDistBorderMF.IsEnabled())
DistanceHdl_Impl(aDistBorderMF);
DistanceHdl_Impl(aIndentMF);
FillItemSet(*_pSet);
}
return sal_True;
}

Question:

Ideally, I would wrap the DistanceHdl_Impl() calls in ..MF.HasFocus() checks
to prevent unnecessary calls:

if(aDistBorderMF.HasFocus()  aDistBorderMF.IsEnabled())
DistanceHdl_Impl(aDistBorderMF);
if(aIndentMF.HasFocus())
DistanceHdl_Impl(aIndentMF);
FillItemSet(*_pSet);

But both aDistBorderMF.HasFocus() and aIndentMF.HasFocus() always seem to
return
false! Is this intentional, or a bug?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice