Welcome to The Document Foundation Planet

This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.

To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.


Thursday
23 May, 2019


face

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


Monday
20 May, 2019


face

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

LibreOffice 6.3 will be released as final in mid August ( Check the Release Plan ) being LibreOffice 6.3 Alpha1 the first pre-release since the development of version 6.3 started in mid November, 2018. Since then, 6390 commits have been submitted to the code repository and more than 1050 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 Alpha1 is already available for downloading here, for Linux, MacOS and Windows.

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

Banner


Wednesday
15 May, 2019


face
https://lh3.googleusercontent.com/Jw_BHWWDubfGASjfFszFu6q9VRXaELjjLun974YCt7pQv3P-WIKqkISu5GHwTNndCHi8jGqv_FvYTZFXdWfxASIzXbgw0Et-7rAQZ3LzxA5Ntxx0GTxRH3y4m3hOYVLMKAyXtCQECQ=w640
Figure 1. Chart in drawingML group shape in DOCX, imported into Writer

Years ago I posted about a large rework to where Collabora helped a customer to make Writer read the drawingML markup for DOCX shapes. You can read the various benefits of this switch in that article — but similar to other large reworks, this also broke some previously working corner-cases, where test coverage lacked.

One of these is charts in group shapes. This needs explicit handling, as Writer normally handles charts as TextEmbeddedObjects, while code that imports charts from OOXML is not specific to Writer. The fix just tells the generic drawingML import to use a Writer-specific service name for the charts.

This is available in LibreOffice master (towards 6.3).


Tuesday
14 May, 2019


face

Brussels in the night

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.

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


Tuesday
07 May, 2019


face

General Activities

  1. LibreOffice 6.2.3 was released on April 18, 2019
  2. László Németh (NISZ) fixed the Autocorrect capitalization of the English i’m
  3. László Németh (NISZ) continues his work with pasting table from Calc to table in Writer. Now Calc table with hidden rows pastes in Writer table without these rows
  4. Grzegorz Araminowicz (Collabora) improved SmartArt interoperability
  5. Stephan Bergmann added support for JRE installations with unknown java vendor
  6. Andreas Kainz ended update Sifr icon theme. Some review and feedback are welcome
  7. Heiko Tietze implemented a nice Tip-of-the-Day dialog that is prompted when LibreOffice is launched.
  8. Miklos Vajna (Collabora) has fixed many OpenGL bugs
  9. Mike Kaganski (Collabora) has fixed some Pivot table interoperability problems when import/export them into XLSX format
  10. Using the new Windows bibisect repo for 4.3 created by Cloph, Buovjaga was able to solve many old regression mysteries
  11. Gábor Kelemen (NISZ) closed many reports as duplicates, Chart issues in particular
  12. Noel Grandin (Collabora) improved different opening/saving performance hotspots for some documents in Writer, like documents with lots of bookmarks. Buovjaga decided to profile dozens of existing file saving issues just in case.
  13. Noel Grandin (Collabora) improved the opening time of different documents in Calc.
  14. Xisco Fauli found many crashes ( many of which are already fixed ) using UITests for mass testing
  15. Telesto and Buovjaga wrote instructions for Windows performance tracing using UiforETW
  16. New contributor Tasanim Mulla continued to do significant contributions in the area of confirming bugs
  17. Miklos Vajna (Collabora) keeps working on improving btLr text direction
  18. Tomaž Vajngerl (Collabora) has fixed some bugs affecting macOS
  19. Tamás Zolnai (Collabora) implemented Interoperable text-based form controls
  20. Muhammet Kara (Collabora) disabled the Firefox theme search
  21. Michael Stahl (CIB) added Undo for ToX Update

Reported Bugs

580 bugs, 63 of which are enhancements, have been reported by 339 people.

Top 10 Reporters

  1. Xisco Faulí ( 31 )
  2. andreas_k ( 31 )
  3. Mike Kaganski ( 19 )
  4. NISZ LibreOffice Team ( 16 )
  5. Andreas Gruhler ( 15 )
  6. Roman Kuznetsov ( 9 )
  7. Buovjaga ( 9 )
  8. Aron Budea ( 8 )
  9. Heiko Tietze ( 8 )
  10. Patrick Jaap ( 7 )

Triaged Bugs

585 bugs have been triaged by 87 people.

Top 10 Triagers

  1. Xisco Faulí ( 130 )
  2. Heiko Tietze ( 39 )
  3. Dieter Praas ( 31 )
  4. Buovjaga ( 30 )
  5. V Stuart Foote ( 25 )
  6. raal ( 25 )
  7. Roman Kuznetsov ( 24 )
  8. Oliver Brinzing ( 24 )
  9. Aron Budea ( 23 )
  10. mulla.tasanim ( 22 )

Resolution of Resolved bugs

520 bugs have been set to RESOLVED.

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

Fixed Bugs

231 bugs have been fixed by 42 people.

Top 10 Fixers

  1. Caolán McNamara ( 31 )
  2. Mike Kaganski ( 17 )
  3. andreas kainz ( 14 )
  4. Noel Grandin ( 14 )
  5. Miklos Vajna ( 13 )
  6. Tor Lillqvist ( 10 )
  7. Tomaž Vajngerl ( 8 )
  8. Michael Stahl ( 8 )
  9. László Németh ( 5 )
  10. Balazs Varga ( 5 )

List of critical bugs fixed

  1. tdf#109376 Crash after accepting all changes from compared documents ( Thanks to Michael Stahl )
  2. tdf#120754 Crashes on UNDO ( Thanks to Caolán McNamara )
  3. tdf#123502 crash: use of “com.sun.star.ui.dialogs.FolderPicker” crashes ( Thanks to Mike Kaganski )
  4. tdf#123747 digital

Saturday
04 May, 2019


face

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


Tuesday
30 April, 2019


face

On vecation I ordinary have the best ideas. So this time I made an single line contextual toolbar for writer.

ContextualSingle.PNG

It’s how the single line toolbar should look like. One toolbar which is fully contextual. As one toolbar didn’t have that much space, you have the menubar for all available commands in LibreOffice.

It’s the most compact LibreOffice UI done on my smal Laptop screen (1366 x 768 px). But Contextual single work not only on small screens it’s flexible and suites all screen sizes.

contexts.png

Context Standard, Table, Image, Shape

If you’d like to test contextual single download the daily master build, enable experimental features (Menubar -> Tools -> Configure -> Advanced -> Enable experimental features) and change in Writer Menubar -> View -> User Interface -> Contextual Single.

To test download the daily build
https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current

I broke the linux builds but now daily build for linux is available to check out the context single layout

https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86@87-TDF/current


Monday
29 April, 2019


face

The next release for LibreOffice will have a small but handy improvement for every macro developer, either experienced or beginner.

Hover the mouse on BASIC and Python code in the new Help pages and a tip shows that when you click your mouse, the code exerpt is copied in the system clipboard. You can paste in the BASIC IDE (Integrated Development environment) or any other text application in your system.



With this little feature, you save time of typing the exerpt to test in your IDE or document. Another alternative was to use a collateral file, however, collateral files with embedded macros is likely to trigger security warnings in most LibreOffice installations. Just copying the fragment is easier.

Happy Basic macro programming!
Happy Python macro programming!

face

Recently we at Collabora Productivity have made some substantial improvements to XLSX interoperability related to pivot tables, fixing many issues existed in Calc.

Personally I have committed these patches:

These changes allow our customers, and the whole LibreOffice user community, to enjoy better interoperability when using XLSX format. They will be available in LibreOffice version 6.3 later this summer; and they are immediately available for our customers in this week’s Collabora Office 6.0 update 28.

Thanks to our valuable customers who make these improvements possible funding the work!


Thursday
25 April, 2019


face

Great Icon bugs get fixed!

LibreOffice do organize the bugs into [META] bugs, which is great cause when you link the bug to different [META] bugs you can organize bugfixing over different groups. I care about BUG 106228 which is the Icon meta bug and as you can see most of the icon bugs need developer work. Everything I could fix myself is nearly done.

There are two bigger tasks, but with great effort open

1. svg support for icons bug 124940

All main icon themes are available in svg, but the svg2png libreoffice renderer give bad quality, so we have to ship the png icons. If we could use the svg icons instead of the png, it mean less work for the designers and the posibility to have color scheme support for icons. 100% dark icon theme support and full color support. What a great improvement.

2. language support bug bug 124956

We have colibre, elementary, breeze, sifr, tango icon theme therefore the design group did the icons, some icons like bold, italic, strickout, underline, overline, … have letters which work fine for english users but had to be drawen for other languages. But to know which letter should be used we need the translation team so translation team please submit an bug report for each language and add at depends on 124956, than we will do the icon work.

Result

Colibre, elementary, sifr, breeze will be in an good shape for the 6.3 release, but to fix the last bugs, we need developers, translation team, documentation team, … everybody in one team.


Thursday
18 April, 2019


face

The LibreOffice guidelines say that you should show icons on the most important items https://wiki.documentfoundation.org/Design/MenuBar

Screenshot_20190418_183703.png

Now the menubar show only the most important items so the user didn’t flash with icons, the user get an better overview of the menubars.

happy hacking.


face

Xubuntu 19.04: The Exhaustive Update #Xubuntu #Xfce #DiscoDingo https://bluesabre.org/2019/04/18/xubuntu-19-04-the-exhaustive-update/


Monday
15 April, 2019


face

I already wrote about the btLr text direction in the context of Writer table cells as a result of a Collabora hack week. This is meant to be an update to present what happened in the past 2 months. Here is a video showing the results:

Figure 1. Before / after screen recording for the below mentioned changes

I fixed the following problems since the last blog post on this topic:

All this is available in LibreOffice master (towards 6.3), so you can try it out right now, if interested.


Monday
08 April, 2019


face

Every powerfull text editor like, kate, sublime, notepad++, VS Code, … has it the menubar. Now even better in LibreOffice.

MenubarUpdates

Items with subgroups were arranged at the end of groups , so it’s faster to read the menubar and the groups are between 3-4 items. Tiny changes with big effort.

If you like my work, become a downloads_wordmark_white_on_coral2x.jpg


face

All items in the menubar have now an icon. Some items are missing tdf#124200 but in general all commands will show an icon in the menubar.

Icons Everywhere

For 6.3 all supported icon themes will have the new icons. Now you can check them out in Sifr (which is complete new for 6.3 release).

If you like my work, become a downloads_wordmark_white_on_coral2x.jpg


Thursday
04 April, 2019


face

General Activities

  1. Libreoffice 6.2.1 and LibreOffice 6.2.2 were released
  2. Heiko and Roman Kuznetsov killed the more controls toolbar
  3. Roman Kuznetsov continues to sort the bugs by META (total about 2000 bugs for last 4 month)
  4. Dennis Francis (Collabora) added new Fourier analysis tool to Data→Statistics
  5. Andras Timar (Collabora) puts in order the info about licenses
  6. Andreas Kainz made huge Sifr icon theme update
  7. Jan-Marek Glogowski fixed some Qt5 bugs
  8. Several students tried to fix some Easy Hacks before GsoC in LibreOffice starts
  9. Katarina Behrens (CIB) has fixed many KDE5/Qt bugs
  10. The total number of open KDE-related reports dropped to under 50
  11. Luboš Luňák (Collabora) and Miklos Vajna (Collabora) have fixed some OpenGL bugs
  12. Laurent Alonso made many changes in libetonyek library (parser for the file format of Apple iWork documents)
  13. Roadmap for personal growth in QA was created
  14. Jens Carl made nearly 70 commits related to the Java tests to C++ conversion effort
  15. Noel Grandin (Collabora) discovered that some performance issues involving large tables had been fixed and then proceeded to optimise the code further. He also fixed some other performance issues during the month
  16. Miklos Vajna (Collabora) continues improving smartart support
  17. Saurav Chirania wrote a nice post about things to know if you are a new LibreOffice contributor
  18. Eike Rathke (Ret Hat) and Dennis Francis (Collabora) fixed a bunch a formula recalculation problems

Reported Bugs

680 bugs, 69 of which are enhancements, have been reported by 417 people.

Top 10 Reporters

  1. Nicolas Christener ( 38 )
  2. NISZ LibreOffice Team ( 22 )
  3. Mike Kaganski ( 16 )
  4. Telesto ( 16 )
  5. Roman Kuznetsov ( 9 )
  6. Samuel Mehrbrodt (CIB) ( 9 )
  7. Aron Budea ( 8 )
  8. Olivier Hallot ( 8 )
  9. Tor Lillqvist ( 7 )
  10. laurent.terrosi ( 7 )

Triaged Bugs

687 bugs have been triaged by 93 people.

Top 10 Triagers

  1. Xisco Faulí ( 165 )
  2. Oliver Brinzing ( 46 )
  3. Alex Thurgood ( 44 )
  4. Dieter Praas ( 40 )
  5. Aron Budea ( 35 )
  6. raal ( 29 )
  7. Andras Timar ( 29 )
  8. V Stuart Foote ( 26 )
  9. Julien Nabet ( 22 )
  10. Roman Kuznetsov ( 21 )

Fixed Bugs

201 bugs have been fixed by 51 people.

Top 10 Fixers

  1. Caolán McNamara ( 24 )
  2. Miklos Vajna ( 9 )
  3. Tor Lillqvist ( 9 )
  4. Michael Stahl ( 8 )
  5. László Németh ( 6 )
  6. Luboš Luňák ( 6 )
  7. Katarina Behrens ( 6 )
  8. Julien Nabet ( 6 )
  9. Noel Grandin ( 5 )
  10. Mike Kaganski ( 5 )

List of critical bugs fixed

  1. tdf#121439 PRINTING Crash when calling a print configuration dialog if selected cell range while several print areas are defined across multiple sheets ( Thanks to Luboš Luňák )
  2. tdf#121949 Crash in: libsclo.so Copy block of cells to clipboard with focus on non-selected cell ( Thanks to Luboš Luňák )
  3. tdf#123446 Writer crashes after undoing + redoing ToC insertion in middle of word ( Thanks to Michael Stahl )
  4. tdf#123479 Crash in: ScFormulaResult::GetMatrixFormulaCellToken() ( Thanks to Luboš Luňák )
  5. tdf#124112 Insert drawing object in chart crashes LibreOffice ( Thanks to Noel Grandin )

List of crashes fixed

  1. tdf#122543 Crash after device was put into “stand by” mode ( Thanks to Tor Lillqvist )
  2. tdf#122544 Crash when tunneled dialog is open and document is closed ( Thanks to Tor

Wednesday
03 April, 2019


face

For the next release LibreOffice Sifr icon theme get an update. Therefore 2.500 icons were drawn in inkscape so that Sifr is also available as svg theme.

Next step would be review the theme and give feedback.

If you like my work, become a downloads_wordmark_white_on_coral2x.jpg


Wednesday
27 March, 2019


face

Recently I implemented FOURIER() formula for LibreOffice Calc that computes Discrete Fourier Transform [DFT] of a real/complex data sequence. Computation is done using a couple of Fast Fourier Transform algorithms (all implemented from scratch). I’d like to thank Collabora Productivity for a fully funded hack week and lots of encouragement that enabled me to work on this feature.

The syntax of the formula is :

FOURIER(Array, GroupedByColumns, Inverse, Polar, MinimumMagnitude)

First and second arguments : First argument is the data array range. There are some restrictions on its shape. If the array is grouped by columns(rows), you need to indicate that by setting the second argument GroupedByColumns = TRUE(FALSE). In case of grouped by columns(rows) the “Array” can contain 1 or 2 columns(rows), where the first column(row) should contain the real part of the input sequence and second column(row) if present should contain the imaginary part of the input sequence. If there is only 1 column(row), the input sequence is assumed to be purely real. There is no restriction on the length of the input sequence. For example the length need not be an exact power of 2 like MS Excel’s Fourier analysis tool requires. The DFT computed by FOURIER formula is exact for the given length of the input sequence meaning it does not pad zeroes to the end of the input sequence to make the length an even power of 2.

The third argument “Inverse” is a boolean flag to indicate whether an inverse DFT needs to be computed. This argument is optional and the default value is FALSE.

The fourth argument “Polar” is a boolean flag to indicate whether the final output needs to be in polar coordinates. This argument is optional and the default value is FALSE.

The fifth argument “MinimumMagnitude” is a numeric argument and is used only if Polar=TRUE. All output components(frequency components if Inverse=FALSE) with magnitude less than MinimumMagnitude will be suppressed by a zero magnitude-phase entry. This is very useful when looking at the magnitude-phase spectrum of a signal (especially when its spectrum is sparse) because there is always some very tiny amount of rounding error when doing FFT algorithms and results in incorrect non-zero phase for some non-existent frequencies. By providing a suitable value to this parameter, these non-existent frequency components can be suppressed. The default value of this parameter is 0.0, so no suppression is done by default.

The result of this formula consists of two columns – first column contains the real parts (or the magnitudes if Polar=TRUE) and second column contains the imaginary parts (or the phases if Polar=TRUE).

Below is a screenshot of a sample usage of FOURIER() formula.

fourier-FM-trimmed

The data x[n] column was generated by the formula “=10*COS(2*PI()*COS(2*PI()*A2:A257/128))” (a typical frequency modulation example). Here a Phase-Magnitude spectrum is computed using FOURIER formula

=FOURIER(B2:B257,1,0,1, 1E-10)

Note that the Polar


Friday
22 March, 2019


face

I recently dived into the SmartArt support of LibreOffice, which is the component responsible for displaying complex diagrams from PPTX. I focus on the case when only the document model and the layout constraints are given, not a pre-rendered result.

First, thanks to our partner SUSE for working with Collabora to make this possible.

Organization Chart, Cycle Matrix and Picture Strip

In this post I would like to present the progress done earlier this year regarding the above mentioned diagram types — these are used in many documents.

The improvement (as always) come in small incremental steps:

  • Organization Chart is the most complex type I dealt with so far. I fixed several issues (font color, vertical ordering, multiple paragraphs in a data node, size of layout nodes, better support for hierBranch conditions, the type of connector shapes). This allows giving readable result for diagrams which are more complex than the simple 3-node one presented in the previous post.

  • Cycle Matrix: there were missing child nodes here, the composite algorithm needed improved handling of position / size from constraints and the ordering / fill / line properties of actual content also needed fixing.

  • Picture Strip: the biggest problem here was the lack of pictures, but also the existing snake algorithm needed improvements (size, positioning, spacing and margins of the child shapes were not great).

With all these fixed, we reach a much better state for the mentioned diagram types.

Results so far

The SmartArt test documents from sd/qa/unit/data/pptx/ is what I used for testing this work.

Here is how the baseline, the current and the reference rendering of Organization Chart looks like:

smartart-org-chart.pptx, baseline

smartart-org-chart.pptx, current

smartart-org-chart.pptx, reference

And here is how the baseline, the current and the reference rendering of Cycle Matrix looks like:

smartart-cycle-matrix.pptx, baseline

smartart-cycle-matrix.pptx, current

smartart-cycle-matrix.pptx, reference

And finally here is how the baseline, the current and the reference rendering of Picture Strip looks like:

smartart-picture-strip.pptx, baseline

smartart-picture-strip.pptx, current

smartart-picture-strip.pptx, reference

This is not not perfect yet, but it’s clearly a large improvement, all text is now readable from the diagrams and pictures are no longer missing!

All this is available in master (towards LibreOffice 6.3), so you can grab a daily build and try it out right now. :-)


Thursday
21 March, 2019


face
When I began contributing code to LibreOffice, I faced some issues because I didn't know several facts that the other active contributors knew. This blog post summarizes some of those facts, and I hope it will be useful for other new contributors!

1) The data types LibreOffice code uses -
If you have already browsed through the codebase of LibreOffice, you might have realized that the code doesn't generally use data types like int, float, double, et cetera like we use in small C++ programs. LibreOffice has its own classes, typedefs and structs defined and most of the code use them instead of the trivial data types. Some of those are OUString (instead of string), sal_uInt32 (instead of unsigned int), etc.

2) The CI infrastructure - 
As soon as you send a patch to Gerrit, Jenkins starts to build LibreOffice from your code on several platforms to check whether or not the change you made compiles successfully. Not only that, but it also runs the built software against several test cases and also checks whether or not your code is properly formatted. You are expected to check the output of Jenkins and fix any error it shows. But here's the catch - many of the tests LibreOffice has are flaky - which means the tests might fail even when it isn't your fault. You have to carefully examine the output of Jenkins, and if the error produced is irrelevant to your change, you simply have to rebase your change on the latest commit (which can be done using the Gerrit UI), and wait for Jenkins to build your code again.

3) The directory structure -
Though the presence of a large number of files in the LibreOffice core project might make it difficult for you to search for a particular code, having a knowledge of how the directories are structured might be helpful for you. The following are some important points-
  • Almost all directories have a README file which gives a bit of introduction of what kind of code the directory contains.
  • Many directories have a subdirectory named qa. QA stands for quality assurance and they contain the tests for the code implemented in the same directory.
  • Many directories have a subdirectory named include/inc. These folders contain header files.
  • Many directories have a subdirectory named source. This is the main source code of the directory the README file talks about.
4) The variable prefixing system -
If the file you are working with uses some letters as prefixes in the names of local variables, it'd be great if you use the same prefixes in the patch you send. The prefixes generally denote the data type of the variable. The meaning of some of the prefixes are listed below-


Prefix Meaning
b Boolean
p Pointer
r Reference
n Integer/Numeric Type
c Character
a Anything else

Thursday
14 March, 2019


face

General Activities

  1. LibreOffice 6.2 was released as final on February, 7
  2. Xisco gave a talk about QA at FOSDEM
  3. Mark Hung added support for playing embedded videos in slideshow
  4. Mark Hung fixed an old issue, which prevented Linux users from adding sounds to custom animations in Impress
  5. Balazs Varga (NISZ) keeps fixing OOXML Chart bugs
  6. Miklos Vajna (Collabora) added support for the btLr text direction in Writer.
  7. Szymon Kłos (Collabora) added support for Browsersync integration for Online
  8. Dennis Francis (Collabora) implemented Discrete Fourier Transform in Calc
  9. Martin van Zijl fixed a bunch of old papercut issues, mostly related to selections in Writer
  10. Michael Weghorn did a lot of work on KDE5 & Qt5 file pickers
  11. Katarina Behrens (CIB) and Aleksei Nikiforov (BaseAlt) keep fixing KDE5 issues
  12. Tor Lillqvist (Collabora) continued the work on the new iOS app
  13. Zdeněk Crhonek created nearly 20 UI tests
  14. Andreas Kainz did many updates to the Sifr icon theme along with other UI improvements
  15. Tamas Bunth (Collabora) fixed some Firebird related bugs
  16. László Németh (NISZ) fixed some OLE in DOCX bugs
  17. Bjoern Michaelsen keeps fighting against SwClient
  18. Armin Le Grand and Katarina Behrens (CIB) improved tagged PDF export
  19. Samuel Mehrbrodt (CIB) removed support for Java 5
  20. Heiko Tietze introduced bound to Shift+Alt+Space that inserts a non-breakable narrow space
  21. Tamás Zolnai (Collabora) started to work on MS compatible Forms

Reported Bugs

666 bugs have been reported by 379 people.

Top 10 Reporters

  1. NISZ LibreOffice Team ( 94 )
  2. Telesto ( 23 )
  3. Roman Kuznetsov ( 13 )
  4. Aron Budea ( 12 )
  5. Nicolas Christener ( 10 )
  6. andreas_k ( 9 )
  7. Samuel Mehrbrodt (CIB) ( 9 )
  8. raal ( 8 )
  9. peter josvai ( 7 )
  10. Mike Kaganski ( 7 )

Triaged Bugs

634 bugs have been triaged by 78 people.

Top 10 Triagers

  1. Xisco Faulí ( 109 )
  2. durgapriyanka.arun ( 58 )
  3. Dieter Praas ( 48 )
  4. raal ( 46 )
  5. Oliver Brinzing ( 46 )
  6. Heiko Tietze ( 33 )
  7. V Stuart Foote ( 32 )
  8. Buovjaga ( 29 )
  9. Alex Thurgood ( 22 )
  10. Julien Nabet ( 22 )

Fixed Bugs

158 bugs have been fixed by 49 people.

Top 10 Fixers

  1. Caolán McNamara ( 18 )
  2. andreas kainz ( 6 )
  3. Aleksei Nikiforov ( 6 )
  4. Eike Rathke ( 6 )
  5. Michael Weghorn ( 5 )
  6. heiko tietze ( 5 )
  7. Mike Kaganski ( 5 )
  8. Samuel Mehrbrodt ( 5 )
  9. Miklos Vajna ( 4 )
  10. Katarina Behrens ( 4 )

List of critical bugs fixed

  1. tdf#121532 LO62b1: on macOS local help opens an empty page in default browser ( Thanks to Stephan Bergmann )
  2. tdf#122449 Crash in: mergedlo.dll when closing “Edit Index Entry” dialog (gen/gtk) ( Thanks to Caolán McNamara )
  3. tdf#122643 Crash in: libc-2.27.so after setting Named Ranges to e.g. F:F (non-absolute columns) ( Thanks to Luboš Luňák )
  4. tdf#123320 Writer crash if Paragraph edited after delete of custom Character Style used in Drop Caps ( Thanks to Caolán McNamara )

List of crashes fixed

  1. tdf#123163 CRASH when FILEOPEN of DOCX from scan and Nuance PDF Converter that also can’t be open with MSO ( Thanks to Caolán McNamara )
  2. tdf#123309 GTK3 Chart – crash when change symbol ( Thanks to Caolán McNamara )
  3. tdf#123406 kde5: Crash pressing Esc in undocked Find toolbar ( Thanks to

Friday
01 March, 2019


= Andreas Kainz: GSOC

10:09 UTC

face

It’s time to register to the GSOC programm for the different LibreOffice tasks.

As the notebookbar is available for the regular users I hope to get students how are interested in Improve the LibreOffice notebookbar.

Open tasks are

And of corse there are some open bugs (tdf#102062) and missing uno commands that need to be done.

So join the LibreOffice GSOC project and be part of an open and helpful community.


Thursday
28 February, 2019


face


Image may contain: text
...Because of the official announcement has been published, I had closed my draft article here.

If you are a Japanese speaker, please check the JP team's announcement also.

(Anyway, as above link, now we JP team has our own blog under the TDF domain.  Thank you to everyone in TDF who worked for this!)


Thursday
21 February, 2019


face

As mentioned in my previous such report, a hack week is when we are allowed to hack on anything we want in LibreOffice for a few days at Collabora. I used this time to implement core support for the btLr text direction in Writer.

Motivation

If you work with tables in Word, it’s very easy to create this writing direction: the context menu in a table cell has a menu item to set the direction of the text, where you can rotate the text by 90 degrees counter-clockwise or clockwise. The counter-clockwise btLr direction is the problematic one. Support for tbRl was fine already, since that is needed typically for Chinese/Japanese scripts as well.

Results so far

Here is how the baseline, the current and the reference rendering of btLr text looks like:

https://lh3.googleusercontent.com/o5t6-JQeeNaZpx0YURMvS6xUJv7L4KbkbKnn6VPQ0yzULxHFI15ufkwaw_m0FVY7B2tv8gOnTw1CEY2Uxq6BFTgXHlcorXS52J8X1-mNjsyHKYDmoNG-MQ9X1LtdUWmrLl_W3b2ifQ=w640
Figure 1. btlr-cell.docx, baseline
https://lh3.googleusercontent.com/Y8jXvq7TFyNoKVjwWd_QvJNJaOySZdKZE_HqqBaTwGoi_rExCee3eDAHx4AS49E7d7bcjG8SEgxnXOmdKFXaJx0MzmadungQ7D0SVqdSqC2trMC9InsHdKUTq1iwu5p8bDwUfIizng=w640
Figure 2. btlr-cell.docx, current
https://lh3.googleusercontent.com/KYSBaOiAMdy_U8shsb4zoS8J5uyZzwkFPZY4qIKTrHKlo-M-pCdiHHBUxZ9OmQ-uv_QkBiktXeprTQD6gANDvzDVi8JWs4-Ng2RL-uoMcQCrQNL6Hk7tjXSJBaaqxc2skfZzmepkqA=w640
Figure 3. btlr-cell.docx, reference

You can see how the second paragraph in the cell was missing from the rendered result and now we basically pixel-by-pixel match the reference.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

The document model and UNO API were reasonably straightforward to implement, but the layout was much more challenging. Writer already supported 3 writing directions:

  • typically used for Latin (left to right, top to bottom)

  • Chinese/Japanese (top to bottom, right to left)

  • Mongolian (top to bottom, left to right) text.

This new one is also a vertical direction, also left to right, but bottom to top. The initial layout contained code to read the new enumerator from doc model, extend the SwFrame class to handle this new bottom to top mode, some handling of switching between horizontal/vertical mode and at the end mapping from Writer layout’s direction to VCL’s "900" font orientation. There are more things to handle in layout, but this was good enough to look at other areas as well.

The ODF filter required updating, which was a bit challenging as it was necessary to write different attribute names depending on which enumerator is used from an emumeration, and we don’t have good support for this. Once the filter code was in place, I could write some layout-level tests as well.

Since we have .ui files for UI descriptions, adding UI support was really easy.

Time came to step away from coding for a moment and write up paperwork to propose this feature to be part of the next ODF version (thanks to Andras for the help there!).

Finally I went back to layout, and improved things a bit more: after fixing baseline offsets, the positioning of the text was exactly matching what Word does. How do I know? I used this little script:

gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr.jpg btlr.pdf
gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr-word.jpg btlr-word.pdf
composite -compose difference btlr-word.jpg btlr.jpg out.jpg

Which allows seeing the


face

Firebird Project announces the first Beta release of Firebird 4.0, the next major version of the Firebird relational database, which is now available for testing.This Beta release arrives with features and improvements already implemented by the Firebird development team, as well as with countless bugfixes. Our users are appreciated giving it a try and providing feedback to the development


face

Recently my LibreOffice work is mostly focused on the Online. It's nice to see how it is growing with new features and has better UI. But when I was working on improving toolbars (eg. folding menubar or reorganization of items) I noticed one annoying thing from the developer perspective. After every small change, I had to restart the server to provide updated content for the browser. It takes few seconds for switching windows, killing old server then running new one which requires some tests to be passed.

Last week during the Hack Week funded by Collabora Productivity I was able to work on my own projects. It was a good opportunity for me to try to improve the process mentioned above.

I've heard previously about browsersync so I decided to try it out. It is a tool which can automatically reload used .css and .js files in all browser sessions after change detection. To make it work browsersync can start proxy server watching files on the original server and sending events to the browser clients if needed.

What is the advantage? Developer tools in the browser are not good enough?

  • Changes tracked by git - no need to copy changes from the browser's developer tools to the source files
  • You can setup testing matrix with all apps (writer, calc, impress) and all is reloaded instantly at one time (even on other devices like tablet or smartphone)
  • Fast prototyping

Disadvantages

  • You have to remember to run syntax tests before commiting the changes

To integrate browsersync I needed to do some build system changes. First, all static files are served from 'loleaflet/dist' directory. These files are not the original sources but copies. I modified the Makefiles to create symlinks instead if the browsersync is activated. Thanks to that we can modify sources tracked by git and proxy can detect changes.

To try it out on your own:

  1. Delete your 'loleaflet/dist' folder or
    make clean
    you might need to delete generated 'Makefile' if repository was used before
  2. Install browsersync:
    npm install -g browser-sync
  3. Run 'configure' script with additional --enable-browsersync argument
  4. Run server with:
    LOOL_SERVE_FROM_FS=1 make run
  5. In the other console run browsersync:
    make sync-[writer|calc|impress]
More information can be found in: 'loleaflet/README'

In the video below you can see how it works:

Next step will be to allow browsersync usage with cloud storage integrations like richdocuments, I noticed also some issues with access from other devices (app is still using original server for some resources).


Wednesday
20 February, 2019


face

The paper Mesh: Compacting Memory Management for C/C Applications is about moving memory allocations for compaction, even though the memory pointers are exposed. The idea is to merge allocation blocks from different pages that are not overlapping at page offsets, and then letting multiple virtual…


Friday
15 February, 2019


face

I’d like to share the results of the quick benchmark tests I’ve done to measure the performance of the R-tree implementation included in the mdds library since 1.4.0.

Brief overview on R-tree

R-tree is a data structure designed for optimal query performance on spatial data. It is especially well suited when you need to store a large number of spatial objects in a single store and need to perform point- or range-based queries. The version of R-tree implemented in mdds is a variant known as R*-tree, which differs from the original R-tree in that it occasionally forces re-insertion of stored objects when inserting a new object would cause the target node to exceed its capacity. The original R-tree would simply split the node unconditionally in such cases. The reason behind R*-tree’s choice of re-insertion is that re-insertion would result in the tree being more balanced than simply splitting the node without re-insertion. The downside of such re-insertion is that it would severely affect the worst case performance of object insertion; however, it is claimed that in most real world use cases, the worst case performance would rarely be hit.

That being said, the insertion performance of R-tree is still not very optimal especially when you need to insert a large number of objects up-front, and unfortunately this is a very common scenario in many applications. To mitigate this, the mdds implementation includes a bulk loader that is suitable for mass-insertion of objects at tree initialization time.

What is measured in this benchmark

What I measured in this benchmark are the following:

  • bulk-loading of objects at tree initialization,
  • the size() method call, and
  • the average query performance.

I have written a specially-crafted benchmark program to measure these three categories, and you can find its source code here. The size() method is included here because in a way it represents the worst case query scenario since what it does is visit every single leaf node in the entire tree and count the number of stored objects.

The mdds implementation of R-tree supports arbitrary dimension sizes, but in this test, the dimension size was set to 2, for storing 2-dimensional objects.

Benchmark test design

Here is how I designed my benchmark tests.

First, I decided to use map data which I obtained from OpenStreetMap (OSM) for regions large enough to contain the number of objects in the millions. Since OSM does not allow you to specify a very large export region from its web interface, I went to the Geofabrik download server to download the region data. For this benchmark test, I used the region data for North Carolina, California, and Japan’s Chubu region. The latitude and longitude were used as the dimensions for the objects.

All data were in the OSM XML format, and I used the XML parser from the orcus project to parse the input data and build the input objects.

Since the map objects are not necessarily of rectangular shape, and


Tuesday
12 February, 2019


face

A new edition of FOSDEM (Free and Open source Software Developers‘ European Meeting) just ended. Our CIB LibreOffice team this year was represented by Thorsten Behrens, Michael Stahl and Marina Latini. The event is held annually during the first weekend of February, at the „Université Libre de Bruxelles„. For our team, attending FOSDEM means to be … CIB visiting FOSDEM 2019 weiterlesen

Der Beitrag CIB visiting FOSDEM 2019 erschien zuerst auf CIB events.


face

With the release of 6.2 I read a lot of comments on the different threads. Several issues are listed. One was that Ribbons waste vertical space.

Tabbed toolbar waste vertical space

With default settings the standard toolbar need 110 px vertical space (menubar + 2 toolbar height), tabbed toolbar need 100 px and groupedbar compact 72 px. So the default toolbar need most vertical space.

Toolbar_Vergleich

Difference in height (with GTK3 backend)

  • 110 px for standard toolbar need most vertical space cause the default icon size is 24px (large icons) and you have two toolbars and the menubar
  • 100 px for tabbed toolbar cause the default icon size is 16px (small) and you don’t need an menubar.
  • 72 px for groupedbar compact need the same vertical space than single toolbar.

Yes MSO Ribbons need a lot of vertical space, which is an issue on laptops. Therefore you can show the tabbs only. In LibreOffice we have different UI’s for different workflows, but also for different screen’s. For example on your 32 inch office screen you’d like to work with standard toolbar but on mobile you prefer tabbed compact toolbar (which will be released with 6.3).

On windows the difference between LibreOffice tabbed toolbare and MS Office ribbons is

94 px vs. 110 px

If you like my work, become a downloads_wordmark_white_on_coral2x.jpg

<- Current blog entries