General Activities

1. LibreOffice 6.4 Beta1 was announced on November 18
2. A new version of LibreOffice Impress Remote for Android was announced
3. The new LibreOffice Macro Team posted a progress report
4. Julien Nabet improved the code quality based on cppcheck results
5. Coverity’s defect density is back to 0
6. Andreas Kainz continued improving dialog layout and the UI with nearly sixty commits
7. Caolán McNamara made the customize dialog open quickly again
8. Luboš Luňák and Tomaž Vajngerl (Collabora) introduced the Skia graphics engine into the codebase. It supports rendering the UI using GPU with Vulkan.
9. Mike Kaganski (Collabora) fixed a long standing problem in basic’s syntax checker. He also added support for Windows Default apps settings
10. Stephan Bergmann (Red Hat) started the work on replacing boost::optional with std::optional
11. Justin Luth (Collabora) removed a bunch of obsolete hacks and fixed several issues related to styles and tables in Writer
12. Eike Rathke (Red Hat) made it possible to use long passwords in OOXML documents
13. Tamás Bunth (Collabora) added support for importing and exporting custom label text in DOCX documents
14. Miklos Vajna (Collabora) improved the interoperability of math objects from PPTX
15. Noel Grandin (Collabora) continued working on more than 1024 columns support for Calc, solved an acessibility-related performance issue with complex tables, made ODS documents with lots of countif functions load faster and changed various XML-handling code to use FasterParser
16. Jan-Marek Glogowski (CIB), Michael Weghorn (LHM), Katarina Behrens (CIB) keep reducing the Kf5/Qt5 funtionality gap compared to other VCL backends
17. Gülşah Köse and Tamas Bunth (Collabora) improved how PPTX rotated objects and text are imported and exported
18. Balazs Varga (NISZ) fixed the position and size of custom chart legends and digits of percentages of data points when saving OOXML charts
19. Jim Raykowski made it so list styles can be deleted in Custom Styles view
20. Bartosz Kosiorek and Chris Sherlock added support for EMF+ custom line cap
21. Michael Weghorn fixed loading printer settings with the document
22. László Németh (NISZ) fixed the table line spacing in a certain DOCX document
23. Szabolcs Toth (NISZ) fixed the displaying of table borders in a certain DOCX document
24. Samuel Mehrbrodt (CIB) added API support for the infobar

Reported Bugs

585 bugs, 67 of which are enhancements, have been reported by 365 people.

Top 10 Reporters

1. NISZ LibreOffice Team ( 28 )
2. Xisco Faulí ( 23 )
3. Mike Kaganski ( 12 )
4. Roman Kuznetsov ( 9 )
5. andreas_k ( 8 )
6. Nicolas Christener ( 7 )
7. ricky.tigg ( 7 )
8. sdc.blanco ( 6 )
9. Pablo ( 6 )
10. Nukool Chompuparn ( 6 )

Triaged Bugs

652 bugs have been triaged by 76 people.

Top 10 Triagers

1. Xisco Faulí ( 194 )
2. Heiko Tietze ( 58 )
3. Dieter Praas ( 50 )
4. Timur ( 35 )
5. Julien Nabet ( 30 )
6. Oliver Brinzing ( 29 )
7. Alex Thurgood ( 29 )
8. V Stuart Foote ( 25 )
9. Roman Kuznetsov ( 23 )
10. raal ( 15 )

Resolution of resolved bugs

610 bugs have been set to RESOLVED.

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

Fixed Bugs

236 bugs have been fixed by 43 people.

Top 10 Fixers

1. Caolán McNamara ( 32 )
2. Balazs Varga ( 12 )
3. Mike Kaganski ( 11 )
4. László Németh ( 9 )
5. Samuel Mehrbrodt ( 9 )
6. Miklos Vajna ( 8 )
7. Justin Luth ( 7 )
8. Jan-Marek Glogowski ( 7 )
9. andreas kainz ( 6 )
10. Olivier Hallot ( 6 )

List of critical bugs fixed

1. tdf#118526 CRASH: Notebookbar crashes in read mode ( Thanks to Jim Raykowski )
2. tdf#121963 button flashing – mouse wheel zooming breaks ( Thanks to Armin Le Grand )
3. tdf#128659 Cannot add AutoCorrect entries once the user/autocorr/acor_xx-XX.dat file is created ( Thanks to Noel Grandin )

List of high severity bugs fixed

1. tdf#118639 Editing password-protected non-ODF files creates multiple empty files in backup directory ( Thanks to Mike Kaganski )
2. tdf#124270 Editing: Err:522 on copying of rows with “Calc: threaded” enabled ( steps in comment 6 ) ( Thanks to Dennis Francis )
3. tdf#124708 CRASH: Selecting all and deleting ( Thanks to Muhammet Kara )
4. tdf#127921 Presenter View of Impress 6.3.x doesn’t remember slide after Slides and Close, as it used to, but returns to 1 during presentation ( Thanks to Samuel Mehrbrodt )
5. tdf#128538 Restart in safe mode: Open containig folder doesn’t work and Show user profile gets a error message ( Thanks to Stephan Bergmann )
6. tdf#128562 Pressing F5 (Navigation) in Calc crashes document, corrupts user profile, and makes Calc impossible to use ( Thanks to Noel Grandin )
7. tdf#128862 CRASH: Unable to open tables in HSQLDB odb-files with apostrophe ” ‘ ” character in table name ( Thanks to Julien Nabet )
8. tdf#44462 Provide a proper ‘File Association Manager’ for the windows version of Libreoffice ( Thanks to Mike Kaganski )
9. tdf#47490 CONFIGURATION: “Show overwrite warning when pasting data” setting is not honored when “Enter” is used to paste ( Thanks to Aditya )

List of crashes fixed

1. tdf#118526 CRASH: Notebookbar crashes in read mode ( Thanks to Jim Raykowski )
2. tdf#123851 Crash on start with KDE integration installed ( Thanks to Jan-Marek Glogowski )
3. tdf#124708 CRASH: Selecting all and deleting ( Thanks to Muhammet Kara )
4. tdf#128335 CRASH: cutting textboxes ( Thanks to Miklos Vajna )
5. tdf#128375 CRASH: Closing LibreOffice after cutting content from document ( Thanks to Michael Stahl )
6. tdf#128441 Crash in: mergedlo.dll (nvidia with device 0x2182 + Win10) ( Thanks to Julien Nabet )
7. tdf#128562 Pressing F5 (Navigation) in Calc crashes document, corrupts user profile, and makes Calc impossible to use ( Thanks to Noel Grandin )
8. tdf#128599 Crash when typing in the Authentication Required dialog ( Thanks to Caolán McNamara )
9. tdf#128603 CRASH: Cutting a textbox in a reopened document ( Thanks to Miklos Vajna )
10. tdf#128667 Crash when pasting text with line wrap ( Thanks to Caolán McNamara )
11. tdf#128736 CRASH: Moving content to 2 page and undoing ( Thanks to Miklos Vajna )
12. tdf#128737 CRASH: Importing a specific file ( Thanks to Michael Stahl )
13. tdf#128739 CRASH: working with fields ( Thanks to Michael Stahl )
14. tdf#128746 Opening table properties window causes crash in development build ( Thanks to Caolán McNamara )
15. tdf#128753 CRASH: Closing LibreOffice after cutting content from document ( Thanks to Julien Nabet )
16. tdf#128767 CRASH: Clicking on Export Directly to PDF (gen) ( Thanks to Caolán McNamara )
17. tdf#128788 Crash when trying to put autovalue on a field of a table ( Thanks to Caolán McNamara )
18. tdf#128802 customize toolbar with drag and drop causes crash ( Thanks to Caolán McNamara )
19. tdf#128862 CRASH: Unable to open tables in HSQLDB odb-files with apostrophe ” ‘ ” character in table name ( Thanks to Julien Nabet )
20. tdf#129025 CRASH: Closing LibreOffice while Options dialog is open ( gen ) ( Thanks to Caolán McNamara )

List of performance issues fixed

1. tdf#108642 FILEOPEN: document with a complex table structure takes double the time to open when the sidebar is enabled (gtk3) ( Thanks to Noel Grandin )
2. tdf#126043 Tools -> Customize has a nagging delay of 3 seconds on each opening ( Thanks to Caolán McNamara )
3. tdf#128812 LibreOffice – calc – specific xlsx document (almost) any operation (FILEOPEN, FORMATTING) takes about 1 min ( Thanks to Noel Grandin )

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

1. tdf#38199 Writer EDITING: Why when I press tab in read-only mode, then the document scrolls to top? ( Thanks to Jim Raykowski )
2. tdf#41205 PRINTING: clicking radio button “Pages” should select pane contents for page selection ( Thanks to Michael Weghorn )
3. tdf#42112 EMF+ Fileopen: Embedded grouped diagram from particular DOC still doesn’t preview arrows correctly (diagram opens fine if extracted from MSO) ( Thanks to Bartosz Kosiorek )
4. tdf#43021 Macros: FilePicker method setDisplayDirectory shows wrong folder with native dialog Win 7 (64-bit) ( Thanks to Jan-Marek Glogowski )
5. tdf#44462 Provide a proper ‘File Association Manager’ for the windows version of Libreoffice ( Thanks to Mike Kaganski )
6. tdf#47490 CONFIGURATION: “Show overwrite warning when pasting data” setting is not honored when “Enter” is used to paste ( Thanks to Aditya )
7. tdf#54204 Hyperlinks between documents not works if link contains anchor at the end ( Thanks to Tünde Tóth )
8. tdf#76586 FILEOPEN 2007 DOCX Column width of table within table not imported properly (OK if resaved in MSO) ( Thanks to László Németh )
9. tdf#84183 [Infobar] Wrong appearance of clicked close button ( Thanks to Samuel Mehrbrodt )
10. tdf#84929 EDITING: Clicking in the footer area brings focus/view to last cursor position on page ( Thanks to Justin Luth )
11. tdf#88922 Resizing a chart legend makes the chart’s body rezise on top of it ( Thanks to Balazs Varga )
12. tdf#94288 Entering chart mode doesnt show chart sidebar ( Thanks to Muhammet Kara )
13. tdf#95374 FILEOPEN DOCX Margin import error. LibreOffice imports with -1cm margin that should be 0cm ( Thanks to László Németh )

WORKSFORME bugs

106 bugs have been retested by 40 people.

Top 10 testers

1. Xisco Faulí ( 15 )
2. Timur ( 11 )
3. Buovjaga ( 9 )
4. Julien Nabet ( 8 )
5. eisa01 ( 7 )
6. Robert Großkopf ( 5 )
7. Heiko Tietze ( 5 )
8. Roman Kuznetsov ( 4 )
9. Dieter Praas ( 4 )
10. Aron Budea ( 3 )

DUPLICATED bugs

131 bugs have been duplicated by 29 people.

Top 10 testers

1. Xisco Faulí ( 29 )
2. Timur ( 15 )
3. V Stuart Foote ( 11 )
4. Alex Thurgood ( 8 )
5. Oliver Brinzing ( 8 )
6. NISZ LibreOffice Team ( 7 )
7. Roman Kuznetsov ( 5 )
8. libreoffice.bak ( 4 )
9. Heiko Tietze ( 4 )
10. Dieter Praas ( 4 )

Verified bug fixes

104 bugs have been verified by 20 people.

Top 10 Verifiers

1. Xisco Faulí ( 75 )
2. Timur ( 6 )
3. Dieter Praas ( 4 )
4. Buovjaga ( 2 )
5. BogdanB ( 2 )
6. Michael Weghorn ( 2 )
7. roland ( 2 )
8. raal ( 1 )
9. Patrick Jaap ( 1 )
10. Eike Rathke ( 1 )

Categorized Bugs

241 bugs have been categorized with a metabug by 32 people.

Top 10 Categorizers

1. Dieter Praas ( 51 )
2. Roman Kuznetsov ( 32 )
3. LibreOfficiant ( 29 )
4. NISZ LibreOffice Team ( 27 )
5. V Stuart Foote ( 19 )
6. sdc.blanco ( 11 )
7. Rizal Muttaqin ( 9 )
8. Xisco Faulí ( 7 )
9. Aron Budea ( 7 )
10. Luke ( 5 )

Regression Bugs

114 bugs have been set as regressions by 24 people.

Top 10

1. Xisco Faulí ( 52 )
2. NISZ LibreOffice Team ( 10 )
3. Alex Thurgood ( 8 )
4. Timur ( 6 )
5. Roman Kuznetsov ( 5 )
6. Oliver Brinzing ( 5 )
7. eisa01 ( 3 )
8. Jan-Marek Glogowski ( 2 )
9. Dieter Praas ( 2 )
10. Julien Nabet ( 2 )

Bisected Bugs

99 bugs have been bisected by 13 people.

Top 10 Bisecters

1. Xisco Faulí ( 66 )
2. NISZ LibreOffice Team ( 9 )
3. Aron Budea ( 6 )
4. raal ( 6 )
5. Oliver Brinzing ( 3 )
6. Roman Kuznetsov ( 2 )
7. writepaperforme2 ( 1 )
8. Gabor Kelemen ( 1 )
9. Buovjaga ( 1 )
10. Michael Weghorn ( 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!…

LibreOffice’s native file format is OpenDocument, a fully open and standardised format that’s great for sharing documents and long-term data storage. Of course, LibreOffice does its best to open files made by other office software as well, even if they’re stored in pseudo-“standards” with cryptic and obfuscated contents. Compatibility with PowerPoint PPT(X) presentations is therefore a challenge, but developers are working hard on improvements…

A few months ago, we announced an initiative to improve the support of PPT and PPTX files in LibreOffice. Lots of great work happened since then and the results are collected below!

Everyone is invited to participate in the PowerPoint support initiative, either in development or testing. If you are interested in joining, please send an email to ilmari.lauhakangas@libreoffice.org.

Import/export

Stephan Bergmann (Red Hat):

Speed up loading a PPT file with equation objects

---

Noel Grandin (Collabora):

Speed up loading a PPT file with equation objects

---

Miklos Vajna (Collabora):

Add PPTX import/export for semi-transparent shape text

PPTX import: don’t set shape fill from the style in case the background fill is already set

PPTX import: fixed duplication of math objects

---

Tamás Zolnai (Collabora):

PPTX export: don’t change shape’s background transparency

PPTX export: don’t lose the gradient background fill of a slide

---

Xisco Faulí (TDF):

PPTX import: display shapes with washout mode

PPTX export: handle image colour/graphics modes correctly

PPTX import: don’t lose text highlighting in table cells

PPTX export: save text highlighting

PPTX import: respect no fill colour for text

---

Gülşah Köse (Collabora):

PPTX import: implement z-rotation of 3D text transformation

PPTX export: preserve textbox rotation attribute

---

Tamás Bunth (Collabora):

PPTX import: custom date as custom XTextField

---

Mark Hung (PPT/X team):

PPTX import/export: handle complex text properly

PPTX import: reset font settings, if necessary

---

Luke Deller (PPT/X team):

PPTX import: Fix IsTransparent() for unloaded graphics

---

Housekeeping

Julien Nabet:

Save/restore locking properly in ImplSdPPTImport::Import

sd: prefix members of SdrPowerPointImport

cppcheck: fix 2 funcArgOrderDifferent

---

Various

Mike Kaganski (Collabora):

PPTX export: disable undo during save

Thanks to everyone for their great work!

Today is International Volunteer Day. All around the world, volunteers give their time and energy to help many different causes – including free and open source software projects like LibreOffice.

Indeed, LibreOffice wouldn’t be where it is today, without the incredibly valuable help of hundreds of volunteers in the last decade. So to everyone who has contributed to our project and community over the years, we at The Document Foundation want to say a big thank you! Your work has helped many millions of LibreOffice users around the world benefit from powerful, open and multilingual productivity tools.

And to celebrate, here are some photos of volunteers from events this year:

At the beginning of November, we started a new Month of LibreOffice, celebrating community contributions all across the project. So how many people got sticker packs throughout the month? Check it out…

Congratulations to everyone who’s on that page – and thanks so much for your contributions. It’s great to see such a passionate community helping to bring powerful, free and open source software to the world.

Now, how can you claim your sticker pack? Click the 302 above, and if you see your name (or username) on that page, get in touch! Email mike.saunders@documentfoundation.org with your name (or username) from the wiki page so that we can check, along with your postal address, and we’ll send you these:

(Note: your address will only be used to post the stickers, and will be deleted immediately afterwards.) If you contributed to the project in November but you’re not on the wiki page, please let us know so that we can add you!

But there is one more thing…

And we have an extra bonus: 10 contributors have also been selected at random to get an exclusive LibreOffice glass mug! It looks like this:

And here are the winners:

• Krunose
• LibreOfficiant
• @tetrapyloctomist@muenchen.social (Mastodon)
• Rhoslyn Prys
• Roman Kuznetsov
• Marco A.G.Pinto
• @balogic (Twitter)
• Gerhard Weydt
• Grantler
• Rizal Muttaqin

Congratulations to you all! We’ll be in touch with details for claiming your mugs…

So, this Month of LibreOffice has finished – but we plan to do another one in May next year, with another opportunity to get cool merchandise! And, of course, you can join our friendly community at any time and contribute back to the project. Thanks!

Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more!

• We got started with the Month of LibreOffice, November 2019. This is a campaign that we run every six months, crediting contributions all across the project. Everyone who helps the LibreOffice community during November can claim a sticker pack, and has a chance to win a cool glass mug. Today is the final day, so click the link to find out how to participate!

• The OpenDocument Format (ODF) is the native file format in LibreOffice, and is used by other applications too. On November 7, we welcomed the release to OASIS of TC Committee Draft of ODF Version 1.3 for ratification. At the end of the process, ODF Version 1.3 will be submitted to ISO to become a standard. The final approval is expected in late 2020 or early 2021.

• Also on the topic of ODF, we announced a new tender for consultancy on implementing ODF 1.3 conformance in LibreOffice. This task can be taken on by an individual or a company, so if you have some technical background in ODF and the LibreOffice source code, take a look.

• The LibreOffice Conference 2019 took place in Almeria, Spain in September, and we finished editing and uploading videos of presentations from the main room (auditorium). They’re all in the playlist, which you can browse below – click the button at the top to change to a different video:

• Meanwhile, we talked to Celia Palacios from the Mexican LibreOffice community, who has recently become a member of The Document Foundation. She tells us why she joined, and how she’s helping the LibreOffice project and community.

• Then the Turkish community gave a presentation about the Google Summer of Code (GSoC) in Ankara. There were around 40 attendees, all interested to hear how GSoC students had worked on new features and improvements in LibreOffice.

• In other news, we announced a new version of the LibreOffice Impress Remote for Android. This lets you interact with your slideshow presentation from your Android device – including slide previews, speaker notes, and more.

• Another community that was especially active this month was the Albanian LibreOffice community, who organised a localisation sprint and other events. We really appreciate their help – and our thoughts are with them, and the people of Albania, in the difficult times after the earthquake.

• Over in the documentation project, a team of contributors has worked on refreshing the LibreOffice “Frequently Asked Question” pages. Check out the graph below to see how many wiki edits were made over the last two years:

• And then we had even more community news! LibreOffice was present at two events in the Czech Republic, LinuxDays in Prague and OpenAlt in Brno. Thanks to Zdeněk, Petr and Stanislav for their great work!

• Over in Indonesia, Sokibi’s story tells us about advocacy of free software and LibreOffice at a local level. It’s wonderful to see people all around the world who are so passionate about open source and sharing knowledge!

• The new LibreOffice Macro Team posted a progress report, detailing bugs fixed, help update and code contributions. Great work, everyone!

• And finally, we had a local event update from Sofia, Bulgaria, where LibreOffice was present at OpenFest. Gabriele Ponzo describes his experiences there, and explains how other community members can get involved too.

Keep in touch – follow us on Twitter, Facebook and Mastodon. Like what we do? Support our community with a donation – or join us and help to make LibreOffice even better!

LibreOffice community members attend many events around the world to spread the word about the software, encourage people to get involved, and have fun! We’re really grateful for all their efforts. On November 2 and 3, the OpenFest 2019 took place in Sofia, Bulgaria, and Gabriele Ponzo was there. Here’s his report:

What was the event about?

Sofia’s OpenFest looks like probably the largest open source software and hardware festival in Bulgaria. There were plenty of people – more on Saturday than on Sunday.

There were three tracks, and a huge room for many workshops (four or five usually), which covered topics such as electronics skills improvement (eg soldering), or padlock cracking, or developing with Elasticsearch…

There was also an awesome kindergarten (with backlit sand projection game), a relaxation area and a speaker’s corner, to allow attendees pose more questions to speakers, after their lectures. The organisation of the event was great, I must say, which includes pre and post parties, lead by Yana Petrova.

Why did you go there?

The goal of my mission was to create a local LibreOffice community, and possibly increase the membership base of The Document Foundation, the non-profit entity behind the software, having this country better represented. I’ve seen many people that were interested – so we’ll see if they will become active in our community.

I also had a great opportunity to get in touch with a local technical school called TUES, which is a high school but really well connected with the university. We have now started an official dialogue, in order to try organising some kind of lecture or workshop there too.

My dream would be to have teachers giving students practice with our Easy Hacks and thus giving them the chance to get their hands on a real project’s source code, and possibly improve it. This would have a great added value, from my point of view, in IT lessons, giving the students satisfaction and many real chances for the future.

What did you do there?

I had the opportunity to share a booth with the wonderful guys from the openSUSE community. They were really kind and warm with me and helped in many ways, from coming to the airport to pick me, to talking about LibreOffice in Bulgarian to attendees of the booth, side-by-side with me who was doing in English.

A special thank you goes to Dimitar Zahariev who was so gentle and I’m really happy and honoured to have become friend of, as well as to Rozalina, Rositsa and Rumen.

At the end of the morning of the second day, I had my usual talk about our community and TDF membership. The hall wasn’t full, as in some other’s lectures, but I received a lot of questions at the end, which gave me a lot of hope, and I also talked to two interesting speakers during lunch, about LibreOffice and its ecosystem.

Are there any other events you’d like to attend?

I’ve been told by Yana that they’ll probably have another event during next summer. Either that one and/or the next edition of this one; I’d like to come, but this time with someone else from our community, in order to have our own booth, with plenty of gadgets and marketing materials.

This time, in fact, we couldn’t send anything there and Dimitar was so kind to print flyers for us. Then the organisation team have let us share a big LCD screen with the Kiwi TCMS guys, to show some videos. A thank you goes also to those last ones (Alex, Anton and Vasilena), who were so kind and generous to let use the screen one day per each booth. I’ve been talking to them too, in order to see if the two projects may collaborate.

The event really deserves our presence, from my point of view, since there was a lot of people attending, and the organisation was really professional, starting with the conference management software developed by them – we should ask them if we could try it for our conferences ;-) And also with the audio and video service (like at FOSDEM!).

How can community members get involved and help out at other events?

When we have a booth, especially if it’s not shared, more people are necessary, to cover whole days. This gives everyone the chance to do other things – to have the possibility to follow some talks, do some PR, and get some rest now and then. But the best would be to have people who’re not shy, possibly used to speaking in public, and used to approaching unknown people – in order to interact with them and explain our project.

Another way to involve attendees is to have some kind of game or challenge, giving some gadget as a prize. This is something I’ve seen at most of the booths at this conference.

In conclusion, I really enjoyed this event and I hope to come back and increase even more our presence and our brand knowledge, hoping to find always more contributors to our projects, who could also be the numerous IT companies present in Bulgaria.

So, the branch implementing VCL drawing based on the  Skia graphics library has been merged in.
All(?) the necessary info about how to enable it etc. are in this mail, but there are things that better fit a blog post than a mail, and in this case that's going to be a table and a picture showing how well it may perform. Note that these results are from running visualbackendtest, which is not really a benchmark, so these numbers should be taken with a grain of salt. It's just a test that draws a gradient, several big polygons (each circle is actually 720 lines) and short text.
And LibreOffice of course does many more things than just paint on the screen. And it's not just about performance of drawing (some of these e.g. do not double-buffer, which makes things like alpha blending complicated and slow). And for some of these we could discuss the complicated reasons for why the numbers are what they are. But still, some of the numbers are interesting:

Render method	FPS
Linux gen (X11)	86
Linux gtk3	70-90
Linux OpenGL	45
Linux Skia Vulkan (GPU)	65-90
Linux Skia raster (CPU)	5
Windows GDI	64
Windows OpenGL	40-60
Windows Skia Vulkan (GPU)	175-185
Windows Skia raster (CPU)	75-85

• Sync call with Aron, Kendy, Javier; poked at financials, poked at patch merging, testing, merged a nice online patch from 1&1 to add a REST monitoring API.
• Bit of quartet editing & re-arrangement in Musescore - which is a great tool.

• All Saints, Simon & Norma back for lunch; played with the babes, quartet bits, ferried kids around the place.

• Out for a run with J. Put up some Ikea storage units, Mentalistsed, bit of hacking & mail.

When we make C++17 a requirement for LibreOffice at the end of 2018 the version of coverity provided by scan.coverity.com no longer worked for us. In July 2019 a newer version of the coverity tooling was available which supported C++17 and analysis resumed.

Prior to losing coverity support we had a defect density (i.e. defects per 1,000 line of code) of 0, on its return this had inflated to 0.06 due to both new defects introduced during the down period and old defects newly detected due to additional checks introduced in the new version.

Today we're finally back to 0

• Mail chew; admin, calls, some patch review & merging. J.N.M.E. out to Ikea for a shopping binge.

• Mail chew, debugging, moved flights, demo preparation. Presented to the team, lots of positive feedback. More code cleanup, train, flight, drive home - lovely to see the family again.

Sourcetrail is very useful when you try to study/navigate large C++ codebases like @firebirdsql / @LibreOffice Sourcetrail is now free and open-source! 🥳The source code is available on GitHub: https://t.co/BXX1rRBCtLIf this catches you by surprise, read our blog post on why we made this change and how we will continue: https://t.co/U5FffFZwvW pic.twitter.com/0AxH98RSVg— Sourcetrail (@

On November 13 more than 120 students in Ankara Hacettepe University’s Beytepe Campus joined the first session of the LibreOffice Developer Bootcamp, a course for students with interest in C++. There is a session every week, until the end of the semester.
 

 

 

The announcement of the course was received with enthusiasm at Twitter!

 

The first sessions gave a broad introduction on the course, Free Software & Open Source, LibreOffice & Collabora and requirements for the course. And after that, really into development: installations & setup, different IDEs, git, gcc, clang and the basics of C++.

 

 

 

The instructor of this course, Muhammet Kara, recently also held a talk about Google Summer of Code. Starting from that point, then doing a project for LibreOffice, he grew to a developer working for Collabora.

People at Hacettepe University, Ankara, are exited by story of @muhamm3tkara starting with joining #GSOC then volunteer for @libreoffice and now developer for @CollaboraOffice, major contributor in the #LibreOffice-ecosystem
Thanks for sharing & helping others, Muhammet https://t.co/m10WCfPhx8

— Collabora Office (@CollaboraOffice) November 10, 2019

After the first session, Muhammet tells “There were many enthusiastic participants, even some from outside the town. I’m sure that at the end of the course, there will be many students with pretty good skills in C++ and LibreOffice development.”

This course in Ankara can be organized thanks to of course support of the Hacettepe University for the use of the amphitheater, Hacettepe ACM Student Chapter for the local/logistics organization, Collabora for sponsoring, and the enthusiasm and knowledge that Collabora developer Muhammet Kara is putting into it.

The weekly sessions will be given until the end of the semester, January next year. So if you’re motivated and love open source.. you may still be able to join !

The post Collabora sponsoring LibreOffice Developer Bootcamp in Ankara appeared first on Collabora Productivity.

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

LibreOffice 6.4 will be released as final at the beginning of February, 2020 ( Check the Release Plan ) being LibreOffice 6.4 Beta1 the second pre-release since the development of version 6.4 started in the beginning of June, 2019. Since then, 5677 commits have been submitted to the code repository and more than 850 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.4 Beta1 can be downloaded from here for Linux, MacOS and Windows, and it can be installed alongside the standard version.

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 ).

For help, you can contact the QA Team directly in the QA IRC channel or via Telegram.

Happy testing!!

…

For a long time now I have noticed that OutputDevice is a class that is tightly coupled to drawing primitives such a pixels, lines, rectangles, etc. To draw new primitives in OutputDevice, you need to change the interface by adding another function, often you need to add new private functions, etc.

I have never been entirely comfortable with this - I believe that we shouldn't vary the OutputDevice class, but instead the functionality should be implemented in a command pattern. In a command pattern, you use an object to encapsulate the functionality used to perform an action. What this means is that OutputDevice no longer needs to know how to directly draw a line, pixel, rectangle or any other primitive we throw at it - this is all done in the command object. I call these OutputDevice Drawables. It turns out, I find it easier to test a command object.

In fact, the more I rewrote code to use the command pattern, the more I found that we were using a particular sequence of actions in most of our drawing functions:

1. Add action to GDI metafile 
2. Can we draw? No - exit 
3. Initialize the clipping region if possible 
4. Initialize the object's color 
5. Initialize the object's fill color 
6. Acquire the SalGraphics instance 
7. Do the actual drawing! 
8. Paint alpha virtual device

When I realised this, I decided to follow the principle of encapsulating what was varying - point 7 - the actual drawing. Everything else was the same - at least so I initially thought. It turns out this is not the case all the time, so I allowed two things - a function that can be overridden that tells the Drawable that the step should be bypassed, and in the case where we need to through all this scaffolding out the window a way of bypassing it entirely. However, this is an example of a template method pattern.

You can see the base work for this in a gerrit patch I submitted today. To use the actually command pattern is very easy: if there is not an existing function like DrawPixel in OutputDevice, you just have to invoke the command object via OutputDevice::Draw(Drawable* pDrawable). An example can be found in the unit test.

To implement a new command, you just derive from Drawable - the simplest Drawable class you can define only needs a constructor with the parameters you would normally send to a Draw command in OutputDevice (e.g. PixelDrawable only needs a Point sent to the constructor), and you implement the actually drawing in DrawCommand(OutputDevice* pRenderContext).

A few things I found helped me when I created Drawables - I quite like passing parameters to functions, I'm not a huge fan of a lot of state in the class. Drawables work because they essentially work by calling the Execute function, this handles all the basic drawing for you on the state you set in the constructor. I have found in some patches that I have on github that the functionality is somewhat complex, for this I have extract function to simplify test and readability of the code (an example of this is GradientDrawable - see GradientDrawable.cxx and GradientDrawableHelper.cxx).

It's been almost half a year since I mentioned how precompiled headers do (not) improve C++ compile times. Quite a long time, filled with doing other things, life, occassionally working on getting my patch production-ready and, last but definitely not least, abandoning that patch and starting from scratch again.
It turns out, the problems I mentioned last time had already been more or less solved in Clang. But only for C++ modules, not for precompiled headers. *sigh* I had really mixed feelings when I finally realized that. First of all, not knowing Clang internals that well, it took me quite a long time to get to this point figuring it all out, probably longer than it could have. Second, I've been using C++ modules when building Clang itself and while it's usable, I don't consider it ready (for example, sometimes it actually makes the build slower), not to mention that it's non-trivial to setup, not standardized yet and other compilers (AFAIK) do not yet support C++ modules. And finally, WTH has nobody else yet noticed and done the work for precompiled headers too? After all the trouble with finding out how the relevant Clang parts work, the necessary patches mostly border on being trivial. Which, on the other hand, is at least the good news.
And so I'm switching for LibreOffice building to my patched build of Clang. For the motivation, maybe let's start with an updated picture from the last time:
This is again column2.cxx, a larger C++ file from Calc. The first row is again compilation without any PCH involved. The second row is unpatched Clang with --enable-pch=full, showing again that way too large PCHs do not really pay off (here it does, because the source file is large, but for small ones such as bcaslots.cxx shown last time it makes things slower). In case you notice the orange 'DebugType' in the third row that looks like it should be in the second row too, it should be there, but that's one of these patches of mine that the openSUSE package does not have.
The third row is with one patch that does the PerformPendingInstantiations phase also already while building the PCH. The patch is pretty much a one-liner when not counting handling fallout from some Clang tests failing because of stuff getting slightly reordered because of this. Even by now I still don't understand why PCH generation had to delay this until every single compilation using the PCH. The commit introducing this had a commit message that didn't make much sense to me, the test it added works perfectly fine now. Presumably it's been fixed by the C++ modules work. Well, who cares, it apparently works.
The last row adds also Clang options -fmodules-codegen -fmodules-debuginfo. They do pretty much what I was trying to achieve with my original patch, they just approach the problem from a different side (and they also do not have the technical problems that made me abandon my approach ...). They normally work only for C++ modules, so that needed another patch, plus a patch fixing some problems. Since this makes Clang emit all kinds of stuff from the PCH into one specific object file in the hopes that all the compilations using the PCH will need that too but will be able to reuse the shared code instead, LibreOffice now also needs to link with --gc-sections, which throws away all the possibly problematic parts where Clang guessed wrong. But hey, it works. Even with ccache and Icecream (if you have the latest Icecream, that is, and don't mind that it "implements" PCHs for remote compilations by simply throwing the PCH away ... it still pays off).
So, that it's for a single compilation. How much does it help with building in practice? Time for more pretty colorful pictures:

This is a debug LO build on my 4-core (8 HT) Ryzen laptop, Library_sm is relatively small (36 source files), Library_scfilt is larger (154 source files). Plain 'Clang' means unpatched Clang(v9), 'Clang+' is with the PerformPendingInstantiations patch (i.e. the third row above), 'Clang++' is both patches (i.e. the fourth row above). The setting is either --enable-pch=base for including only system and base LO headers in the PCH, or --enable-pch=full for including everything that makes sense. It clearly shows that using large PCHs with GCC or unpatched Clang just doesn't make sense.
Note that GCC(v9) and MSVC(v2017) are there more as a reference than a fair comparison. MSVC runs on a different OS and the build may be possibly slightly handicaped by some things taking longer in Cygwin/Windows. GCC comes from its openSUSE package, which AFAICT is built without LTO (unlike the Clang package, where it makes a noticeable difference).
And in case the graphs don't seem impressive enough, here's one for Library_sc, which with its 598 source files is too big for me to bother measuring it in all cases. This is the difference PCHs can make. That's 11:37 to 4:34, almost down to one third:
As for building entire LO from scratch, it can be like in the picture below (or even better). The effect there is smaller, because the build consists of other things than just building libraries, and some of the code built doesn't use PCHs. And it's even smaller than it could be, because I used --enable-pch=base, as that's what I've been using up to now (although now I'll switch to a higher level). That's about 1h42m without PCHs to 1h14m with unpatched Clang (27% percent saved), and 1h06m with patches (and the 8minutes difference is still 11% of the unpatched time). Not bad, given that this is the entire LO build. Those 6 minutes for ccache are there to show the maximum possible improvement (or rather nowhere near possible, since the compiler normally still has to do the work of actually compiling the code somehow).
In case you'd want to use this too, that's not up to me now. The patches are now sitting and waiting in the LLVM Phabricator. Hopefully somebody there still cares about PCHs too.

Since forever, Basic in OpenOffice.org had a bug: it didn’t properly check closing parentheses in expressions like

FirstUpper = UCase( Left( sString, 1 ) + LCase( Mid( sString, 2 ) )

(example taken from this AskLibO question). Note the mismatch between opening and closing parentheses: four opening, and only three closing. The author missed one to close UCase function after Left( sString, 1 ), and any compiler would naturally point out to this common mistake – any but StarBasic in OOo and derivatives.

What StarBasic did was auto-closing the expression in the end when compiling. It would only complain if the result of such auto-closing would be ill-formed; sometimes (as in the example above), the result would be syntactically correct – but not necessarily semantically correct: the example above compiled with StarBasic did not what author expected (a text with first character capitalized, and the rest of the text in lowercase), but returned text in all caps instead. For some similar cases, such errors could be not easy to find in the absence of compiler check, especially in a large project.

This has been reported to LibreOffice bug tracker as tdf#80731 back in 2014; and it was addressed in 5.4 development cycle, with the fix backported into 5.3.1. A nice and correct fix, isn’t it?

Well, not actually. It turned out, that over the years, the amount of existing and actually used legacy code having the error has become so big, that it was unrealistic to make sure that all of it is checked and fixed. Of course, some errors were found in the code bundled with LibreOffice itself – and naturally, it was fixed. Some third-party extensions – quite a number of them – also happened to have it; and all authors who could be contacted, had released updated releases with the mistake corrected; thank you! But it wasn’t possible to test any extension out there; and besides publicly available and supported extensions, there were also unsupported (but still used, and useful) ones; and private ones (used by those who developed/paid for their development); and also uncountable macros outside of any extensions, and all of them having the error, that happily worked before, suddenly stopped working for their users … so after some time, the fix was reverted both from 5.3.3, and from still developing 5.4 (tdf#106529). By the way, I was enjoying reading “AltSearch extension put a bugfix release 1.4.2 to work around this bug” there, as if pointing to syntax error was actually a LibreOffice’s bug, not a mistake in the extension’s code.

So LibreOffice kept silently allowing the wrong syntax ever after 5.3.3, until now. Today I have reinstated the original fix by Pierre Lepage from 5.4, with one modification: the check is only active when compiling the code from within Basic IDE. What does it mean? It means, that for anyone writing a new code in the Basic IDE, the syntax error will be properly found and shown. When one opens an existing module in the IDE, and makes a modification (which would of course trigger recompilation), the existing errors in the same module (even in different routines) would be found, too. But if the code is compiled not from the IDE (as when a macro is executed from an event handler; or when an extension runs its code), the old permissive handling is kept, and the code with errors will continue working as before.

I consider this an acceptable compromise, which would both allow existing users of legacy code to keep using their code, and still prevent creation of new buggy code (and also help gradually cleaning up the existing errors in supported Basic programs).

The change will appear in coming version 6.4. It’s still to be seen if this change will survive, or will it also uncover a different can of worms, and be eventually reverted, as its predecessor