This page was marked as inactive and is retained for historical reference.

Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.





LibreOffice Weekly News gathers interesting developments from discussions on mailing lists and IRC, updates in QA and git commits, and combines them into a tidy publication at the end of each week. This summary will emphasize a developer's point of view. This week in LibreOffice...

LibreOffice Weekly News #5

← previous Publication Date 2014-09-14 Editor William Gathoye (wget)

Development

New project from Document Liberation

As a reminder, The Document Liberation Project aims to provide an ability to open outdated or closed/proprietary file formats. When these formats are not supported any more by the company that initiated them, the salvation is often brought to the user thanks to libraries made by the Document Liberation. Users are able to recover their document contents and can save them to ODF, a modern, FOSS and very long-term supported alternative file format.[1]

We noticed that a new additional library called libpagemaker has been made available in version 0.0.1. This one allows to open Aldus/Adobe PageMaker document. As this library is still in pre-alpha development state, only basic shapes and their attributes can be read for now, but we expect improvements in the future. Thanks Anurag Kanungo, Brennan Vincent, David Tardon, and Fridrich Strba for this initiative!

As with any libraries from the Document Liberarion Project, they are crafted to work for LibreOffice but can be used in other projects too.[2]

Better XHTML export

Andrew Sayers, a new LibreOffice contributor, released mid-August 17 patches to improve the LibreOffice Calc export filter using XSLT.[3]

Document converter

Soon after the birth of LibreOfficeKit, Olly Betts released a project called lloconv, making use of LibreOfficeKit and allowing to call directly the rendering library LibreOffice uses. As a result, we do not need to play with UNO, to have LibreOffice running and this is faster.[4]

In July, Riccardo Magliocchetti released a Python cffi wrapper for LibreOfficeKit.

A wrapper is basically a function that calls another one, but in this case, this Python code is making a bridge between Python and LibreOfficeKit.

cffi, an acronym for C Foreign Function Interface for Python, is an interface which provides a reliable way to call compiled C code from Python.

This wrapper provides an easier way for Python developers to convert documents in their applications written in Python.[5]

Android version

The Document Foundation has decided to allocate a budget to develop the base framework for an Android version of LibreOffice with basic editing capabilities. Companies able to respect the requirements described in the call for offers and able to delivery the project for February 2015 are welcomed to apply and provide a timing and cost estimation. This call for offers is valid until October 6th, 2014.

Remove inheritance on std::map and std::vector

This week some more progress in removing inheritance on these std container classes: std::map and std::vector has been achieved by Takeshi Abe.[6] Inheriting from container classes of the standard library is actually a bad practise, we should use a composition or weak aggregation instead.

Standard library containers allow Inheritance. Nothing stops you from inheriting from a standard library container class. You will not get any compilation errors if you do so. But what they are not designed for is to allow the destruction of your derived class object through a Base class pointer. If you want to use inheritance in such a scenario (in short for dynamic polymorphism) then standard library containers are clearly not designed for it.[7]

The translation of the German comments is still continuing, we should hit 100% pretty soon. This is actually difficult to predict if we are still far or not, since as far as we know, no one has computed how far we are with translating German comments.

If you want to help, a script located at bin/find-german-comments is still available to locate these German comments in the code.

But comments are not the only location where we can still see German language tracks, some variables in the internal LibreOffice UNO API are still spelled in German. A bug report has been opened since the birth of LibreOffice project, and we begin to see again some progress in this regard. Thanks Jennifer Liebel.[9]

Maybe some more deprecation in the UNO::Writer API

The Writer UNO methods SwXTableColumns::getCount() and SwXTableColumns::getByIndex() might be deprecated since we are able to get the same piece of information by other ways and they are all due to implementing XIndexAccess [10]. Programmatically, columns are just an illusion: the table model just consists of rows with cells inside other rows. Because of that, it is OK to talk about columns at the UI level, but at the API level (here), it is probably better to not talk about them, thus the deprecation.

Some news for macOS builds

Up to now LibreOffice was using libstdc++ the standard C++ library from the 4.2 GCC shipped with macOS. This old 4.2 GCC version is deprecated and is not updated by Apple, like the rest of the UNIX-like tools of the OS (binutils, bash, etc.), for licensing reasons: these projects moved to GPLv3, while Apple is still using their GPLv2 counterparts. Since LibreOffice is migrating to a full 64 bits version on the macOS platform and is using more and more C++11 code, using libc++ was a needed requirement.

Since a recent commit, LibreOffice 4.4 and above built against the macOS SDK >= 10.8, and if no --with-macOS-version-min-required configure flag is explicitly used, will make use of libc++ instead of libstdc++ [11].

Since Retina™ displays are now present on all Apple devices (except on the MacBook Air) and 64-bit builds are now the standard configuration for LibreOffice macOS builds, the flags --enable-retina and --enable-64bits will be dropped and will be the default configuration.[12]

Requiring to have at least macOS 10.8 to build an macOS version is required for OpenGL support and the C++11 features that begin to be widely deployed into the LibreOffice code base.[13]

The Tinderbox 53, producing builds for macOS, is now built with the new Maria DB connector that has been developed recently. The following configuration flags were added --enable-ext-mariadb-connector , --with-system-mariadb and --enable-bundle-mariadb [14] to the tinderbox configuration.

Bibisect location for 4.4 has changed

As a reminder, the "bibisect" repositories of (binary) LibreOffice builds let you locate with some precision the time when a regression appeared. You do not need to build LibreOffice; this has already been done for you. Simply do a dichotomic search and you will find the commit—to the precision of the bibisect repository—responsible for the bug.

The repository of binary builds for the 4.4 branch has moved from Bitbucket and is now on The Document Foundation-owned server infrastructure.

If you were previously using <ssh://git@bitbucket.org/vmiklos/lo-daily.git> for your bibisections, please update the repository URL in your .git/config to the new one: <git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily.git> . Thanks Miklos Vajna![15]

LibreOffice 4.3 is not usable on < SSE2 CPU

Since the 4.3 branch, it has been reported LibreOffice cannot run on a Windows Platform if the processor does not support at least SSE2.[16]

This is due to the fact LibreOffice is now using Visual Studio 2012 to produce binaries for Windows. Visual Studio 2012 is using the default compilation flag /arch:SSE2 .[17] The idea if we want to support older CPUs is to change this flag to "-arch:SSE".[18]

Some arguments have started regarding the need to be able to compile LibreOffice on such old hardware, here an AMD K7 whose production started in mid-1999 and was discontinued in 2005, 9 years before LibreOffice 4.3 was released.

The solution chosen was to get back to SSE1 compiler and improve algorithms and OpenCL usage. The latter will anyway detect and use the CPU feature automatically.[19]

While the flag has been merged in master,[20] the bug is still not marked as solved, because it is not completely fixed. Michael Stahl[21] precised some external library might not take the -arch:SSE flag into account, so that we got sometimes exception, especially in enabledExtension from the Extension Manager. The solution to narrow the issue is to have a tool which inspects all LibreOffice ddl to see if some SSE2 extensions are present.[21]

To disassemble on Windows, we found dumpbin . The syntax is dumpbin /DISASM file.exe .

. The syntax is . On Linux, as objdump can only work with ELF, the trick is to use MinGW which has an objdump version adapted to the PE format. On Arch Linux, simply install the mingw-w64-binutils package and use i686-w64-mingw32-objdump . The syntax is i686-w64-mingw32-objdump -d file.exe .

Then, we simply need to grep any SSE2 opcode on the command output from this list, if we got result, the exe/dll is using SSE2. A Perl script has already been created by the Gentoo community, you just need to change the l58 to reflect the exact MinGW objdump location on your system.

A new tool for Vimmers

If you are using YouCompleteMe, a rather new Vim plugin replacing omnicomplete, supertab, etc., you should be pleased to learn a small tool vim-ide-integration has been merged in the LibreOffice repository, in master a month ago allowing you to use LibreOffice code with that extension.

Basically, YouCompleteMe has several completion engines, the C-family completion engine requires you to have a file .ycm_extra_conf.py which contains the flags you need to build your project. These flags are used to locate headers and thus classes, method definitions, etc. This file is thus mandatory for YouCompleteMe to work properly. The tool that has been merged actually creates the needed flags for that file. Thanks to Markus Mohrhard for this initiative he performed while he was actually sick in his bed.[22]

Beyond ODF: macros and automation

Macros are an interesting topic as they go beyond the direct representation of document contents. As a reminder, for those who do not know because they are not using them, macros are actually instructions, functions and routines used to control the software in an automated way.

As a simple example with LibreOffice, if you want to make a particular operation on each line of a document, but using a simple shortcut, it is impossible as the action is actually made of several ones, a macro could come in handy that time. You write your instructions either using the macro recorder or using the LibreOffice API, and bind the macro to a keyboard shortcut, allowing you to perform a long task at the speed of light.

The macro recorder converts actions made in LibreOffice into limited BASIC code; but this does not cover the whole interface and complicated actions might not be possible. This is why this option is advertised as limited. This solution uses UNO slots but takes you away from using the API which is much more evolved, but a bit more complicated to use for some tasks.

By default the macro recorder is not enabled, you have to check the checkbox Enable macro recording (limited) in Tools ▸ Options ▸ LibreOffice ▸ Advanced ▸ Optional (unstable) options . Then, to use the recorder, simply go to Tools ▸ Macros ▸ Record Macro , perform your actions, and click on Stop Recording from the floating dialog box that appeared, choose a macro name and click on Save .

The LibreOffice API allows you to interact completely with LibreOffice either using the LibreOffice own scripting language, LibreOffice BASIC, or using one of the supported language which has a binding for LibreOffice: C++, Python, Java, and Wikipedia:OLE Automation. But you can write your own UNO language binding to control LibreOffice with your favorite language too [23] .

. Access2Base, we can consider it as an extension to the LibreOffice API, and since LibreOffice 4.2, even as a subset of the API as it is now bundled into LibreOffice. Access2Base simplifies the use of the API when trying to access and communicate with databases in Base in particular;

VBA (Visual Basic) macros are at the same time a language and an office object model which are saved inside Microsoft Office documents only (this means VBA cannot be saved in ODF documents: odt, ods,...). LibreOffice incorporates limited direct support for VBA. By default LibreOffice expects to have LibreOffice BASIC code, so you must start your code by

Option VBASupport 1 Option Compatible

if you want to use VBA script[24].

Although macro are saved in the user profile (or Normal.dotm in Microsoft Office), some can be saved inside the document itself and VBA macro are in all cases saved into the Office document structure itself.

After having explained above the steps to write macros, we can easily understand that writing macro requires to discuss with an SDK whose features depend heavily on the internal implementation[25][26] of the product we want to control: LibreOffice, Microsoft Office, Calligra, etc. So the objects we call in a macro might (and mostly will) not exist in another product[27].

We need to differentiate the document format from macros: the document (here ODF) saves and organises the data into a well structured archive while macros are processes, designed to help the user, locked against a particular piece of software. We can make an analogy with web browser extensions. These depend also heavily on the platform for which they were crafted: you cannot use an extension created for Firefox on Chromium for example. This is why you will not see these macros standardized in either the ODF or OOXML document format specification.

This is why you could potentially replace all macro you use by an extension. Since it requires coding skills, the better way for interoperability is yet to not use them, or at least, if they cannot be avoided, storing them in the user profile instead of the file itself and using textual macros rather than operating system specific COM or ActiveX components[25].

New contributors

We welcomed 7 new contributors to the LibreOffice project:

Giuseppe Bilotta (Oblomov) [28]

Sudarshan Rao (Sudarshan18) [29]

Boris Egorov [30]

Marco Lechner (mlechner) [31]

Michael Jaumann [32]

Tobias Madl [33]

Michael Weghorn[34]

Please note that basing our number of contributors on the number of license statements is a bit unfair, as some have provided patches but not published a statement yet, while others have published one but have left the project afterwards. Also this only concerns the development team, contributors doing user support, Q/A, etc. do not need a license statement and they are not counted in this report. But let thank them anyway, they are doing a valuable work.

Robert Antoni Buj i Gelonch, who published his statement in June 2014, has recently published on our gerrit instance a bunch of patches to clean Java stuffs we still have. Thanks to him! [35]

Stefan Weiberg, a new contributor, for who we reported the license statement last week, is now publishing his first patches related to the #fdo82088 easy-hack [36] [37] [38] , congrats!

easy-hack , congrats! Matthew J. Francis, a new contributor from last week published his first patches too. [39]

Jan-Marek Glogowski, a contributor who published a license statement in November 2013, recently published his first patches. Thanks for being back! [40]

Jennifer Liebel, reported last week too, published her first patched too. Congrats![41]

Design team

Bye bye mailing list

During the last monthly IRC meeting, held on August 31th, the design team decided they will drop the mailing list in favour of Redmine[42] After a month of test, if there is no opposition, the design and ux-advise mailing list will be removed[43].

The main work platforms used by the Design team are

the wiki to keep track of design propositions, user experience principles, artwork resources and track of previous IRC meetings

the aforementioned Redmine project to keep tracks and discussion about design bugs

and the #libreoffice-design IRC channel for the monthly meetings.

Documentation

LibreOffice Base gets a new German guide

Robert Großkopf has reported the previous 4.2 German guide has been updated to LibreOffice 4.3 expanding the number of pages by 50 pages. You can see the changes here.[44]

A guide to understand the plethora of Base guides

LibreOffice has currently 3 guides for Base:

Getting Started with Base which is the chapter 8 from the book Getting Started with LibreOffice

which is the chapter 8 from the book LibreOffice Base Handbook

LibreOffice Base Guide

The reason that there's both a Guide and a Handbook is that the German documentation team got tired of waiting around for the English team to finish the Base Guide, so they took the draft chapters, translated them, and rewrote (Robert Großkopf) some parts from information available in mailing list and forums,[45] finished the book, and published it as the Base-Handbuch. That document was then translated back into English as the LibreOffice Base Handbook.[46] The English draft was renamed into LibreOffice Base Guide and left as-is, without much attention.[47]

This is why contrary to the newcomer belief, according to the meaning of the word "handbook" which suggests a reasonably comprehensive book that covers most simple use cases to nudge the user in the right direction, without going too much into the details and according to the meaning of "guide" which should be a complete manual covering all use cases,[48] the Handbook is not intended to be shorter than the Guide.

The difference is that the German version of the Handbook is finished and updated to the version 4.2 of LibreOffice, while the English version is finished too, but still for LibreOffice 3.5.

Alan Cook is now updating the English Handbook from the more up-to-date German version whose translation to English has been performed by Hazel Russman.[46]

Dan Lewis reported[49] he is currently reviewing the chapter 2 of the Base Handbook. His work might overlap with the work Alan Cook is doing. The old unmaintained Base guide might even be removed in the future.[50]

During these holidays, Thomas Taylor, a retired engineering technician, Linux user and LibreOffice mailing list moderator, proposed his help.

As an answer to any new contributor wanting to get involved in the documentation team, the Base Handbook is the clearly the content requiring the most of work from now, especially proofreading. Indeed, even if the German LibreOffice Base Handbook is considered as completed, Alan Cook discovered some issues.

Completing the screenshots is a huge task that needs to be performed. For license reasons, only GNU/Linux screenshots are allowed, publishing screenshots with macOS or Windows is risky on the legal point of view.

Translation of LibreOffice Guides with OmegaT

Milos Sramek, who gave a presentation about this subject at the LibreOffice conference from Bern, proposed that the documentation team uses OmegaT to improve the efficiency when translating manuals. This tools addresses what Alan Cook is doing (see the above subject): he is currently translating a new version of some text by taking advantage of the translation of an old version. In order to not break the current workflow, Alan decided to keep the tools he is currently using, but, maybe in the future, for the next round of translations, he will reconsider using this tool.

Sophie Gautier gave it a try but is expecting to write a tutorial because the installation and learning process is not so easy for a newcomer[51]

Draw Guide for LibreOffice 4.3

Chapter One was uploaded and is ready for review.[52]

The Writer guide for LibreOffice 4.2 has been delayed due to lack of contributors. As a reminder, you do not have to throw away the documentation guides when their based-on version is outdated. The documentation team is indeed skipping some LibreOffice versions and updates the handbooks and guides after some time, when it is needed and changes in the interfaces require it.

Jean Weber recently updated the chapter 16. Only chapters 13, 14, and 15 need to be proofread and, if needed, updated before we could release this new updated guide[53].

If you want to contribute, the best way is to follow this guide, especially the document Joining the LibreOffice Documentation Team from the First steps with the Documentation team section. Below, you will see the main way to contribute to the documentation team is to subscribe to the ODFAuthors website, hosted, here, at The Document Foundation. This website consists in writing documentation for projects making use of the ODF standard and is not limited to LibreOffice.

Keep in mind the workflow the documentation team uses is to add content to the English version, then when it is finished, translate the content to other languages. Keeping a list of the changes performed in the English version allows the translator to directly focus their translation skills to specific location in his translation without spending much time in rereading all the text. The first translation usually takes a lot of time, while updates are relatively way less time consuming.

Wanted: team coordinator dead or alive (preferably alive)

Out of this joke, the LibreOffice documentation team is currently having a coordination problem, and this is not the only team impacted, other LibreOffice teams and even other FOSS projects are also impacted. Up to now, Jean Weber "de facto" fulfilled this function due to her huge implication into the project. However her intentions were never to do it consistently. Although she warned the team she will be doing even less in the future, nobody came up with a solution or applied to this function.

The problem we have is not attracting new contributors (see above), keeping them involved, and, in addition, active, is another and even more difficult challenge. Also, keeping objectives achieved for a well defined deadline is against the definition of volunteering[54].

Sophie Gautier has volunteered[55] to do this coordination work and has been accepted by the team[56]. As a first step she will reorganize the wiki and document some tools which could be used by the translators[57].

Sophie, nicknamed as sophi on IRC, is one of The Document Foundation founders. On a paid basis she is coordinating the releases and is an administrative assistant for the Foundation. As a volunteer, she is mainly active in the French translation: localizing the UI, help and FAQ is what she loves most, she does some Quality Assurance (bugs triaging/hunting) too[55].

Number of guides sold

Sales figures for the printed books and eBooks sold by Friends of OpenDocument, Inc. via Lulu.com from January 1, 2011 to September 10, 2014 are available. This is rather interesting to see which books are most popular, allowing the team to focus on a version in particular if needed.

478 Getting Started

198 Writer Guide

93 Calc Guide

87 Base Handbook

50 Impress Guide

57 Draw Guide

31 Math Guide

Total 994[58]

Marketing

The LibreOffice Magazine is becoming wider

The next LibreOffice Magazine (it will be already the 13th issue! congratulations!) is now calling for papers. Since the scope of languages has been widened from Portuguese to Spanish and English, and if you have tutorials, migration cases, achievements and tips, please submit them as ODF with a small picture and your resumé before October 6, 2014 to redacao libreoffice.org.[59]

Profesionalizing our communication

In our last edition, we noticed the Brazilian video trying to promote LibreOffice, we have some good news since an English translation has been made available. This is not yet perfect as the application menus we can see in the video are still in Portuguese, but this is a great start.[60]

Meetings and conferences

Brazil Conference

Eliane Domingos de Sousa, a contributor from the Brazilian LibreOffice Community, who is also in charge of the LibreOffice Magazine, announced that the second National LibreOffice Meeting will be held this year from September 26, to 27 2007 iin the state of São Paulo at the UNESP University. More information is available here[61].

OpenSUSE.Asia summit

SUSE is a member of the Advisory Board and is providing developers for LibreOffice. SUSE is also promoting the development of the community-supported OpenSUSE GNU/Linux distribution, and is therefore sometimes doing events like LibreOffice. Obviously since OpenSUSE is somewhat related to LibreOffice, they are calling for papers and participants. If you want to join feel free to answer this announcement.

Seattle LibreFest

Robinson Tryon, our remote backdoor to the USA, is organizing a community event about LibreOffice (LibreFest) around, or at the same time of the SeaGL, a grassroots technical conference dedicated to spreading awareness and knowledge about GNU/Linux and FOSS software and hardware in general, on October 26th 2014.

This LibreOffice related event, will introducte the LibreOffice project and community, explain how to use Bugzilla and do some bug triages.

Toulouse Hackfest

As a reminder, Arnaud Versini is organizing a LibreOffice hackfest on November 15th and 16th, 2014.

Munich hackfest

This bug squashing party is hosted and sponsored by the LiMux project, the project that created a GNU/linux distribution for the Munich Municipality, in order for them to have a tailor-made distribution fitting perfectly the needs of the Munich city.

See this page for Doodle and coordination.

Document Foundation boards

To get a refreshed view of the boards constituting The Document Foundation, please read this summary first.

A new member for the advisory Board

ITOMIG, a company founded as a spin-off the of the German Tübiingen University in 2004, has developed an open source expertise, offered to French and German enterprises, and focused on free open source office suites, mainly LibreOffice. This expertise consists in migration support and development consulting. ITOMIG will provide the Advisory Board with consultants giving technical advices to the Board of Directors.[62]

User tips and tricks

Search in multiple documents

Last week we raised an issue regarding the inability, on GNU/Linux at least, to be able to search in multiple document at one. After one week of intensive serach, Maurice, the user who asked initially the question, finally found a solution[63].

The idea is to create a master document, using the navigator feature to add sub document, save the master document and then you will be able to search for content in all subdocuments at one. For details, simply read here.