The First LibreOffice Latin America Conference is a success and achieved important community milestones.

Linguistic challenges, women’s participation in FOSS, interoperability, professional training, migration, scripting and much more were hot topics in the conference held at the Facultad Politecnica of the Universidad Nacional de Asunción, Paraguay.

By Daniel A. Rodriguez.

The event started internally on Thursday 18 with a translation sprint of the LibreOffice Guarani team, with the assistance of Olivier Hallot (Brazil), LibreOffice volunteer translator for Brazilian Portuguese.

The Conference opened to public on Friday 19 in a ceremony that gathered the Minister of the Secretariat of Linguistic Policies (SPL), Ladislaa Alcaraz de Silvero, Prof. Limpia Ferreira Ortiz, FP-UNA Vice-Dean, members of the Guaraní Culture Atheneum, Prof. Mag. Alcides Torres Gutt, Coordinator of the Translation Team together with Italo Vignoli and Gustavo Pacheco representing The Document Foundation and the LibreOffice Community.

“The LibreOffice Latin American Conference is an event not only of technology, it is also a space for the study of new forms of productive organization. It will deal with technical topics such as development and quality control, but also with successful cases of migration and, with special attention, the translation into Guaraní, native of the American continent and official in Paraguay,” said the Vice-dean in her inaugural speech.

The conference initiative was declared of “Scientific and Technological Interest” by the Honorable Chamber of Deputies of Paraguay.

This regional conferences were carried out for 8 years in Europe and other continents, and for this time Paraguay was chosen as the venue, because it has a vibrant Free Software community, a special interest for the Guaraní language, and was completely organized by volunteers. Talks and workshops were held by speakers, members of the LibreOffice community, from Italy, Spain, Mexico, Costa Rica, Bolivia, Chile, Brazil, Argentina and Paraguay, from Thursday 18 to Saturday 20 of July at the Polytechnic Faculty of the National University of Asuncion in San Lorenzo campus.

The first presentations covered the Hispanic community, the reality of the companies linked to the FLOSS in Paraguay and the difficulties faced by women workforce in the technological field. An official photo of the participants followed.

Starting the afternoon Henry Castro (Bolivia) talked on the development and technical challenges of LibreOffice Online. He was followed by José Gattica (Chile) talk on “Migration to LibreOffice in a vulnerable school”. Simultaneously, Mauricio Baeza (Mexico) gave the workshop on macros in the computer lab.

Xiomara Céspedes talked about the migration to LibreOffice and open document formats at the University of Costa Rica. She was followed by Renato Barsotti (Argentina) experience of the Faculty of Economics of the National University of Misiones (UnaM).

The next day morning, Olivier Hallot (Brazil) shared with the attendees the details about the importance of documenting the software. Simultaneously, Klaibson Ribeiro (Brazil) conducted the Calc workshop.

Italo Vignoli (Italy) talked about the characteristics of the LibreOffice community on a global scale, presenting graphs and figures to support the features and trends of the people involved in LibreOffice. He was followed after lunch by Xisco Fauli (Spain) on LibreOffice Development and Quality Control. At the same time, the certification team reviewed and approved the application of Rute Solipa (Portugal) for Professional Instructor and Xiomara Céspedes (Costa Rica) as Certified Migration Consultant in a video call session with Lothar Becker (Germany), Italo Vignoli and Gustavo Pacheco.

Italo Vignoli returned to give two presentations, the first one explaining the certification policy of The Document Foundation and the second one addressing the importance of adopting and using open documents formats such as the ODF standard.

The conference ended with the testimony of the participating students and the general public about the personal gains from the themes and knowledge presented at the conference and, in particular, the individual commitment to create a genuinely Paraguayan LibreOffice community and focus on LibreOffice translated into Guarani.

UK Government Digital Service joins The Document Foundation Advisory Board

Berlin, July 22, 2019 – The Document Foundation (TDF) announces that the UK’s Government Digital Service (GDS) has joined the project’s Advisory Board, effective immediately.

The Government Digital Service (GDS) is part of the UK Cabinet Office [1]. It leads the digital transformation of Government in the UK, helping people interact with government more easily and supporting government to operate more effectively and efficiently.

In July 2014, the UK Cabinet Office announced the selection of the Open Document Format (ODF) for sharing and viewing government documents.

The Open Standards Team within GDS support and encourage the use of open standards in government. Their aim is to help identify and contribute to open standards for software interoperability and to promote data formats that will help to meet user needs across the UK government and support the delivery of common components.

“GDS has been a long-term supporter of the adoption of Open Document Format, and their participation in the TDF Advisory Board represents a strong endorsement of the project’s commitment to the advancement of open standards and ODF”, says Simon Phipps, TDF Director.

John Strudwick, Interim Director for Service Design and Assurance at GDS, said: “GDS are delighted to have joined the Advisory Board of TDF. We believe that open standards are important in meeting the needs that users have of Government and that ODF plays a big role in helping to deliver this.”

TDF Advisory Board’s (AB) [2] primary function is to represent supporters of the project, and to provide the Board of Directors (BoD) with advice and guidance. In addition, the AB is at the kernel of the LibreOffice ecosystem, and as such is key to the further development of the project.

[1] https://www.gov.uk/government/organisations/cabinet-office
[2] https://www.documentfoundation.org/governance/advisory-board/

LibreWaterloo: Building the LibreOffice community in Canada

If you’ve seen our LibreOffice contributor map, you’ll note that we have a few community members in north America. (Of course, the map doesn’t show absolutely everyone in the LibreOffice project – just people we’ve interviewed recently.) So we want to grow this community! Marc Paré has set up LibreWaterloo, to:

have a local presence on the Canadian scene with respect to the LibreOffice project and software. We would like to connect with local LibreOffice coders and users, and “to have fun” should be one of the pillars and principles we strive for.

So, how did Marc go about it, and what was the first meeting like? Here’s what he had to say:

I spoke at a meeting of the KW Non-Profit Sys Admin (KWNPSA) where I am a co-coordinator, and I announced the creation of the new LibreWaterloo community group. There, I did a two hour presentation on the status of The Document Foundation, along with LibreOffice and the benefits of starting a group.

There were approximately 15 people at the meeting, and a couple of people came to trouble-shoot their software; however, the meeting was not to trouble-shoot issues, but to discuss if there was an interest from the Sys Admin group.

We now have an organizing committee of three people, and we’ll meet in the next two or three weeks to start formalizing the community and shape its mission statement etc. I will be placing an advert in the local student newspaper at University of Waterloo announcing the community and hope to attract some young devs to the community, I also hope to meet with a local technical writer who teaches technical writing courses at our local college and universities – I will see if she would like to cooperate on her classes and perhaps have her students work on some of the LibreOffice Guides.

I also plan on contacting a national indigenous organization and see if they or we could help to organize indigenous language versions of LibreOffice. The Canadian government has put aside a large sum of money to help groups conserve indigenous languages in Canada; we are losing approximately one indigenous language every two-three weeks, as our indigenous elders are dying and their culture is also dying with them. I will see if we could apply for funds.

We will be organizing monthly meeting on a regular schedule and hope to have working groups set up sometime by October or November.

Thanks Marc! Everyone in the Waterloo area is welcome to come along – check out Twitter for updates, or this page on Meetup. Want to start (or expand) the LibreOffice community in your region? drop us a line on the marketing mailing list and we’ll give you a hand!

Annual Report 2018: LibreOffice development

In 2018, 17,473 commits were made to the LibreOffice source code, from 223 authors. Here’s an overview of what they worked on…

Behind the scenes of LibreOffice 6.2

Throughout the second half of 2018, the developer community worked on a new major release: LibreOffice 6.2. Details about the end-user-facing new features are provided on this page, and in the following video – so in the rest of this blog post, we’ll focus on developer-related changes.

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

So, let’s get technical!

In terms of system requirements, the macOS minimum version was bumped up to 10.9 (and will be 10.10 in LibreOffice 6.3). Similarly, binary Linux x86 (32-bit) releases from The Document Foundation were deprecated, so there will be no Linux x86 builds produced by TDF after LibreOffice 6.2. However, this does not mean that Linux x86 compatibility will be removed; Linux distributions can still opt to build 32-bit binaries. See here for more details.

On the user interface front, there were other changes. Two new VCL plugins (qt5 and kde5) were implemented (with the KDE5 plugin extending the Qt5 one), to provide integration with KDE Plasma 5 and other Qt5-based desktop environments. These were mainly implemented by Katarína Behrens (CIB) and Jan-Marek Glogowski (City of Munich).

If the kde5 and the gtk3_kde5 plugins are installed, the desktop detection will now prefer the kde5 one. The qt5 plugin must be explicitly selected via SAL_USE_VCLPLUGIN=qt5, as it’s never selected automatically.

Native copy and paste of spreadsheet data in Writer tables was implemented by László Németh (NISZ): previously, you could paste a copied table as image, object, plain text, and as RTF; the latter resulting in a new table in Writer. In LibreOffice 6.2 you can paste directly in an existing table.

Data Validation now supports custom formulas thanks to Marco Cecchetti (Collabora), while Edit > Track Changes > Show no longer severely impacts performance in documents with many tracked changes. The document view is now capable of hiding the tracked changes, so they do not have to be rearranged in the document model to be hidden – implemented by Michael Stahl (CIB).

LibreLogo, the programming interface for graphic design and education got unit testing, IDE and compiler fixes and improvements (László Németh – FSF.hu Foundation). Meanwhile, work continued on the native GTK3 UI, as demonstrated by Caolan McNamara (Red Hat) at FOSDEM 2018:

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Google Summer of Code

The Google Summer of Code (GSoC) takes place every year, and provides university students with funding to work on free and open source software. For 2018, seven LibreOffice developers were accepted into GSoC, and they worked on various features and updates. These improvements were presented in a session at the LibreOffice Conference in Tirana, Albania.

Daniel Silva showed his work on the revamped print dialog, which reorganised options into two tabs, to make them easier to find: a General tab, covering all components of the suite, and then a separate tab for component-specific features (ie those found in Writer, Calc, Impress and so forth). Altogether, this makes it easier for end users to find the options they need, without having to look through many different tabs.

Meanwhile, Mert Tümer worked on the LibreOffice Android Viewer as part of GSoC: he produced 23 patches, made up of nine new features and 14 bug fixes. Some of the new features include Export to PDF, printing, customising worksheets, and better language support.

Saurav Chirania implemented a logger for user interface testing, which logs interactions and stores them in a file, while Vikas Mahato worked on features for importing data from external sources, along with transformations for the data (38 types of transformation were implemented). Finally, Hrishabh Rajput worked on updating listbox widgets to separate read values from input values, Kshitij Pathania added some improvements to the Notebookbar, and Shobhan Mandal focused on adding support for Python in the LOEclipse plugin.

A big thanks to everyone who contributed code last year! Why not join them?

You don’t need to be the world’s best C++ wizard to get involved – just some C++ knowledge and willingness to explore the codebase is great!

We have Easy Hacks to get your started, so check out this page for inspiration. Cheers!

What is the Open Document Format (ODF), and how is it developed?

Regina Henschel is a long-time member of the LibreOffice community, and has worked on ODF, the native file format of the suite. At our recent German community meetup, we talked to her about how ODF is developed, and how users can help to improve it…

Tell us a bit about ODF…

Open Document Format is LibreOffice’s native file format. (If you have a file with a .odt, .ods, .odp or .odg extension, then it’s an Open Document Text, Spreadsheet or Presentation file or Graphic respectively.)

ODF is developed by OASIS, then submitted to ISO (the International Organization for Standardization), and then adopted as a standard. There is also a working group at ISO, which by the way also works on OOXML – which can then ask questions about development, and so on.

For ODF we are now working on version 1.3. We had a “feature freeze” last summer. We have come so far that everything we wanted to have in it is available in the “editor version”. Now we’re going to fine-tune it, then we’ll be back in summer – so that was a whole year. Then comes the coordination process at OASIS, so it usually takes two years until a new version of the standard is ready.

How do you decide which new features to add?

The feature has to be well defined, and that depends a little on how good the proposal you get is. There are some suggestions like: “We want to have a feature for Fourier transformations” – but nothing else! And then we say: as long as there is no implementation that actively handles it, we’ll postpone it for later. It’s not worth it, for a standards body to deal with a proposal like this, if there are no applications that are actually interested in it.

ODF exists as a “strict” standard, for features that are fully standardized, and then there is an “extended mode” in which you can try out new features in applications. They then run under their own namespace, and if that works, organizations can make a suggestion for OASIS, eg: “This feature works well for us, so please include this in the strict standard.”

Then others can say: “Yes, we want to do something similar, but it would be better for us if we didn’t call it X, but Y instead”. Or: “We need an additional attribute to make it work for us”, for example. In situations like that, the proposals are discussed.

For example, in LibreOffice, it’s now possible to specify the size of charts, independent of their labels. In the old standard, you could only set the size including the label. This means that when data changed and the label changed, the effect was that the size of the chart changed. So that’s been fixed in ODF 1.3.

There are also bugfixes, where there are things that are simply wrong, or that are not clear enough for implementation. For example, one thing that was really incorrect was to put the units “at” and “atm” on the same level – that was definitely wrong. And one time, a matrix form was wrong as well. So we work on fixes for these.

Can normal end-users help out?

Yes, you can be a “normal person”, so to speak, without being on any committee – you can still send something to the Technical Committee. There is a mailing list, and also a homepage, where you can get informed about the work of the committee. There you can also find a link to the mailing list – but you have to register, because of spam. Messages on this list are then read and answered by the Committee.

The second way to get involved is when the Committee is about to make a new version of ODF. This will then be made available for voting – and then there will be an official time for comments. There the regulations are a bit stricter; this is not voluntary, but the committee has to actually work on these comments. That should then give a qualified answer.

The next step where official participation takes place is at ISO. They have the same disclosure process again, where comments are collected accordingly. Then the Technical Committee gets a long list from ISO: “We have received these comments, please discuss them.”

So this is a process that is very open. That’s one of the reasons why I decided to join the Committee. It’s not that something happens in secret, and then suddenly there’s a standard – but rather, the process is totally comprehensible.

The other thing that interested people can see is the archives of the mailing lists – and there are weekly teleconferences too.

Thanks to Regina for all her help over the years! ODF – and other open standards – are incredibly important, especially for long-term data storage. Indeed, the UK government recommends using ODF, and has guidelines for using the format in organisations and companies. Also check out this presentation from Regina at FOSDEM 2018.

Start developing LibreOffice! Download the source code, and build on Windows

Please don’t use these instructions in practice – they become obsolete over time. Instead, follow the wiki article for building on Windows.

(This post was originally written in Hungarian by Adam Kovacs for his blog. Thanks Adam!)

In our previous post in this series, we looked at building on Linux. But it’s also possible to download and compile the LibreOffice source code on Windows, so that’s what we’ll demonstrate here!


Step 1: Download and install Visual Studio Community version (free)

Get it from the Visual Studio website. Add these components during installation:

  • MSVC v142 – VS 2019 C++ x64/x86 build tools (v14.2x)
  • C++ core features
  • Windows 10 SDK (10.0.xxxxx.x)
  • Windows Universal C Runtime
  • C++ ATL for v142 build tools (x86 & x64)
  • .NET Framework 4.x.x SDK
  • C++ 2019 Redistributable MSMm (only required to build MSI installer)

Step 2: Download and install openJDK

Get these:


Step 3: Download and install Cygwin

Get it from here. Then, in a command prompt, access the Cygwin installer directory, for example:

cd c:\Users\username\Desktop\

And run the following command:

setup-x86_64.exe -P autoconf -P automake -P bison -P cabextract -P doxygen -P flex -P gcc-g++ ^
-P gettext-devel -P git -P gnupg -P gperf -P make -P mintty ^
-P nasm -P openssh -P openssl -P patch -P perl -P python -P python3 ^
-P pkg-config -P rsync -P unzip -P vim -P wget -P zip -P perl-Archive-Zip ^
-P perl-Font-TTF -P perl-IO-String

(This command installs different dependencies, including packages and programs, that are needed to compile LibreOffice.)

If you later want to install new programs or packages in Cygwin, you can also restart the installer. Then, when you can select the programs from the list, look for the appropriate name (eg nano, mc, wdiff) and in the drop-down list, change pending to full.


Step 4: Download JUnit and Ant

From now on, all commands are run in Cygwin.

mkdir -p /cygdrive/c/sources
cd /cygdrive/c/sources
wget https://archive.apache.org/dist/ant/binaries/apache-ant-1.9.5-bin.tar.bz2
tar -xjvf apache-ant-1.9.5-bin.tar.bz2
wget http://downloads.sourceforge.net/project/junit/junit/4.10/junit-4.10.jar

(These commands will download JUnit and Ant to the c:\sources folder. The path of Ant will be, for example: c:\sources\apache-ant-1.9.5, which should be specified later in autogen.input.)


Step 5: Download Make

mkdir -p /opt/lo/bin
cd /opt/lo/bin
wget http://dev-www.libreoffice.org/bin/cygwin/make-4.2.1-msvc.exe
mv make-4.2.1-msvc.exe make
chmod a+x make

(This will allow you to start the actual compilation later.)


Step 6: Download the LibreOffice source code

Create a directory for LibreOffice somewhere (eg in your home directory), and then go into it:

mkdir ~/libreoffice
cd ~/libreoffice

This command downloads the source files to the current directory (the “.” character):

git clone git://gerrit.libreoffice.org/core .

If the current directory is not specified as a parameter, it will create a “core” directory and download the files.

Another example: this command creates a directory called “libreoffice” in the current directory, and downloads the source code into this newly created directory:

git clone git://gerrit.libreoffice.org/core libreoffice

In the event of a download error, try replacing git:// with https://.


Step 7: Edit autogen.input

In the LibreOffice folder, create a file named autogen.input with the following content (replace the paths with the actual ones):

--enable-64-bit
--enable-debug
--with-ant-home=/cygdrive/c/cygwin64/source/apache-ant-1.9.5
--with-jdk-home=/cygdrive/c/Program Files (x86)/ojdkbuild/java-1.8.0-openjdk-1.8.0.181-1 
--disable-odk
--with-visual-studio=2019

If you still need some settings in autogen.input, you can use the ./autogen.sh –help command to list all possible settings.


Step 8: Run autogen.sh

cd ~/libreoffice
./autogen.sh

Step 9: Run “make” (this starts the actual compilation)

/opt/lo/bin/make

If you would like to compile without unit tests (so if you don’t want to check that what you have changed in the source code will cause regressions), use the “build-nocheck” parameter:

/opt/lo/bin/make build-nocheck

Note: if you forget to add a specific option (such as –enable-debug) to autogen.input, and then add it and run “autogen.sh” and “make” again, it no longer updates the existing files, so the new settings do not apply. You must then run a “make clean” first, and then run “make” again:

/opt/lo/bin/make clean
/opt/lo/bin/make

(The latter can of course be run with the “build-nocheck” parameter.)


Step 10: Run the newly built version of LibreOffice

When compilation has finished, you can start it from the LibreOffice directory:

./instdir/program/soffice
./instdir/program/soffice --writer
./instdir/program/soffice --calc

At this point, a lot of information is written to the command line while running LibreOffice. We can turn them off like this:

SAL_LOG=-INFO instdir/program/soffice

Now only SAL_DEBUG type values will be written to the command line (if they are already placed in the code somewhere).

If you just want to convert a file (for example, to fix export errors), you can do so. The converted file is then created in the LibreOffice directory (it is therefore advisable not to place the files to be converted in the LibreOffice directory, to avoid confusing them with the files that have already been converted). For instance:

SAL_LOG=-INFO instdir/program/soffice --convert-to docx ../chart_borderline.docx

Additional information

When the compilation is finished, and we modify the contents of one of the source files, we will start the compilation again. But this will not compile the entire codebase from scratch (unless we run the “make clean” command), but it only compiles the files we modified, which is a significant time saving.

If we forget to include a setting in autogen.input, but the compilation has already been done, then it is not enough to add the setting and start the compilation again – we also need to run make clean before.

For example, if we compiled without –enable-debug, add –enable-debug to the autogen.input file, then run make clean, followed by make or make build-nocheck.

You can also compile specific modules of LibreOffice:

/opt/lo/bin/make sw

Or:

/opt/lo/bin/make build-nocheck sw

These are the names of the modules:

  • sw: Writer (formerly StarWriter)
  • sc: the spreadsheet (Calc)
  • sd: Impress and Draw
  • dbaccess: database manager (Base)
  • starmath: formula editor
  • oox: source code files for importing and exporting Office Open XML files (docx, xlsx, pptx, …)
  • chart2: source code files for managing charts

For more modules, see here.