date:20131016

LibreOffice Gerrit News for core on 2013-10-16

2013-10-16 Thread gerrit

Moin!

* Open changes on master for project core changed in the last 25 hours:

+ fdo#7 add support for COVARIANCE.P and COVARIANCE.S functions
  in https://gerrit.libreoffice.org/6135 from Winfried Donkers
+ sw: Smart-Art related UTs updated to new option
  in https://gerrit.libreoffice.org/6139 from Andres Gomez
+ Backport for bug fdo#70345
  in https://gerrit.libreoffice.org/6250 from matthieu gay
+ sw/export docx: add unit test for document with header and section(s)
  in https://gerrit.libreoffice.org/6249 from Pierre-Eric Pelloux-Prayer
+ sw/docx export: fix handling of document with header and section(s)
  in https://gerrit.libreoffice.org/6248 from Pierre-Eric Pelloux-Prayer
+ fdo#70393: move libpng to a subdir of external
  in https://gerrit.libreoffice.org/6231 from Björn Michaelsen


* Merged changes on master for project core changed in the last 25 hours:

+ Add the new iOS app project files
  in https://gerrit.libreoffice.org/6255 from Ptyl
+ New iOS client code
  in https://gerrit.libreoffice.org/6254 from Ptyl
+ fdo#61950 De-extensionize presentation minimizer: post clean
  in https://gerrit.libreoffice.org/6247 from David Ostrovsky
+ fix polygon rendering with clip area of one line only
  in https://gerrit.libreoffice.org/5709 from Tsahi Glik @ CloudOn
+ Use SAL_WNODEPRECATED_DECLARATIONS_PUSH/POP part2
  in https://gerrit.libreoffice.org/6244 from Julien Nabet
+ fdo#47958: gross cut/paste signal emission nonsense
  in https://gerrit.libreoffice.org/6064 from Julien Nabet
+ fdo#57659: fix exif processing
  in https://gerrit.libreoffice.org/6245 from Julien Nabet
+ Remove Java unit tests migrated to Python
  in https://gerrit.libreoffice.org/6017 from David Ostrovsky
+ fdo#70371: Initial perl script
  in https://gerrit.libreoffice.org/6238 from Jelle van der Waa


* Abandoned changes on master for project core changed in the last 25 hours:

+ fdo#61950 De-extensionize presentation minimizer: post clean
  in https://gerrit.libreoffice.org/6246 from David Ostrovsky


* Open changes needing tweaks, but being untouched for more than a week:

+ Make libatomic_ops buildable and enable on non-X86.
  in https://gerrit.libreoffice.org/5812 from Andrzej J.R. Hunt
+ Remove obsolete MIME associatons on MAC OS
  in https://gerrit.libreoffice.org/6103 from Samuel Mehrbrodt
+ Increase number of remembered recent documents from 10 to 25
  in https://gerrit.libreoffice.org/6101 from Krisztian Pinter
+ startcenter: Make SC open faster by timeouting thumbnails
  in https://gerrit.libreoffice.org/6102 from Krisztian Pinter
+ Remove old outdated gallery images and sounds
  in https://gerrit.libreoffice.org/4993 from Samuel Mehrbrodt
+ Remove more unusedcode
  in https://gerrit.libreoffice.org/5937 from Marcos Souza
+ Simplify oslThreadIdentifier on Linux 32.
  in https://gerrit.libreoffice.org/5553 from Arnaud Versini
+ Dynamically align toolbars in LibreOffice
  in https://gerrit.libreoffice.org/5655 from Prashant Pandey
+ fdo#36791 : fix for import of greeting card
  in https://gerrit.libreoffice.org/4240 from Adam CloudOn
+ more debug logs, extra debug layer, file is not used in p3k
  in https://gerrit.libreoffice.org/5267 from James Michael Dupont
+ Positional Tab additions
  in https://gerrit.libreoffice.org/5387 from Adam CloudOn
+ fdo#64817 : fix for rectangle with image fill
  in https://gerrit.libreoffice.org/4718 from Adam CloudOn


Best,

Your friendly LibreOffice Gerrit Digest Mailer

Note: The bot generating this message can be found and improved here:
   
https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=blob;f=gerritbot/send-daily-digest
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

MySQL Connector Extension Build on Linux 32bit

2013-10-16 Thread Alex Thurgood

As some of you will probably know by now due, I attempt to provide the 
mysql native connector extension for Linux 32 bit, 64 bit and OSX 64bit.


At present, the 32bit Linux build doesn't work on other people's 
machines with a similar base OS, whereas the Linux 64bit does. There is 
a noticeable difference in size between the two OXT files, and 
comparison of the two shows the following :


32bit extension :
alex@Aspire-X1430:/home/Development/libo/core$ unzip -l 
workdir/unxlngi6.pro/Extension/mysql-connector-ooo.oxt

Archive:  workdir/unxlngi6.pro/Extension/mysql-connector-ooo.oxt
  Length  DateTimeName
-  -- -   
0  2013-09-24 11:42   META-INF/
 1388  2013-10-15 12:57   META-INF/manifest.xml
  311  2013-10-14 14:45   components.rdb
  255  2013-10-15 12:13   description-en-US.txt
 1737  2013-10-15 12:57   description.xml
  838  2013-09-24 10:20   images/extension_32.png
   667046  2013-10-14 14:15   libmysqlcppconn.so
   484084  2013-10-14 14:29   mysqlc.uno.so
0  2013-09-24 11:42   registration/
   436207  2013-10-15 12:57   registration/LICENSE
 3561  2013-09-24 10:21 
registry/data/org/openoffice/Office/DataAccess/Drivers.xcu

- ---
  1595427 11 files
alex@Aspire-X1430:/home/Development/libo/core$ ls -an 
workdir/unxlngi6.pro/Extension/mysql-connector-ooo.oxt
-rw-rw-r-- 1 1000 0 482261 oct.  15 12:57 
workdir/unxlngi6.pro/Extension/mysql-connector-ooo.oxt




64bit extension:
alex@Aspire-X1430:~$ unzip -l Downloads/mysql-connector-ooo.oxt
Archive:  Downloads/mysql-connector-ooo.oxt
  Length  DateTimeName
-  -- -   
0  2013-10-07 13:29   META-INF/
 1391  2013-10-11 16:36   META-INF/manifest.xml
  311  2013-10-11 16:36   components.rdb
  255  2013-10-11 16:35   description-en-US.txt
 1743  2013-10-11 16:36   description.xml
  838  2013-10-07 13:04   images/extension_32.png
  5113839  2013-10-11 15:06   libmysqlcppconn.so
  3802154  2013-10-11 16:35   mysqlc.uno.so
0  2013-10-07 13:29   registration/
   436207  2013-10-11 16:36   registration/LICENSE
 3561  2013-10-07 13:04 
registry/data/org/openoffice/Office/DataAccess/Drivers.xcu

- ---
  9360299 11 files
alex@Aspire-X1430:~$ ls -an Downloads/mysql-connector-ooo.oxt
-rw--- 1 1000 1000 2587648 oct.  16 07:59 
Downloads/mysql-connector-ooo.oxt



What I'm failing to understand is why this is happening. The basic build 
systems are based on Ubuntu 13.04 Raring, and use exactly the same build 
switches, the only difference being that the 64bit OS is Linux Mint 15 
Olivia (based on Ubuntu 13.04), and the 32bit is a default Ubuntu 13.04 
Raring. Something is obviously failing to be included during the 32bit 
build, but what ?


64bit :
  5113839  2013-10-11 15:06   libmysqlcppconn.so
  3802154  2013-10-11 16:35   mysqlc.uno.so

32bit :
   667046  2013-10-14 14:15   libmysqlcppconn.so
   484084  2013-10-14 14:29   mysqlc.uno.so


Any help much appreciated.



Alex






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

Re: Changing the object created by imported docx

2013-10-16 Thread Jacobo Aragunde Pérez

Hi again,

I think we can conclude some things from your feedback:

* The most future-proof solution would be replacing all uses of
Writer-kind images with Draw-kind ones, and add to the latter some
missing features present in the former [1]. This is an old discussion
coming from OO days [2], there's even an analysis of this task at [3].

* We could leave 0º, 90º, 180º and 270º rotated images as they are now
(Writer-kind bitmaps), because they are working properly both at import
and export.

* It would be acceptable to use Draw-kind images to import
freely-rotated pictures coming from docx documents. To export them
properly, the bug #65836 [4] should be fixed.

Thanks to you all. Conversations at this list are always insightful :)

[1] http://wiki.openoffice.org/wiki/User:Regina/ComparisonWriterDrawPicture
[2] https://issues.apache.org/ooo/show_bug.cgi?id=3545#c105
[3]
http://wiki.openoffice.org/wiki/Writer/Unification_of_Graphic_Objects_and_Embedded_Objects
[4] https://bugs.freedesktop.org/show_bug.cgi?id=65836

Regards,
--
Jacobo Aragunde
Software Engineer at Igalia

El 15/10/13 09:44, Jacobo Aragunde Pérez escribió:
Morning :)

I've been thinking on potential solutions to #70457 [1]. It's related
with rotation information lost when importing a docx that contains some
bitmap.

Writer bitmaps are only allowed to be rotated in 90º steps, but in Word
they can be rotated to any angle. When importing a document containing a
45º bitmap the rotation is lost, and it keeps lost when the document is
saved back.

I wonder if importing embedded bitmaps coming from docx as Draw objects
would be an acceptable solution for this bug (Draw objects allow to be
rotated to any arbitrary position).

Such a change should be discussed first, imho. What do you think?

Thanks in advance for your time.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=70457

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

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

2013-10-16 Thread Stephan Bergmann

 dbaccess/source/core/dataaccess/commanddefinition.hxx |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

New commits:
commit 7a3381c2a80de38b513e6e2b455ca5d3c70274c8
Author: Stephan Bergmann sberg...@redhat.com
Date:   Wed Oct 16 10:02:33 2013 +0200

CID#1000838 Fix overrides' exception specifications

Includes also fixes for
CID#1000839
CID#1000840
CID#1000841

Change-Id: I4c7d0bbaec59357af722353bdf947f5629dde1b0

diff --git a/dbaccess/source/core/dataaccess/commanddefinition.hxx 
b/dbaccess/source/core/dataaccess/commanddefinition.hxx
index 3a4a79c..f6afbee0 100644
--- a/dbaccess/source/core/dataaccess/commanddefinition.hxx
+++ b/dbaccess/source/core/dataaccess/commanddefinition.hxx
@@ -99,13 +99,13 @@ public:
 { OComponentDefinition::setPropertyValue(p1, p2); }
 virtual com::sun::star::uno::Any SAL_CALL getPropertyValue(const OUString 
p1) throw(::com::sun::star::beans::UnknownPropertyException, 
::com::sun::star::lang::WrappedTargetException, 
::com::sun::star::uno::RuntimeException)
 { return OComponentDefinition::getPropertyValue(p1); }
-virtual void SAL_CALL addPropertyChangeListener(const OUString p1, const 
com::sun::star::uno::Referencecom::sun::star::beans::XPropertyChangeListener 
p2) throw( ::com::sun::star::uno::RuntimeException )
+virtual void SAL_CALL addPropertyChangeListener(const OUString p1, const 
com::sun::star::uno::Referencecom::sun::star::beans::XPropertyChangeListener 
p2) throw(::com::sun::star::beans::UnknownPropertyException, 
::com::sun::star::lang::WrappedTargetException, 
::com::sun::star::uno::RuntimeException)
 { OComponentDefinition::addPropertyChangeListener(p1, p2); }
-virtual void SAL_CALL removePropertyChangeListener(const OUString p1, 
const 
com::sun::star::uno::Referencecom::sun::star::beans::XPropertyChangeListener 
p2) throw( ::com::sun::star::uno::RuntimeException )
+virtual void SAL_CALL removePropertyChangeListener(const OUString p1, 
const 
com::sun::star::uno::Referencecom::sun::star::beans::XPropertyChangeListener 
p2) throw(::com::sun::star::beans::UnknownPropertyException, 
::com::sun::star::lang::WrappedTargetException, 
::com::sun::star::uno::RuntimeException)
 { OComponentDefinition::removePropertyChangeListener(p1, p2); }
-virtual void SAL_CALL addVetoableChangeListener(const OUString p1, const 
com::sun::star::uno::Referencecom::sun::star::beans::XVetoableChangeListener 
p2) throw( ::com::sun::star::uno::RuntimeException )
+virtual void SAL_CALL addVetoableChangeListener(const OUString p1, const 
com::sun::star::uno::Referencecom::sun::star::beans::XVetoableChangeListener 
p2) throw(::com::sun::star::beans::UnknownPropertyException, 
::com::sun::star::lang::WrappedTargetException, 
::com::sun::star::uno::RuntimeException)
 { OComponentDefinition::addVetoableChangeListener(p1, p2); }
-virtual void SAL_CALL removeVetoableChangeListener(const OUString p1, 
const 
com::sun::star::uno::Referencecom::sun::star::beans::XVetoableChangeListener 
p2) throw( ::com::sun::star::uno::RuntimeException )
+virtual void SAL_CALL removeVetoableChangeListener(const OUString p1, 
const 
com::sun::star::uno::Referencecom::sun::star::beans::XVetoableChangeListener 
p2) throw(::com::sun::star::beans::UnknownPropertyException, 
::com::sun::star::lang::WrappedTargetException, 
::com::sun::star::uno::RuntimeException)
 { OComponentDefinition::removeVetoableChangeListener(p1, p2); }
 virtual 
com::sun::star::uno::Referencecom::sun::star::ucb::XContentIdentifier 
SAL_CALL getIdentifier() throw( ::com::sun::star::uno::RuntimeException )
 { return OComponentDefinition::getIdentifier(); }
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Roundtripping DOCX file in CLI vs API vs GUI - different results !

2013-10-16 Thread Miklos Vajna

Hi Adam,

On Tue, Oct 15, 2013 at 07:05:32PM +0300, Adam Fyne adam.f...@cloudon.com
wrote:
I was wondering if you have encountered this, or know what is the root cause
of this.

There are 3 different ways to perform a roundtrip of a DOCX file using
LibreOffice:

* GUI- This way you run LibreOfffice, open the
file, do 'save as', choose 'DOCX' and type the filename

* API - This way you simply load\import the
LibreOffice libraries - and use the API to convert a file from one format to
another

* CLI - This way you type in the console
something like './soffice -conver-to '.

What we have noticed is - that the results of the outputted DOCX files are
not visually identical in all 3 way !

One pitfall is that on the export side, we have two DOCX export filters:
one is 'Office Open XML Text', the other is 'Microsoft Word 2007/2010
XML'. They are basically the same filter, but in case the ECMA standard
and what Word does differs, the use can choose what does she prefer.

The filter queries its name like this:

http://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/docxattributeoutput.cxx#1900

In the past, for some reason --convert-to used the ECMA filter, while
gui save as used the Word filter, in case docx was given as a file
extension. So this can be one problem -- though I just checked with
latest master, and now I don't see this anymore, even --convert-to uses
the Word filter (which is good).

An other pitfall is that in Writer, layout is rendered in an idle loop
(there are at least two iterations, the first should be quick, the
second should be more correct), so if you use --convert-to, we somehow
have to wait for the layout. This kind of problem used to cause problems
with unit tests as well: we wanted to test layout, but layout wasn't
ready right after loading. ;-)

That's why we have this code for unit tests:

http://opengrok.libreoffice.org/xref/core/sw/qa/extras/inc/swmodeltestbase.hxx#92

A third pitfall is that the main() of unit tests and the desktop app
is not the same, it happened in the past that desktop app exported
images, while unit tests didn't. That's how we have code like this:

http://opengrok.libreoffice.org/xref/core/test/source/bootstrapfixture.cxx#69

All in all, there can be multiple reasons why such output differs, of
course ideally none of them should happen.

Difference in naming of image files in media folder

(e.g. file round trip through CLI may have image1/2/3.png as names whereas
file round trip through API may have image101/102/103.png or different.

I haven't noticed such difference earlier, so that's something that needs
tracking down.

Entire Table of Contents is lost if round trip through CLI/API whereas it is
retained (largely) if done through GUI.

We have this writerfilter/source/dmapper/ModelEventListener.cxx class,
which reacts on this OnFocus even of the document, and does some field
updating -- isn't it possible that in case of CLI/API, that event is
never emitted, and that causes your problem?

I don't really understand how come the filter behaves differently between
CLI\API and GUI.

I guess in all cases it's not the filter itself, it's the layout, filter
name, some API what the filter tries to use, etc. -- that differs.

If there is some duplicate code and we are doing our fixing in the wrong
place than we need to be aware of it.

Maybe there is some additional code to the filter in the core model that is
not running in the CLI ?

There is some duplication, as mentioned above for unit tests vs desktop
app (desktop::Desktop::Main() vs test::BootstrapFixture::setUp()), but
in your GUI/--convert-to/API case, that all should use the desktop main
loop, so should not affect you.

We have opened a bug https://bugs.freedesktop.org/show_bug.cgi?id=70481
for this in Bugzilla,

but I was wondering if you have any thoughts about this or if you have
encountered this before.

As written above, not this one, but I saw similar issues, yes.

Reading the bugreport, Owen mentions that the situation used to be a bit
better, that is worth to investigate as well (e.g. if it's a
regression, what commit caused that), I haven't done that so far.

Hope this helps,

Miklos

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

Re: hanging indent

2013-10-16 Thread Miklos Vajna

Hi Russel,

[ Putting back the freedesktop list to CC, removing that is considered a
bit rude, I assume it happened only by accident. ]

On Tue, Oct 15, 2013 at 05:27:08PM +, Russell Schmitt 
russjennschmi...@juno.com wrote:
 Bug 62176 format Negative indents in styles not saved properly is the one 
 report I can find.  I have read others. Thank you

I see at https://bugs.freedesktop.org/show_bug.cgi?id=62176 that it's
marked as a regression, already bibisected. Did you look at the
problematic commit range to see if there is anything that is directly
related to this problem?

Miklos


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

Re: MySQL Connector Extension Build on Linux 32bit

2013-10-16 Thread Stephan Bergmann


On 10/16/2013 09:33 AM, Alex Thurgood wrote:

64bit :
   5113839  2013-10-11 15:06   libmysqlcppconn.so
   3802154  2013-10-11 16:35   mysqlc.uno.so

32bit :
667046  2013-10-14 14:15   libmysqlcppconn.so
484084  2013-10-14 14:29   mysqlc.uno.so


Any help much appreciated.


I would look at the readelf -d output for each of these, to see which 
other libraries they link against ((NEEDED) lines), and at the nm 
--def output for each of these, to see whether there are any glaring 
differences (and where the names of the missing symbols might give a hint).


Stephan

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

1 2 3 >

1 - 100 of 276 matches

Mail list logo