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, and why it’s important…

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.

LibreOffice 6.3 will offer a new tabbed layout called tabbed compact. Focus are users with widescreen and a simple user interface.

Install LibreOffice 6.3 RC1 and give me feedback. You can change the UI via menubar -> View -> Layout.

The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 6.3 RC1 is ready for testing!

LibreOffice 6.3 will be released as final in mid August, 2019, being LibreOffice 6.3 RC1 the forth pre-release since the development of version 6.3 started in mid November, 2018 ( See the release plan ). Since LibreOffice 6.3 Beta2 ( the previous pre-release ), 123 commits have been submitted to the code repository and 66 bugs have been fixed. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 6.3 RC1 can be downloaded from here, it’s available for Linux, MacOS and Windows. ( Note tha it will replace your actual installation )

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email address in order to create a new account ) so it can get fixed before LibreOffice 6.3 final is released.

For help, you can contact us directly in our IRC channel.

Happy testing!!

…

(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!

(Note: if you encounter problems following this guide, please also check this wiki page.)

---

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

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

• C++ compiler
• Windows SDK 10
• UCRT library
• Visual C++ ATL for x86 and x64
• .NET Framework SDK

---

Step 2: Download and install openJDK

Get these:

• https://openjdk.java.net/install/
• https://jdk.java.net/11/
• https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_windows-x64_bin.zip

---

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:

--enable-64-bit
--enable-debug
--with-visual-studio=2017
--with-windows-sdk=10.0
--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 
--without-junit
--without-helppack-integration
--enable-extension-integration
--enable-scripting-beanshell
--enable-scripting-javascript
--disable-ext-wiki-publisher
--disable-ext-nlpsolver
--disable-online-update
--enable-breakpad
--disable-odk
--disable-gtk
--with-myspell-dicts
--enable-mergelibs
--enable-pch
--disable-ccache
--disable-firebird-sdbc

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.

Today we’re talking to Jun Nogata from our Japanese community!

To start, tell us a bit about yourself!

So, I live in Himeji, Japan where UNESCO World Heritage site Himeji Castle is. I work a part-time lecturer at a local university.

I am a big fan of free and open source software (FOSS). I started to use Linux from Slackware 95, and I’m using Debian Sid at the moment. I am active in the Debian community in Japan and I’m also an OpenStreetMap mapper.

I like listening to indie rock music, playing guitar and DJing sometimes. Also, I’m learning Korean – I want to talk to my friend DaeHyun Sung from the Korean LibreOffice community!

Oh, and I created the LibreOffice Impress templates “Midnight Blue” and “Alizarin” – thank you for using them. On social media, you can find me on Twitter and Facebook.

What are you working on in LibreOffice at the moment?

I am working on the Japanese Ask LibreOffice website as answerer and moderator – and I’m also involved in marketing and public relations for the Japanese team.

Previously, there was no marketing from the Japanese team. December 2018, I started to post information about LibreOffice from the Japanese community Facebook and Twitter accounts. There were reactions from the users, like: “I was worried that there was no information about LibreOffice, but now it’s getting better.”

I talked to the Japanese team about the necessity of creating a blog, to share and communicate information outside of social networking services. Naruhiko Ogasawara consulted with Italo Vignoli to create the blog for the Japanese team. I am happy to add information about LibreOffice in Japanese to the blog.

Is there anything else you’d like to work on in the future?

I would like to try to improve the Japanese settings. LibreOffice is known as “cost-free, but poor-quality office software” in Japan because LibreOffice’s settings are not appropriate for the language.

In Japanese, for example, you can set characters per line and lines per page to determine the page layout, but the page style text grid is not able to specify characters per line and lines per page due to improper implementation. (If you are interested, please set 37 characters x 30 lines, without changing the font and ruby size.) I will try to fix these settings and change the bad image.

How did you originally get involved with LibreOffice – and what was the experience like?

As a user, I was attending the “Kansai LibreOffice Group” (関西LibreOffice勉強会) hosted by Shinji Enoki. My templates were included in LibreOffice 4.4 – it was a big surprise, and a pleasure for me that I could contribute to LibreOffice without changing the source code. A big thanks to the whole community for LibreOffice!

Finally, what do you see in the future for LibreOffice? What does it need most?

Ideally? users in all languages can use LibreOffice without changing any settings. The paragraph style of Writer is “Align left”, but in Japanese, “Justified” is standard. Japanese users need to change the settings before writing documents. That is very difficult.

However, if set the default setting to “Justified”, Americans and people who speak European languages will be in trouble. So I think that LibreOffice can create a mechanism to resolve conflicting settings in different languages.

Thanks Jun! Japanese LibreOffice users are welcome to join us and get involved in the project – we look forward to meeting you! (Also check out the English page too.)

This week:

I was implementing the Compiler of the UI Objects:
      
        1) ButtonUIObject
        2) CheckBoxUIObject   
        3) TabControlUIObject
        4) ComboBoxUIObject
        5) RadioButtonUIObject
        6) ListBoxUIObject
        7) SpinFieldUIObject
        8) EditUIObject       

Also, I implemented a simple algorithm that will remove some redundant lines for example with the old logger we may have this:



now we will get this doing same functionality:




All this changes can be found here:
https://gerrit.libreoffice.org/#/c/75156/


Also, thier was missing part in the Close Dialog Compiler it's now implemented here:
https://gerrit.libreoffice.org/#/c/75165/

Also, This week I worked in the Special Commands from the writer application and implement:

    1) Type Command
    2) Select Command
    3) GoTo page

this can be found here: 
https://gerrit.libreoffice.org/75171


Next Week I will try to finish the Compiler of all the Special Commands and the General Commands and start imtergrating and testing the project total.

LibreOffice 6.3 is being developed by our worldwide community, and is due to be released in early August 2019 – see the release notes describing the new features here.

In order to find, report and triage bugs, the LibreOffice QA team is organizing the second Bug Hunting Session for LibreOffice 6.3 on Monday July 08, 2019.

Tests will be performed on the first Release Candidate version, which will be available on the pre-releases server a few days before the event. Builds will be available for Linux (DEB and RPM) with GTK3 and KDE5 support, macOS and Windows. ( Note that it will replace your actual installation)

Mentors will be available from 07:00 UTC to 19:00 UTC for questions or help in the IRC channel #libreoffice-qa and the Telegram QA Channel. Of course, hunting bugs will be possible also on other days, as the builds of this particular Release Candidate (LibreOffice 6.3.0 RC 1) will be available until mid July. Check the Release Plan.

General Activities

1. LibreOffice 6.3 beta2 was released for testing on June, 25
2. The bibisect repositories from libreoffice-6-3-branch-point to latest master for Windows and Linux are available for cloning
3. Miklos Vajna (Collabora) keeps working on btLr text direction
4. Balazs Varga (NISZ Team) keeps improving Chart interoperability
5. Noel Grandin (Collabora) keeps fixing performance issues. See ‘List of performance issues fixed’ below
6. Arkadiy Illarionov is working on removing duplicated code
7. Regina Henschel is working on converting Fontwork to TextWarp on export
8. Jan-Marek Glogowski keeps improving Qt5 support
9. Grzegorz Araminowicz (Collabora) keeps improving SmartArt support
10. Tünde Tóth (NISZ Team) fixed some hyperlink interoperability problems
11. Tomaž Vajngerl (Collabora) keeps improving support for iOs
12. László Németh (NISZ Team) keeps working on improving tracking changes interoperability
13. Thorsten Behrens (CIB) added support for PDF/A-2 export
14. Roman Kuznetsov updated the fonts in the window installer
15. Jim Raykowski fixed some undo and UI bugs

Reported Bugs

544 bugs, 74 of which are enhancements, have been reported by 282 people.

Top 10 Reporters

1. Telesto ( 57 )
2. NISZ LibreOffice Team ( 22 )
3. Xisco Faulí ( 15 )
4. Roman Kuznetsov ( 13 )
5. Markus Elfring ( 11 )
6. Robert Großkopf ( 10 )
7. BottleOnTheGround ( 9 )
8. Regina Henschel ( 7 )
9. sergio.callegari ( 7 )
10. Buovjaga ( 7 )

Triaged Bugs

545 bugs have been triaged by 80 people.

Top 10 Triagers

1. Xisco Faulí ( 139 )
2. Dieter Praas ( 67 )
3. V Stuart Foote ( 34 )
4. raal ( 31 )
5. Julien Nabet ( 19 )
6. Alex Thurgood ( 14 )
7. Timur ( 13 )
8. Heiko Tietze ( 13 )
9. Olivier Hallot ( 12 )
10. Roman Kuznetsov ( 11 )

Resolution of resolved bugs

622 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

206 bugs have been fixed by 40 people.

Top 10 Fixers

1. Caolán McNamara ( 21 )
2. Jan-Marek Glogowski ( 17 )
3. Miklos Vajna ( 11 )
4. Eike Rathke ( 10 )
5. Noel Grandin ( 9 )
6. László Németh ( 7 )
7. Roman Kuznetsov ( 7 )
8. Jim Raykowski ( 6 )
9. rizmut ( 6 )
10. Balazs Varga ( 6 )

List of crashes fixed

1. tdf#101473 [EDITING] Function wizard crashes LibO when evaluating addin that implement XVolatileResult ( Thanks to Eike Rathke )
2. tdf#111522 SdrUndoMoveObj::Undo() Crash When multi windows ( Thanks to Miklos Vajna )
3. tdf#122200 kde5: Crash when navigating tree in accerciser (Accessibility Explorer) ( Thanks to Michael Weghorn )
4. tdf#125333 Crash on repeated searches with FindReplaceRememberedSearches=0 ( Thanks to heiko tietze )
5. tdf#125382 Crash when check a “Personal Letter” on Letter Wizard ( Thanks to Xisco Fauli )
6. tdf#125624 CRASH working with file with lots of hints ( Thanks to Mike Kaganski )
7. tdf#125660 COMPARE DOCUMENTS: Crash in swlo!SwRedlineData::SetSeqNo ( Thanks to Michael Stahl )
8. tdf#125670 Crash in: OutputDevice::InitClipRegion on Slide show ( Thanks to Caolán McNamara )
9. tdf#125685 crash in layout after paste on particular document ( Thanks to Michael Stahl )
10. tdf#125692 kde5: Impress crashes when closing after using presentation minimizer ( Thanks to Jan-Marek Glogowski )
11. tdf#125741 Crash: swlo!SwFrame::PrepareCursor ( Thanks to Michael Stahl )
12. tdf#125751 Crash: ntdll!RtlEnterCriticalSection ( Thanks to Michael Stahl )
13. tdf#125754 Crash swlo!SwAnchoredDrawObject::IsValidPos ( Thanks to Michael Stahl )
14. tdf#125821 Crash on insertion of video ( Thanks to Jan-Marek Glogowski )
15. tdf#125840 Crash when trying to customize Base Data View toolbar ( Thanks to Muhammet Kara )
16. tdf#125866 crash when adding path/file to header in page style dialog ( Thanks to Caolán McNamara )
17. tdf#125982 Crash when opening Tools > Language > Hangul/Hanja Conversion in Calc ( gtk/gtk3) ( Thanks to Caolán McNamara )
18. tdf#125983 CRASH: Updating link to external files ( Thanks to Noel Grandin )
19. tdf#126000 Crash deleting template ( Thanks to Noel Grandin )
20. tdf#126017 Crash swlo!SwNode::EndOfSectionIndex ( Thanks to Michael Stahl )
21. tdf#126020 LO Impress: Change slide vith video leads to crash ( Thanks to Jan-Marek Glogowski )
22. tdf#126054 Crash when you select “File|Create Master Document” and save (Groupedbar Compact) ( Thanks to Caolán McNamara )
23. tdf#126134 CRASH: closing LibreOffice while printing long file (gen) ( Thanks to Caolán McNamara )
24. tdf#126137 CRASH: clicking on table ( Thanks to Xisco Fauli )

List of performance issues fixed

1. tdf#113112 EDITING: Adding a new sheet before a existing large sheet is pretty slow ( Thanks to Noel Grandin )
2. tdf#121094 Performance: Opening xlxs with many rows takes several minutes ( Thanks to Noel Grandin )
3. tdf#125591 FILEOPEN: DOC: performance regression opening a file with EMF images ( Thanks to Miklos Vajna )
4. tdf#125661 Copying a large sheet is very slow ( Thanks to Dennis Francis )
5. tdf#125665 Big ODT documents take too long to load or save ( Thanks to Noel Grandin )
6. tdf#125691 FILEOPEN: Document hangs at import time ( with OOO_EXIT_POST_STARTUP ) ( Thanks to Dennis Francis )
7. tdf#125706 Fields have noticeable impact on loading/saving performance ( Thanks to Noel Grandin )
8. tdf#67538 XTypeDetection::queryTypeByDescriptor poor performance ( Thanks to Noel Grandin )

List of old bugs ( more than 4 years old ) fixed

1. tdf#48041 Impress FILEOPEN: diagram in pptx file looks wrong, vertical axis lines duplicated ( Thanks to Balazs Varga )
2. tdf#54819 EDITING: with “track changes” the paragraph following a deleted paragraph changes its style ( Thanks to László Németh )
3. tdf#67538 XTypeDetection::queryTypeByDescriptor poor performance ( Thanks to Noel Grandin )
4. tdf#70234 FILESAVE: DOC/DOCX – Track change of fields not saved correctly ( Thanks to László Németh )
5. tdf#75659 FILEOPEN: Imported .docx charts missing legend with default name ( Thanks to Balazs Varga )
6. tdf#78657 FILESAVE: When saving a DOCX that has a picture with a hyperlink on it – the hyperlink is lost ( Thanks to Tünde Tóth )
7. tdf#88287 UI: Rename “Lines” toolbar and removing “Arrows” toolbar from View > Toolbars ( Thanks to Roman Kuznetsov )
8. tdf#89709 TOOLTIP: Page number tooltip doesnt appear in document with a single page ( Thanks to Jim Raykowski )
9. tdf#89884 Icons for bold, italics and underline should not be tied to the English UI keyboard shortcuts ( Thanks to Rizal Muttaqin )
10. tdf#89991 Save ODT as DOCX turns on Show Changes when Record Changes also on ( Thanks to László Németh )
11. tdf#92079 Basic Dialog image background not set ( Thanks to Miklos Vajna )
12. tdf#92083 Color bar should be included in the View menu ( Thanks to Roman Kuznetsov )
13. tdf#92503 FILEOPEN: CSV – Certain date fields not imported correctly, pattern detected ( Thanks to Eike Rathke )

WORKSFORME bugs

84 bugs have been retested by 38 people.

Top 10 testers

1. Xisco Faulí ( 21 )
2. V Stuart Foote ( 6 )
3. Cor Nouws ( 5 )
4. Buovjaga ( 5 )
5. Dieter Praas ( 5 )
6. Telesto ( 4 )
7. Julien Nabet ( 4 )
8. Thomas Lendo ( 3 )
9. Aron Budea ( 2 )
10. Heiko Tietze ( 2 )

DUPLICATED bugs

80 bugs have been duplicated by 33 people.

Top 10 testers

1. Xisco Faulí ( 24 )
2. V Stuart Foote ( 6 )
3. Dieter Praas ( 5 )
4. Timur ( 3 )
5. Alex Thurgood ( 3 )
6. Justin L ( 3 )
7. Roman Kuznetsov ( 3 )
8. Jan-Marek Glogowski ( 3 )
9. Oliver Brinzing ( 3 )
10. Thomas Lendo ( 3 )

Verified bug fixes

101 bugs have been verified by 19 people.

Top 10 Verifiers

1. Xisco Faulí ( 58 )
2. BogdanB ( 10 )
3. Roman Kuznetsov ( 5 )
4. Buovjaga ( 3 )
5. Julien Nabet ( 3 )
6. Vera Blagoveschenskaya ( 3 )
7. Wolfgang Jäger ( 2 )
8. Cor Nouws ( 2 )
9. Michael Weghorn ( 2 )
10. Dieter Praas ( 2 )

Categorized Bugs

507 bugs have been categorized with a metabug by 43 people.

Top 10 Categorizers

1. Thomas Lendo ( 142 )
2. Dieter Praas ( 97 )
3. V Stuart Foote ( 49 )
4. Roman Kuznetsov ( 38 )
5. Xisco Faulí ( 35 )
6. NISZ LibreOffice Team ( 16 )
7. Rizal Muttaqin ( 15 )
8. Gabor Kelemen ( 13 )
9. Muhammet Kara ( 12 )
10. Mark Hung ( 8 )

Regression Bugs

108 bugs have been set as regressions by 19 people.

Top 10

1. Xisco Faulí ( 37 )
2. Telesto ( 14 )
3. Roman Kuznetsov ( 10 )
4. raal ( 10 )
5. NISZ LibreOffice Team ( 9 )
6. Thomas Lendo ( 5 )
7. Alex Thurgood ( 3 )
8. Jacques Guilleron ( 3 )
9. Cor Nouws ( 3 )
10. Dieter Praas ( 2 )

Bisected Bugs

80 bugs have been bisected by 12 people.

Top 10 Bisecters

1. Xisco Faulí ( 41 )
2. raal ( 9 )
3. Aron Budea ( 8 )
4. NISZ LibreOffice Team ( 8 )
5. artur ( 3 )
6. Gabor Kelemen ( 3 )
7. Roman Kuznetsov ( 2 )
8. Justin L ( 2 )
9. Michael Stahl (CIB) ( 1 )
10. Oliver Brinzing ( 1 )

Evolution of Unconfirmed Bugs

Check the current list of unconfirmed bugs here

Evolution of Open Regressions

Check the current list of open regressions here

Evolution of Open bibisectRequests

Check the current list of open bibisectrequests here

Evolution of Highest Priority Bugs

Check the current list of highest priority bugs here

Evolution of High Priority Bugs

Check the current list of high priority bugs here

Thank you all for making Libreoffice rock!
Join us and help to keep LibreOffice super reliable!
Check the Get Involved page out now!…

At week 4 I have finished the first phase of the new UI logger which was the grammar and the new sentences of the log messages and rewrite all the log statement with the new grammar.

This week I have started the implementation of the Compiler of the new logger grammar. This Compiler is responsible for taking the log file with the new grammar and generate a UI test case that performs the same as the user actions.

This week I write the python script that will take the input addresses from the user and the path of the test case to be generated. Also, I begin to implement the handler of each type of commands. This handler is the functions that called for each type of commands found in the grammar and start to replace it by the corresponding UI python functions that used for testing. I have finished this week the Starter handler, Uno commands Handler and Dialog handler.

This can be found here.

Also, all these changes are stored in this branch:

	private/EL-SHREIF/ui_logger

to test the new script and the new project this can be done after adding TEXTX library to our build system to be able to test it. For now, you can use any virtual env and install python and TEXTX on it then run this command:

for example, if we have this log file:

We will get this UILogger:

Week 5, again!

So I managed to sort out the blog not building. The problem was a case of incorrect syntax in the _config.yml on this site.

So I passed the evaluation and I’ll be here for another two months by the looks of it. We’ve now got a working program which starts and control LibreOffice just like planned, however it is quite rough and the next two months will be spent making it smoother and better-looking mainly, I reckon. Apart from any other work my mentors might throw at me. :)

• Start and stop LibreOffice.
• Load and close documents in LibreOffice.
• Start and transition slideshows.
• Website control panel has additional functionality for controlling the playlist and slideshows.
• Some minor additions and fixes such as making the informational screen look alright and display the correct information.

I’ve also run into problems with LibreOffice:

• Some slides (usually ones with heavy content?) give me a black screen when running LibreOffice (libreoffice-fresh from archlinuxarm) on my Raspberry Pi 3 B+ – this is quite disconcerting but might simply be due to my ancient LCD screen which needs about an hour to warm up before it works (backlight issues?), although it seems really strange. If anyone has a Raspberry Pi and feels like replicating this that would be great!

Right now I’m making some simple example presentations to use while testing the program, just to have something half-decent and realistic to look at. I have some polishing/ tweaking to do on the existing program as well.

Rasmus

I managed to sort out the blog not building. The problem was a case of incorrect syntax in the _config.yml on this site.

I passed the evaluation and I’ll be here for another two months by the looks of it. We’ve now got a working program which starts and control LibreOffice just like planned, however it is quite rough and the next two months will be spent making it smoother and better-looking mainly, I reckon. Apart from any other work my mentors might throw at me. :)

• Start and stop LibreOffice.
• Load and close documents in LibreOffice.
• Start and transition slideshows.
• Website control panel has additional functionality for controlling the playlist and slideshows.
• Some minor additions and fixes such as making the informational screen look alright and display the correct information.

I’ve also run into problems with LibreOffice:

• Some slides (usually ones with heavy content?) give me a black screen when running LibreOffice (libreoffice-fresh from archlinuxarm) on my Raspberry Pi 3 B+ – this is quite disconcerting but might simply be due to my ancient LCD screen which needs about an hour to warm up before it works (backlight issues?), although it seems really strange. If anyone has a Raspberry Pi and feels like replicating this that would be great!

Right now I’m making some simple example presentations to use while testing the program, just to have something half-decent and realistic to look at. I have some polishing/ tweaking to do on the existing program as well.

Rasmus

I’m making progress with interfacing with LibreOffice, I can now start and run slideshows, which is what the project is about at its core.

I’ll update with a screenshot/ photos of the project running on my Raspberry Pi as soon as possible.

Below is my report for week 4

These last two weeks I’ve been stuck on integrating my program with LibreOffice (mentioned in previous report), but I’ve finally figured out how to get it to work and am now back on track. I’m about two days behind schedule but I’ll catch up now the problem’s solved.

Originally this was going to be done with Impress Remote Protocol, but URP/ UNO seemed like a better choice, so we agreed to go for that. The coming weeks (5-7) were supposed to be spent adding features and doing other work related to the IRP server, I’m not sure how valid this is now and will discuss it with my mentor.

Spent most days on

• Trying different configurations, settings to connect to LibreOffice properly with UNO. Ideally it should work with any standard LibreOffice installation(?).
• Wrote scripts to test in isolation from my main program
• Reading up on UNO on https://wiki.openoffice.org/wiki
• Got it working and added a new “unoremote” interface to my program, presentations can be opened, closed, etc according to the user-curated playlist. This was basically all I was trying to do.

Rasmus

The LibreOffice Quality Assurance ( QA ) Team is happy to announce the bisect repository from libreoffice-6-3-branch-point to latest master for Windows is available for cloning at Gerrit. As a novelty, it’s the first time the bisect repository for Windows is built for 64 bits instead of 32 as in previous repositories. Future repositories will be built for 64 bits as well.

What is a bisect repository ?

it’s a git repository populated with hundreds of builds of LibreOffice. Added to the repository in chronological order, each build represents each commit in the LibreOffice core repository, allowing the QA Team to easily identify at which point a regression was introduced. Watch Effective Bisection and Bibisection (Matthew Francis’s talk at LibOCon 2015 on YouTube) for both an introduction, and practical details.…

LibreOffice is an application with a large number of expert features, and though aimed to be easy to use there are always surprising shortcuts to achieve a goal. We post every day a tip on Twitter, and with the upcoming release 6.3 there will be also a tip-of-the-day messagebox when you start the program.…

Report Week 4

Is the RSS thing working?

The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 6.3 Beta2 is ready for testing!

LibreOffice 6.3 will be released as final in mid August, 2019, being LibreOffice 6.3 Beta2 the third pre-release since the development of version 6.3 started in mid November, 2018 ( See the release plan ). Since LibreOffice 6.3 Beta1, 226 commits have been submitted to the code repository and 106 bugs have been set to FIXED in Bugzilla. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 6.3 Beta2 can be downloaded from here, it’s available for Linux, MacOS and Windows. Besides, and it can be installed along with your actual installation.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ) so it can get fixed before LibreOffice 6.3 final is released.

For help, you can contact us directly in our IRC channel.

Happy testing!!

…

This week:

As this week was my last week in my exams I worked in many minor points to finish it and finish all missing parts for phase1.

I migrate all the work in this branch :
                                 >  private/EL-SHREIF/ui_logger
This will make it easy to work on the old commits then we can merge at the end of the project.

as I found we have many lines that we will not use in the compiler in the future for example these lines:
        Action on element: urled with action : TYPE
        Action on element: urled with action : 16

So I solve this by make this function :
        OUString WindowUIObject::get_action(VclEventId nEvent) const
return empty string when we don't need to log this statement I think this won't be the best approach in the future.

this is example of what we can get now from the new logger:



Also for adding Jinja2 to use it in generation. I tried this week to create simple data structure that we can use to make same thing without any need to add external resources.

Also this week the SideBar actions wasn't implemented so I add it to the grammar as a general commands as it will be the same for all the applications.

Also this week the Select actions wasn't logged with the new grammar. I add it to the grammar as a general commands also. it will be like this:
                              >>Select  {"OBJECT": "Unnamed_Obj_0"}

Also This week I worked on adding the special command for math and impress in the grammar and write the log statements with the new grammar.

all this can be found in this patch: https://gerrit.libreoffice.org/#/c/74629/

So for phase 1 we have:
1) grammar for the new ui_logger
2) all the log statements now worked with the new grammar

to finish the project the next stage will be:
1) working on the compiler that will generate the test cases from this grammar
2) start adding new events to be logged

This week:
I continue working on Rewriting the logger messages with the new DSL grammar:

    1)EditUIObject
        It wasn't finished last week but this week it's finished with the new garmmar and can log select and write actions.

    2)Uno Commands
        some small changes to be understandable with the new grammar
        ** a missing part here that we want to ignore logging message if the parameters of the UNO command are empty as they will be logged twice which is not good.

    3)Dialog Commands
        **Sometimes we have empty dialog names I don't know now how to handle this.
   
    4)Special Commands of (writer and Calc)
        In this part we know that we use EventDescription Object to transfere what we need to the logger for example in the GOTO command we put this parameters:
            aDescription.aAction = "GOTO";
            aDescription.aParameters = {{"PAGE", aPage}};
            aDescription.aID = "writer_edit";
            aDescription.aKeyWord = "SwEditWinUIObject";
            aDescription.aParent = "MainWindow";
            UITestLogger::getInstance().logEvent(aDescription);

So in the logger we will use these parameter to construct the log statement that we need and ignore having same construction as old logger which made it not friendly in reading.

    5)Also Type Command handled alone wherever you type.

I create 2 new functions that will help in getting data from the EventDescription Object and Use it to log all available actions of Calc and writer.
Now if we want to log new action in any application after sending its parameters to logger we will need to receive these parameters and use it to make sentences that match our grammar.

You can find the patch that make all of this here.

The next step is to finish some missing parts in the Uno Commands and fix problem of Dialog Commands and add new feature helpful statements in the ObjectUI commands.Then I will start write the compiler that will make code generation.


           

The LibreOffice Quality Assurance ( QA ) Team is happy to announce the bisect repository from libreoffice-6-3-branch-point to latest master is available for cloning from Gerrit. As a novelty, this repository adds support for KDE5 environment.

What is a bisect repository ?

it’s a git repository populated with hundreds of builds of LibreOffice. Added to the repository in chronological order, each build represents each commit in the LibreOffice core repository, allowing the QA Team to easily identify at which point a regression was introduced. Watch Effective Bisection and Bibisection (Matthew Francis’s talk at LibOCon 2015 on YouTube) for both an introduction, and practical details.…

• B&B Hotel - lots of traffic noise through the closed window, ambulances to dream of; up lateish, train, Eurostar, train and so on. Reasonable connectivity - built ESC agenda a tad late while on the train encouraging using Collabora Online rather effectively; good.

• Up early, a couple of dismal, late trains to Kings Cross, and the Eurostar to OW2Con / Paris. Dodgy taxi ride, arrived somewhat late for the session. Gave a talk on LibreOffice Online and then C'bras role in it briefly.
• Caught up with Sigmund, Philippe from Arawa, Simon, and enjoyed a fine evening together with friends old & new.

• More admin, project planning, prototype acceptance criteria construction. Three lots of maths revision in the evening. Worked late putting documentation together with Kendy.

• Mail chew, worked away at project planning and acceptance criteria. Couple of project calls and sync with Kendy.

Our wiki is currently down for maintenance.

• All Saints, band in the morning. Back for a fine lunch, and out for another, much less used stretch of walk along the nearby ancient, defensive Dyke.
• Slept while H. did Organ practice, encouraging progres with the quartet. Slugged in front of a movie in the evening.

If you occassionally do performance profiling as I do, you probably know Valgrind's Callgrind and the related UI KCachegrind. While Callgrind is a pretty powerful tool, running it takes quite a while (not exactly fun to do with something as big as e.g. LibreOffice).

Recently I finally gave Linux perf a try. Not quite sure why I didn't use it before, IIRC when I tried it somewhen long ago, it was probably difficult to set up or something. Using perf record has very little overhead, but I wasn't exactly thrilled by perf report. I mean, it's text UI, and it just gives a list of functions, so if I want to see anything close to a call graph, I have to manually expand one function, expand another function inside it, expand yet another function inside that, and so on. Not that it wouldn't work, but compared to just looking at what KCachegrind shows and seeing ...

When figuring out how to use perf, while watching a talk from Milian Wolff, on one slide I noticed a mention of a Callgrind script. Of course I had to try it. It was a bit slow, but hey, I could finally look at perf results without feeling like that's an effort. Well, and then I improved the part of the script that was slow, so I guess I've just put the effort elsewhere :).

And I thought this little script might be useful for others. After mailing Milian, it turns out he just created the script as a proof of concept and wasn't interested in it anymore, instead developing Hotspot as UI for perf. Fair enough, but I think I still prefer KCachegrind, I'm used to this, and I don't have to switch the UI when switching between perf and callgrind. So, with his agreement, I've submitted the script to KCachegrind. If you would find it useful, just download this do something like:

$ perf record -g ...
$ perf script -s perf2calltree.py > perf.out
$ kcachegrind perf.out

Would you like your C++ code to compile twice as fast (or more)?

Yeah, so would I. Who wouldn't. C++ is notorious for taking its sweet time to get compiled. I never really cared about PCHs when I worked on KDE, I think I might have tried them once for something and it didn't seem to do a thing. In 2012, while working on LibreOffice, I noticed its build system used to have PCH support, but it had been nuked, with the usual poor OOo/LO style of a commit message stating the obvious (what) without bothering to state the useful (why). For whatever reason, that caught my attention, reportedly PCHs saved a lot of build time with MSVC, so I tried it and it did. And me having brought the PCH support back from the graveyard means that e.g. the Calc module does not take 5:30m to build on a (very) powerful machine, but only 1:45m. That's only one third of the time.

In line with my previous experience, on Linux that did nothing. I made the build system support also PCH with GCC and Clang, because it was there and it was simple to support it too, but there was no point. I don't think anybody has ever used that for real.

Then, about a year ago, I happened to be working on a relatively small C++ project that used some kind of an obscure build system called Premake I had never heard of before. While fixing something in it I noticed it also had PCH support, so guess what, I of course enabled it for the project. It again made the project build faster on Windows. And, on Linux, it did too. Color me surprised.

The idea must have stuck with me, because a couple weeks back I got the idea to look at LO's PCH support again and see if it can be made to improve things. See, the point is, PCHs for that small project were rather small, it just included all the std stuff like <vector> and <string>, which seemed like it shouldn't make much of a difference, but it did. Those standard C++ headers aren't exactly small or simple. So I thought that maybe if LO on Linux used PCHs just for those, it would also make a difference. And it does. It's not breath-taking, but passing --enable-pch=system to configure reduces Calc module build time from 17:15m to 15:15m (that's a less powerful machine than the Windows one). Adding LO base headers containing stuff like OUString makes it go down to 13:44m and adding more LO headers except for Calc's own leads to 12:50m. And, adding even Calc's headers, results in 15:15m again. WTH?

It turns out, there's some limit when PCHs stop making things faster and either don't change anything, or even make things worse. Trying with the Math module, --enable-pch=system and then --enable-pch=base again improve things in a similar fashion, and then --enable-pch=normal or --enable-pch=full just doesn't do a thing. Where it that 2/3 time reduction --enable-pch=full does with MSVC?

Clang has recently received a new option, -ftime-trace, which shows in a really nice and simple way where the compiler spends the time (take that, -ftime-report). And since things related to performance simply do catch my attention, I ended up building the latest unstable Clang just to see what it does. And it does:
So, this is bcaslots.cxx, a smaller .cxx file in Calc. The first graph is without PCH, the second one is with --enable-pch=base, the third one is --enable-pch=full. This exactly confirms what I can see. Making the PCH bigger should result in something like the 4th graph, as it does with MSVC, but it results in things actually taking longer. And it can be seen why. The compiler does spend less and less time parsing the code, so the PCH works, but it spends more time in this 'PerformPendingInstantiations', which is handling templates. So, yeah, in case you've been living under a rock, templates make compiling C++ slow. Every C++ developer feeling really proud about themselves after having written a complicated template, raise your hand (... that includes me too, so let's put them back down, typing with one hand is not much fun). The bigger the PCH the more headers each C++ file ends up including, so it ends up having to cope with more templates. With the largest PCH, the compiler needs to spend only one second parsing code, but then it spends 3 seconds sorting out all kinds of templates, most of which the small source file does not need.

This one is column2.cxx, a larger .cxx file in Calc. Here, the biggest PCH mode leads to some improvement, because this file includes pretty much everything under the sun and then some more, so less parsing makes some savings, while the compiler has to deal with a load of templates again, PCH or not. And again, one second for parsing code, 4 seconds for templates. And, if you look carefully, 4 seconds more to generate code, most of it for those templates. And after the compiler spends all this time on templates in all the source files, it gets all passed to the linker, which will shrug and then throw most of it away (and that will too take a load of time, if you still happen to use the BFD linker instead of gold/lld with -gsplit-dwarf -Wl,--gdb-index). What a marvel.

Now, in case there seems to be something fishy about the graphs, the last graph indeed isn't from MSVC (after all, its reporting options are as "useful" as -ftime-report). It is from Clang. I still know how to do performance magic ...

High packet loss ratio at the datacenter (or its upstream carriers) causes slowdown and service disruption. (Possibly depending on the IP protocol version and route taken.)

This year’s FOSDEM (Free and Open source Software Developers’ European Meeting) has been held in in the beautiful city of Brussels (Belgium), as usual, on February 2 & 3, 2019. It was organised by volunteers to promote the widespread use of free and open source software..

This was my first FOSDEM as a deputy member of the MC, and a fresh member of the Collabora team.

I will try to give some information about my talks, and share my experience.

TDF Meetings, LibreOffice Hackfest & LibreOffice Dinner…

The first 2 days was spent on the LibreOffice Hackfest, MC & BoD joint meetings. Seeing all friends face to face was a pleasure. We discussed some important matters face to face, and had a great time together.

Did some work on the LibreOffice themes, and discovered the ugly truth of major Mozilla API change.

We also had a community night/dinner with the LibreOffice community members on Saturday. Had pleasant chats with many friends, and a nice ‘kosher/halaal’ meal with Lior (thank you again!).

It was also a nice adventure, chasing Indian/Eastern/Asian tastes with Mike. :)

The Hotel

This year, I stayed with the pack in Bedford. Its location is perfect, but you may feel the building’s age. (In good & bad ways.) I had the first night with a semi-functional heater in the room. Not very pleasant, considering the winter of Brussels. Next day they gave a second portable heater -yay! :)-, and I survived with those.

The Talks

Talk 1: Resurrecting Mozilla Themes for LibreOffice

Past, present, and the future of LibreOffice’s Personalization dialog.

LibreOffice has had the ability to use Mozilla Themes (Personas) for some time (Tools > Options > Personalization); but it kept breaking all the time, and never had an acceptable UX. Also tons of errors/warnings, and very slow search and apply processes almost brought it to the point of being killed for good. But I couldn’t let it die, started looking into the related code and the bug reports. Now it has a better UX/UI, and got most annoying bugs/crashers fixed, and is much faster.

I tried to present a summary about the journey so far, and the plans for the future.

• Presentation video on YouTube
• The slides of the presentation on Speaker Deck

Talk 2: Document Redaction with LibreOffice

Redaction in its sanitization sense (as distinguished from its other editing sense) is the blacking out or deletion of text in a document, or the result of such an effort. It is intended to allow the selective disclosure of information in a document while keeping other parts of the document secret. Typically the result is a document that is suitable for publication or for dissemination to others than the intended audience of the original document. For example, when a document is subpoenaed in a court case, information not specifically relevant to the case at hand is often redacted. Another example is patient information of hospitals, which is distributed to be used for research purposes.

A new document redaction feature for Collabora Office is being developed, and it will also be available on the next major version of LibreOffice. This new feature will provide a much more efficient means than the traditional print-redact-scan process, and will try to prevent also the accidental leakage of redacted information by completely removing them in the resulting PDF document, rather than just hiding.

• Presentation video on YouTube
• The slides of the presentation on Speaker Deck

Overall

Again a good use of time, full of experience sharing with fellow FLOSS developers, and community members.

Looking forward to the next FOSDEM! :)

Our provider is experiencing connectivity hiccups, affecting the reachability of our services (depending on the route taken).

The work around user experience often requires to create a minimal working example. Either users report an issue or request enhancements, the comparison with the current situation is necessary. LibreOffice has a built-in feature to create dummy text (type dt and press F3) but this function inserts only unformatted text.…