Added something to track the org.freedesktop.appearance.color-scheme property as used by the GNOME 42 Dark Style Preference setting. Screencast recorded with the new iteration of GNOME's screen built-in recorder which is quite snazzy.
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.
Added something to track the org.freedesktop.appearance.color-scheme property as used by the GNOME 42 Dark Style Preference setting. Screencast recorded with the new iteration of GNOME's screen built-in recorder which is quite snazzy.
Have you received “A polite ping, still working on this bug?” message on one of your Gerrit submissions? You can simply send an arbitrary reply to avoid the patch being abandoned within a month. Here we discuss more about Pootle bot, which is one of the QA (Quality Assurance) tools for the LibreOffice QA team to manage old submissions.
You may have received messages from some bots, including Pootle bot. This bot checks Gerrit to find the older submissions, and abandon the old ones that no one actively work on them.
If it has been several months after the last change on a submission, the bot adds a comment and asks:
A polite ping, still working on this bug?
Then, you can do one of these things, according to your choice:
Abandoned
Abandoning this for the moment due to inactivity. Be aware it can be reopened anytime if you still want to continue working on it. Do not forget to rebase it first.
Even in this case, you don’t have to worry! As the message says, you can simply click on the RESTORE button on the top right of the page to restore the patch and continue working on it.
Please note that if you have restored an old submission, you have to do a re-base to get the latest changes in the LibreOffice code, pushed while your submission was remaining intact. If there is not a merge conflict, you can do this easily by clicking on the REBASE button on the top right of the page. Otherwise, you have to download the patch and resolve the merge conflict manually.
You can find more information about
Also, you can read this previous post on how to use Gerrit code review.
The Impress Guide 7.3 has just arrived with the latest LibreOffice Impress 7.3 developments.
This 374 pages book covers the main features of Impress, the presentations (slide show) component of LibreOffice. You can create slides that contain text, bulleted and numbered lists, tables, charts, clip art, and other objects. Impress comes with prepackaged text styles, slide backgrounds, and Help. It can open and save to Microsoft PowerPoint formats and can export to PDF, HTML, and numerous graphic formats.
The Guide update was an effort of Peter Schofield and Kees Kriek.
Peter Schofield
Kees Kriek
Thank you guys for the wonderful Impress Guide!
The full set of published LibreOffice guides is available in the LibreOffice Documentation Website and in the LibreOffice Bookshelf Project.
LibreOffice Conference 2022 will be a hybrid event, both in presence and remote, scheduled for the month of September, from Thursday, September 29th at 9:00AM CEST, to Saturday, October 1st at 1:00PM CEST (https://conference.libreoffice.org/2022/). In addition, there will be a community day on Wednesday, September 28th. The event will be at NOI Tech Park in Bolzano/Bozen (https://noi.bz.it/it), the capital city of South Tyrol, in northern Italy.
All sessions at NOI Tech Park will be streamed live and recorded for download, but it will be possible to present from remote on Friday, September 30th (details will follow). Workshops will be possible only in presence, and should be agreed with organizers in order to schedule them in a specific room (which will be recorded but not streamed).
The Document Foundation invites all members and contributors to submit talks, lectures and workshops for this year’s conference. Whether you are a seasoned presenter or have never spoken in public before, if you have something interesting to share about LibreOffice, the Document Liberation Project or the Open Document Format, we want to hear from you!
Proposals should be filed by July 15, 2022, in order to guarantee that they will be considered for inclusion in the conference program.
The conference program will be based on the following tracks:
Presentations, case studies, and technical talks will discuss a subject in depth and will last 30 minutes (including Q&A). Lightning talks will cover a specific topic and will last 5 minutes (including Q&A).
Please send a short description/bio of yourself as well as your talk/workshop proposal to https://events.documentfoundation.org/libreoffice-conference-2022/. If you want to give multiple talks, please send a separate proposal for each.
Please check if you need a VISA to travel to Italy on this page (available in Arab, English, Russian and Chinese): https://vistoperitalia.esteri.it/home/. If you need a VISA, please get in touch with Italo Vignoli (italo@libreoffice.org) as soon as possible, to get an invitation letter.
If you cannot travel to Italy and prefer to present from remote, please add a note to your talk proposal, in order to allow organizers to schedule your talk on Friday (and organize a test session in advance).
If you do not agree to provide the data for the talk under the “Creative Commons Attribution-Share Alike 4.0 License”, please explicitly state your terms. In order to make your presentation available on TDF YouTube channel, please do not submit talks containing copyrighted material (music, pictures, etc.).
Thanks a lot for your participation!
(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)
LibreOffice’s infrastructure team is responsible for maintaining the hardware, virtual machines and services that enable the wider community to develop, market, test, localize and improve the software. The public infrastructure is powered by around 50 kernel-based virtual machines (KVMs) spread across four hypervisors, plugged to an internal 10Gbps switch, hosted at Manitu in St. Wendel (Germany), and managed with libvirt and its KVM/QEMU driver. The virtual disk images are typically stored in GlusterFS volumes – distributed across the hypervisors – except for some transient disks (such as cache) where the IOPS requirement is higher and the redundancy less important.
As 2021 marked another “pandemic year” with only online events, the infrastructure team helped to make these a pleasant experience from home. Notably, they deployed a Pretalx instance to manage conference submissions and the schedule, and put in place a streaming backend based on Jitsi/Jibri/RTMP during the annual conference, thereby providing several participation options to chose from.
After several months of tests and feedback from the community, the infra team also concluded the migration of LibreOffice’s Q&A platform (“Ask LibreOffice”) to Discourse. Over 65,000 questions and 130,000 replies from 50,000 users — spanning over 17 languages — were imported, with a focus on preserving post attribution and overall layout. The metric collection engines (Matomo as well as the public Grimoire Dashboard) were updated to reflect that change.
Also on the community participation front, the infrastructure team deployed a Decidim instance to structure debate and encourage democratic participation from community members. The instance is currently still under test.
On the Continuous Integration (CI) front, the team deployed new buildbots for Windows and Linux baselines, as well as a buildbot for the WebAssembly (WASM) effort. They also migrated and refactored the bibisect setup to better suit the needs of the quality assurance community.
As for the backends: Debian GNU/Linux 11 (codename “Bullseye”) was released in the middle of 2021, and the team upgraded most of TDF’s virtual machines accordingly during the second half of the year. However, for the lower layers of the virtualization stack, the upgrade is planned for 2022. Furthermore, lots of work was done in planning the restructuring of database engines, most notably around Point-in-Time Recovery; this work was driven by contributor Brett Cornwall. Finally, the team assisted the Membership Committee with the architecture of the back-end side of their new tooling.
Berlin, May 12, 2022 – LibreOffice 7.2.7 Community, the seventh minor release of the LibreOffice 7.2 family, targeted at desktop productivity, is available for download from https://www.libreoffice.org/download/.
End user support is provided by volunteers via email and online resources: https://www.libreoffice.org/get-help/community-support/. On the website and the wiki there are guides, manuals, tutorials and HowTos. Donations help us to make all of these resources available.
For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners, with long-term support options, professional assistance, custom features and Service Level Agreements: https://www.libreoffice.org/download/libreoffice-in-business/.
LibreOffice 7.2.7’s changelog pages are available on TDF’s wiki: https://wiki.documentfoundation.org/Releases/7.2.7/RC1 (changed in RC1) and https://wiki.documentfoundation.org/Releases/7.2.7/RC2 (changed in RC2).
LibreOffice Community and the LibreOffice Enterprise family of products are based on the LibreOffice Technology platform, the result of years of development efforts with the objective of providing a state of the art office suite not only for the desktop but also for mobile and the cloud.
LibreOffice Technology based products for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/, while for App Stores and ChromeOS are listed here: https://www.libreoffice.org/download/libreoffice-from-microsoft-and-mac-app-stores/
LibreOffice users, free software advocates and community members can provide financial support to The Document Foundation with a donation via PayPal, credit card or other tools at https://www.libreoffice.org/donate.
LibreOffice 7.2.7 is built with document conversion libraries from the Document Liberation Project: https://www.documentliberation.org.
So I enabled support for up to 16384 columns in Calc by default some time ago, but just getting it to work was not necessarily the end of the work. Making Calc have 16 times more columns means that any operation that works on entire columns is suddenly 16 times slower, or even worse. Similarly this could easily lead to 16x more memory used. So the support not only needs to work, but it also needs to be usable.
It theory adding a number of empty columns to the end of a spreadsheet should not make a difference, but in practice it does. With 1024 columns it is not as necessary to ignore those empty columns as it is with 16k, and a lot of the code dates back to the times when Calc supported even fewer colums (256?), where a being little inefficient here or there didn't show. But now it suddently did.
For example, if you protect or hide all unused columns until the end of the spreadsheet, then hitting the right arrow key on the last accessible cell makes Calc check all cells to the right for whether it's possible to go into them. And checking whether a column is hidden requires searching the list of column information, which is not trivial (it's compacted in order not to waste memory). The barely noticeable cost of this with 1024 columns got large enough to cause noticeable delays. Fortunately the ColHidden() function is smart enough to return the first and last column in the compacted range where the flag is equal, the code doing the cursor navigation just up until now didn't bother using that information, but now it needed to do so.
Another example, and that's quite a large topic, is allocating columns. If most of those new columns are not actually used, then it makes sense to allocate them only when needed, right? That will save memory, and it will make things faster too, because there is no need to check those empty columns. That idea got implemented back when this 16k work was started by others, adding e.g. function GetColumnsRange() that clamped the range to the allocated columns, but the problem is that in practice this is not as simple as that.
Zdeněk Crhonek (aka “raal”) from the Czech LibreOffice community writes:
The Czech team has finished its translation of the LibreOffice Getting Started Guide 7.3. As usual it was team work, namely: translations by Petr Kuběj, Zdeněk Crhonek and Ludmila Chládková; localized pictures by Roman Toman; and technical support from Miloš Šrámek. Thanks to all the team for their work! The Czech translation of the guide 7.3 is available for download on this page.
Indeed, many thanks to everyone in the Czech community for their work! Learn more about LibreOffice’s documentation project here.
(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)
In 2021, the QA team triaged thousands of bugs, bisected hundreds of regressions, and answered questions from countless bug reporters. As one of the most visible groups directly responding to end users, the QA team must be nimble and able to adapt to changes. In addition, it must deal with specific requests for help from other teams.
The QA team meets regularly on IRC on the #libreoffice-qa channel, which is the best medium for discussing bugs and regressions. The IRC channel provides an excellent opportunity to remain in close contact with team members, and to tutor new members in the art and skill of LibreOffice QA. This is bridged to the Telegram group.
During 2021, 6,804 bugs were reported by 3,022 users, which means 131 new bugs were reported every week on average.
In July 2021, the QA Team organized an online Bug Hunting Session for LibreOffice 7.2. This provided the opportunity for all users, especially those with technical knowledge, to test pre-release versions and provide their feedback in the IRC channel and Telegram group. They were helped to report and confirm bugs, which led to improved stability in the final release.
Also, during 2021, the QA team performed 652 bibisects of regressions.
Learn more about the QA project on this page, and give the team a hand!
LibreOffice is now available for download also on SourceForge
Berlin, May 4, 2022 – LibreOffice 7.3.3 Community, the third minor release of the LibreOffice 7.3 family, targeted at technology enthusiasts and power users, is available for download from https://www.libreoffice.org/download/. In addition to the LibreOffice website, starting from tomorrow it will be possible to download LibreOffice from SourceForge: https://sourceforge.net/projects/libreoffice/files/libreoffice/stable/.
Logan Abbott, SourceForge’s President and COO, says: “We’re happy to add to our open source download library an amazing open source office suite such as LibreOffice, which is without a doubt one of the best office suites ever and one which I personally use often. I highly recommend it to anyone that needs a powerful FOSS office suite.”
The LibreOffice 7.3 family offers the highest level of compatibility in the office suite market segment, starting with native support for the OpenDocument Format (ODF) – beating proprietary formats in the areas of security and robustness – to superior support for DOCX, XLSX and PPTX files.
Microsoft files are still based on the proprietary format deprecated by ISO in 2008, which is artificially complex, and not on the ISO approved standard. This lack of respect for the ISO standard format may create issues to LibreOffice, and is a huge obstacle for transparent interoperability.
LibreOffice for enterprise deployments
For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners, with long-term support options, professional assistance, custom features and Service Level Agreements: https://www.libreoffice.org/download/libreoffice-in-business/.
LibreOffice Community and the LibreOffice Enterprise family of products are based on the LibreOffice Technology platform, the result of years of development efforts with the objective of providing a state of the art office suite not only for the desktop but also for mobile and the cloud.
Products based on LibreOffice Technology are available for major desktop operating systems (Windows, macOS, Linux and Chrome OS), mobile platforms (Android and iOS) and the cloud. They may have a different name, according to each company brand strategy, but they share the same LibreOffice unique advantages, robustness and flexibility.
Availability of LibreOffice 7.3.3 Community
LibreOffice 7.3.3 Community represents the bleeding edge in term of features for open source office suites. For users whose main objective is personal productivity and therefore prefer a release that has undergone more testing and bug fixing over the new features, The Document Foundation provides LibreOffice 7.2.6 and soon LibreOffice 7.2.7.
LibreOffice 7.3.3 change log pages are available on TDF’s wiki: https://wiki.documentfoundation.org/Releases/7.3.3/RC1 (changed in RC1) and https://wiki.documentfoundation.org/Releases/7.3.3/RC2 (changed in RC2). Over 80 bugs and regressions have been solved.
LibreOffice Technology based products for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/, while for App Stores and ChromeOS are listed here: https://www.libreoffice.org/download/libreoffice-from-microsoft-and-mac-app-stores/
LibreOffice individual …
If you have started your journey to become an experienced developer, you already know that you have to describe what you have done when you change the code and submit it to be merged in the master branch. In git and many other source code management systems, this description is called a commit message.
The commit message has a title, and can have a detailed description. You should separate the description from the title by adding a blank line after the title.
Some may argue that the code itself is the most important thing, and you should provide a readable clean code. This is true, and you should care most for the code. But, on the other hand, when you are working on a big project with hundreds of developers, it is also important to write descriptive commit message that is easy to read for other developers who work on the same project.
In order to be able to search and find the relevant historical information about different aspects in the code, a good way would be searching in the commit messages. You can invoke:
$ git log
You can press “/” for search, then type a search phrase. By pressing “Enter”, you will get a match, and then the next match by pressing the key “n”. This happens if matches are found.
This is only possible if you and others have previously provided good information on what each change does, providing enough details and keywords, so that others could be able to search efficiently.
If you have added your changes to the staging area of the git, then you can invoke this command to commit the changes.
$ git commit
You should provide a good title and description. Here’s how.
Git commits also have other information, that are automatically generated. For example, the “Author” field comes from your git settings. You should use your complete first name and surname, and a valid email. Your timezone also comes from your system settings.
The Change-Id is generated when you commit, and it is used to identify a submission across different patch sets. Gerrit adds “Reviewed-on”, “Reviewed-by” and “Tested-by” fields automatically. For example, consider this commit:
Author: Miklos Vajna <vmiklos@collabora.com> Date: Wed Apr 27 20:12:52 2022 +0200 sd theme: add PPTX import for shape fill color effects This is always direct formatting, so FillProperties::pushToPropMap() always has the needed info at hand. Change-Id: I3317b618e0e8bb7688d0f0fbfe4546e2e8b4e947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133525 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
You should describe what you have done in a commit in the commit title. The suggested maximum length for the commit title is 50 characters. Also, you should limit the amount of work in a single commit to only one thing. There are many reasons for that; one of them is to be able to roll back …
Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…
Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
Writer now has the start of content controls: a new way to set properties on a piece of text, primarily for form filling purposes. This feature improves compatibility with the DOCX format: inline content control types "rich text" and "checkbox" are the first two types we can now import.
Word users expect to be able to import their document to Writer and experience a matching feature set: form filling is not an exception. Word provides several content control kinds (inline, block, row and cell content controls), this project focuses on inline ("run") content controls.
In the scope of inline content controls, the plan is to support rich text, checkbox, dropdown, picture and date content controls. This blog post presents the already implemented rich text and checkbox types.
You might wonder why content controls are useful, since Writer already has form controls and fieldmarks, which provide something similar. Here are some properties of content controls, which make them incompatible with field-based fillable forms or form controls:
inline content controls can’t span over multiple paragraphs, while this is allowed for fieldmarks (bookmark-based fields)
content controls must be well-formed XML elements, this allows nesting (while Writer fields can’t be nested), but does not allow the start/end position to be a random place in the document (while this is allowed for fieldmarks, which have separate XML elements for start and end)
content controls just have a set of properties, while fieldmarks are supposed to have a field command and a result (with a separator between the two)
content controls can contain rich text (full set of character formatting), while Writer fields can only have one character formatting (e.g. half of the field can’t be bold)
The feature consists of menu items to insert rich text or checkbox content controls, and then you can interact with the inserted content controls:
Rich text content controls simply show an indicator when you’re inside the content control:
This is similar to input fields, just allows rich text content, not limited to plain text.
Checkbox content controls contain a single character, but you can interact with them: clicking on the content control toggles the checked state of the checkbox:
And these content controls can be saved to ODT and DOCX.
If you would like to know a bit more about how this works, continue reading… :-)
As usual, the high-level problem was addressed by a series of incremental commits:
https://gerrit.libreoffice.org/c/core/+/132291 sw content controls: add document model
https://gerrit.libreoffice.org/c/core/+/132350 sw content …
Boost your skillset and learn new things- join the Month of LibreOffice! The software is a worldwide, community open source project – and many people who help to improve it, actually started out as regular users of the software.
So in the coming four weeks, we’d love it if you get involved, join our community, and have fun. You can build up valuable skills for a future career – and you don’t need to be a programmer. There are many ways to help make LibreOffice awesome, as we’ll see in a moment.
And best of all: everyone who contributes to LibreOffice in the next four weeks can claim a cool sticker pack, and has the chance to win extra LibreOffice merchandise such as mugs, hoodies, T-shirts, rucksacks and more (we’ll choose 10 participants at random at the end):
So, let’s get started! There are many ways you can help out – and as mentioned, you don’t need to be a developer. For instance, you can be a…
We’ll be updating this page every few days with usernames across our various services, as people contribute. So dive in, get involved and help make LibreOffice better for millions of people around the world – and enjoy your sticker pack at the end as thanks from us! And who knows, maybe you’ll be lucky enough to win bonus merch as well…
(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)
Throughout the year, the documentation project closed the gap between LibreOffice major releases, and the updates of the corresponding user guides. By the year end, all of the version 7 guides updated to match the release of LibreOffice 7.2, and ready to continue for the forthcoming release – 7.3 – which arrived in February 2022. The goal of tracking the software release closely was achieved, and the documentation team is now in a steady state of small updates between releases.
The updates and enhancements of the guides was an effort of all the team, coordinated by Jean Weber (Writer and Getting Started Guide), Steve Fanning (Calc and Base guides), Peter Schofield (Impress and Draw guides), Rafael Lima (Math guide). A number of volunteers also worked in each guide by writing and reviewing contents and suggesting improvements. Special thanks to Jean Weber for making the guides available for sale in printed format via Lulu Inc.
In the last quarter of 2021, thanks to The Document Foundation’s budget, some master documents bugs were fixed under contract by Michael Stahl of allotropia, and now the documentation team can safely assemble it guides with master documents, and produce PDFs with hidden sections and correct navigation indexes in PDF readers.
The documentation community also had a nice contribution from Jean Pierre Ledure, Alain Romedenne and Rafael Lima, for the development of the ScriptForge macro library, in synchronization with the much-needed Help pages on the subject, a practice rarely followed by junior developers of LibreOffice. As we know, undocumented software is software that’s lacking; features that are unknown to the user can be a cause of costly calls to a help desk in corporate deployments. ScriptForge developments came together with its documentation, demonstrating the ScriptForge team’s professional maturity.
Special thanks to Steve Fanning for his leadership of the Calc Functions wiki pages maintenance. The wiki pages were initially developed by Ronnie Gandhi in 2020 under the Google Season of Docs programme, and are now run by Steve, providing richer content about the functions, with better descriptions, new examples, and other reference information. The in-depth review of the Calc Function wiki pages gave very good feedback for the Help pages, which also lead to help content improvements. The Calc functions wiki pages are available for translation, thanks to the dedication of Ilmari Lauhakangas at TDF.
Very important as well: the documentation community also had a team of Help page bug fixes, closing Help documentation bugs, bridging gaps, fixing typos and improving quality, a must-have update to keep LibreOffice in-shape for its user base. The Help pages, which are part of the LibreOffice code, were also refactored continuously …
LibreOffice supports many file formats, and among them are some raster and vector image formats from Microsoft. Metafile formats WMF, EMF and EMF+ are among the vector formats usable in Microsoft products, and also in LibreOffice. Here we discuss the implementation of the support for these file formats in LibreOffice.
We call these file formats metafiles, as they are means of storing drawing commands that are calls to the Windows API that draws shapes and text on the screen. It is possible to replay these metafiles to have a graphical output in an appropriate context.
It is possible to create complex shapes using metafiles. For example, if you take a look at the odk/examples/basic/forms_and_controls folder in the LibreOffice source code, you will see some nice examples. Here is one of them: A delicious burger created using vector primitives.
berger.wmf
The oldest metafile format is WMF, which goes back to Windows 3.1 during 1990s, but EMF and EMF+ are newer formats and support many new features.
LibreOffice can open these file formats. It is also possible to use them as the images inside another formats. For example, you can have WMF inside a DOC or DOCX file, or in native ODT format of LibreOffice.
The emfio module of LibreOffice handles reading of the metafile records. It essentially translates these records into the mataactions. Then, vcl and drawinglayer display them. You can take a look at emfio/source/reader to see the main source files, wmfreader.cxx and emfreader.cxx in which rely on mtftools.cxx.
An important class which is used here is the GDIMetaFile class, which is described in the vcl/README.GDIMetaFile.md as:
The
GDIMetaFileclass reads, writes, manipulates and replays metafiles via theVCLmodule.A typical use case is to initialize a new
GDIMetaFile, open the actual stored metafile and read it in viaGDIMetaFile::Read( aIStream ). This reads in the metafile into theGDIMetafileobject – it can read in an old-styleVCLMTFmetafile (back in the days that Microsoft didn’t document the metafile format this was used), as well as EMF+ files – and adds them to a list (vector) ofMetaActions. You can also populate your ownGDIMetaFileviaAddAction(),RemoveAction(),ReplaceAction(), etc.Once the
GDIMetafileobject is read to be used, you can “play” the metafile, “pause” it, “wind forward” or “rewind” the metafile.
Other than reading, LibreOffice can write metafile formats as the output. For the output filter, vcl/source/filter/wmf is the place to look at.
As the metafile formats are binary files, you will need tools to be able to work with these formats. We discuss three useful tools among others: mso-dumper, limerest and mtf-demo.
The mso-dumper is an in-house developed tool created and used by LibreOffice developers to dump information from the Microsoft binary formats. It reads the binary files WMF, EMF, EMF+ in addition to DOC, PPT, XLS and other …
So I've been working on improving LO text layout performance, as specified by the TDF tender. As it says, text layout in LO can be rather slow, because of problems like repeated text layout calls for the same text.
Let's have a look at a perf profile for PDF export of the document from bug#116400 :
There are two major costs here:
The first one is splitting text into script runs (separating runs of e.g. latin text from RTL text). About 61% of time is spent in vcl::text::TextLayoutCache. Which is rather strange for something called 'cache'. But this is one of the cases of poor naming, as the class is actually not a cache, it is the result of the script run splitting. It is called TextLayoutCache probably because callers are supposed to cache it and pass the same item to several OutputDevice calls ... which mostly does not happen. So whenever a text is to be drawn, this gets recreated. To make things even worse, it is done for the entire string, even if only a part of it is drawn, so this supposed cache actually makes things slower.
This can be fairly easily fixed by turning the class into an actual cache. Each TextLayoutCache instance depends only on the string, so it's easy to keep a reasonable number of them in one global cache.
The second problem is breaking text into multiple lines at suitable places. In this case the problem was in the ICU library we use. The common scenario when breaking text is finding the first break and then continuing with the same text to find the following break, and so on. ICU code tries to cache this if the position in the text is close enough to the previous one, and if it's not close enough but after the last position, it tries to only walk back a bit instead of repeating the entire work from the beginning of the string. But for whatever strange reason this walking back didn't work, and it walked back until the very beginning. And the test handling the result of the walking back didn't check what the result was and reset the position to whatever the result was. So in practice the breaking almost always started from the beginning, even if the last position was a way more reasonable place to start breaking from. So 26% of time is spent breaking the same text over and over (and it's only 26% because script run splitting is even more expensive).
I've reported this to ICU together with a suggested fix to not reset position to beginning if the last position is better, they've confirmed the problem, but apparently want to look at why the walking back doesn't work in the first place, and there has not been an actual fix from them yet. So I've at least pushed my patch for now.
The resulting perf profile now …
These days, many C++ projects are built using build tools like cmake and meson in addition to GNU make (gmake). In this blog, I have already written on how to compile and run LibreOffice SDK examples using gmake. Now I want to discuss instructions for compiling and running C++ examples using cmake as the build tool. For the previous instructions using gmake, see this older post:
To be able to compile and run the C++ examples using cmake, you should have installed LibreOffice and LibreOffice SDK, then you should set LOROOT in CMakeLists.txt to appropriate folder. For LibreOffice 7.3 SDK, you should use this line:
set (LOROOT /opt/libreoffice7.3)
Compiling and running the C++ programs would be easy. For some of the examples, you need to run an instance of LibreOffice to listen for the incoming connections. So, you have to invoke:
$ libreoffice7.3 "--accept=socket,port=2083;urp;"
and then just open the project file in Qt Creator (or any other IDE of your choice that supports cmake), and click Build and then Run.
If you have built LibreOffice yourself, use the instdir path for LOROOT:
set(LOROOT = /home/hossein/Projects/libreoffice/core/instdir)
If you use a local build, you may need a running instance of LibreOffice. For this purpose, invoke:
$ ./instdir/program/soffice.bin "--accept=socket,port=2083;urp;"
And execute the project from your IDE.
Here I assume that the project is named example. To build and run the example from the command line using cmake, go to the source folder, and then invoke:
$ mkdir build $ cd build $ cmake .. $ make $ ./example
The CMakeLists.txt file containing the instructions for building the the example project can be as following:
cmake_minimum_required(VERSION 3.5)
project(example LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(LOROOT /opt/libreoffice7.3)
add_executable(example main.cpp)
SET(CMAKE_INCLUDE_CURRENT_DIR ON)
include_directories(
${CMAKE_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}/com/sun/star
${LOROOT}/sdk/include
)
target_link_directories(example PRIVATE
${LOROOT}/program
${LOROOT}/sdk/lib
)
target_link_libraries(example
-luno_sal
-luno_cppu
-luno_cppuhelpergcc3
-luno_salhelpergcc3
-lunoidllo
-lxmlreaderlo
-lreglo
-lmergedlo
)
add_definitions(-DLINUX)
execute_process(COMMAND ${LOROOT}/sdk/bin/cppumaker -Gc -O. ${LOROOT}/program/types.rdb ${LOROOT}/program/types/offapi.rdb)
Essentially, the above file specifies these:
1) Include directories: sdk/include, com/sun/star and also the source directory.
2) Library directories: sdk/lib and program.
3) Name of the linked libraries: -luno_sal -luno_cppu -luno_cppuhelpergcc3 -luno_salhelpergcc3 -lunoidllo -lxmlreaderlo -lreglo -lmergedlo
4) Using cppumaker utility to generate UNO headers from the binary description offapi.rdb. You can read more about LibreOffice SDK utilities in LibreOffice DevGuide chapter 4.
Several environment variables are set when you use the original scripts provided by the LibreOffice SDK. When using cmake, you may have to set these environment variables:
On Linux:
export UNO_PATH=/opt/libreoffice7.3/program export URE_BOOTSTRAP=vnd.sun.star.pathname:/opt/libreoffice7.3/program/fundamentalrc
and …
The motivation here is Use attention-attracting cue when pressing Ctrl+F while in the find bar and do "something" to call attention to the widget. I thought I'd try some of the built-in GTK CSS support. So here we animate the widget to reduce its left and right margins inwards a little and its opacity to 50% before returning to its original properties.
Nothing is ever simple, so in order to repeat the animation (the second time ctrl+f is pressed while the widget has focus) we have to duplicate the animation and use the other copy when the previous copy was last run.
Configuring tables is an every day task for word processors. Most users likely insert a table via menu or toolbar and size the columns per mouse. This usually wont result in a satisfying precision and the table properties dialog would be the next step.…
Any code submission to LibreOffice should pass Gerrit code review in order to get merged into the LibreOffice codebase. This is possible using the code review tool Gerrit.
To understand more, refer to these articles:
For getting started with LibreOffice development in general, watch this video.
Here, I assume that you have read those articles, you have created your account, and you have done your first contributions to the LibreOffice – but you want to know more about how to effectively use Gerrit. This is what I am discussing in this article.
LibreOffice Gerrit
If you are a newcomer, possibly I (Hossein) and Ilmari can help you. You can add us as the reviewers, and we will review your submissions. Just search for our names in front of the “Reviewers” part in your submission, and you can easily add me or Ilmari as the reviewer.
If you want to work on more complicated tasks, you can also refer to this page to find experts in different areas.
We have experts in these areas:
Access2Base, Automated tests, BASIC, Bugzilla, build system (gbuild), Calc, Chart, Database, Debian, adding dictionaries, documentation, Draw, General UI problems, git and Writer RTF filters, gerrit, GUI design questions, headless (–without-x build switch), i18nlangtag, i18npool, Impress presentation, KDE, Libcdr and Corel Draw import, libvisio and Visio import, localization fixes / l10n / non-English bug description, localization fixes / l10n tools, Mac, ODF filter, Pebble, PostgreSQL integration, QA, ScriptForge, Translation, Ubuntu, UI, UNO, sal, configmgr, VCL, Weblate, Wiki, Wiki Extension, Wiki Config, Editing, Windows, Windows Installer, Writer, writerfilter, X11-specific
Quite a lot of topics!
But, as you can read in that Wiki page, please “Please do not email these developers personally with your personal pet bug”. Just add them as the CC or the reviewer of a relevant submission.
Sometimes it happens that Jenkins can not build your submission. This can happen for several reasons. It can be because of a problem in your code, or a problem with the build system itself.
If the problem is from your side, then fix the problem and re-submit your code as a new patch set, and Jenkins will try to build it again.
But, if the problem is with Jenkins, you can either ask on #tdf-infra and someone with appropriate access will resume your build. Another solution would be doing a re-base and then Jenkins will build your submission again. For doing this, you do not need any special permissions.
Please be patient, and keep in mind that CI is a limited resource, so you should use it carefully. Please note that you should build (using make) and test (using make check) on your computer locally before submitting the code to the Gerrit.
Sometimes you want to work simultaneously on multiple submissions. Then, you have to create a branch for each of these submissions to be able to …
Writer now supports what we call clearing breaks: a new property on line breaks which controls where to put the next line in case the line break is at the end of a line which intersects with an anchored object. This feature improves compatibility with the DOCX and HTML formats.
Word users expect to be able to import their documents to Writer and experience high fidelity rendering: this means Writer has to support clearing breaks, which instruct the layout to put the next line after a line break not necessarily at the next available vertical position, but perhaps the next line should "just down" to the next full line, or perhaps just do this partially. (Jump down to the next line, so no anchored object causes an additional indentation on the left or right side.)
The easiest case is the "none" clearing break, i.e. when it’s not actually clearing. This looks like this:
This is just a plain line break, and there are no changes here. It used to look like this in the past as well:
And both match the reference rendering:
Now, what’s more interesting is the "all" clearing break, when the next line is placed in a way that it’s a full line. Figure 1 already shows how it now looks like in Writer. Here is how it used to look like:
Finally you can compare that with the reference:
This is the most interesting case, and Word still provides UI to insert such breaks, so it frequently appears in documents out there. But there are two other cases, still. The "left" clearing break "jumps down", below anchored objects on the left. Here is how it looks now in Writer:
And this is how it used to look like:
Finally you can compare that with the reference:
The last case is the mirror of this, when the "right" clearing break "jumps down", below anchored objects on the right. Here is how it looks now in Writer:
And this is how it used to look like:
Finally you can compare that with the reference:
Other than the layout, there is also user interface for this in both LibreOffice and Collabora Online:
This year’s GSoC is coming; and this year, I suggest that we handle one big problem plaguing LibreOffice: deadlocks.
Users know that sometimes, program hangs. Often that is because of deadlocks. It is well known that one of industry’s most widely used ways to handle this problem is Ostrich algorithm [1].
This proposal is to audit the LibreOffice core code for possible deadlocks, and handle all the found places using the most robust and efficient implementation of Ostrich algorithm. The task includes study of available implementations; the chosen one should be efficient, robust, and available under a compatible open-source license.
Students that choose this task may assume that I would gladly mentor their work on this.
Happy hacking!
So I've updated my Clang to the newly released version 14, and while doing the LibreOffice rebuild afterwards I noticed that it seemed to build faster. I didn't measure it, but the build finished sooner than I expected. So of course I've measured it.
As a simple reference I used my year-old post about Clang 11 building faster with PCH, where Calc'c Library_sc built in 4 minutes and 39 seconds. And indeed now it's faster:
1105.84user 88.35system 2:55.07elapsed 682%CPU (0avgtext+0avgdata 1666576maxresident)k
180904inputs+2272520outputs (41390major+23529938minor)pagefaults 0swaps
Just to make sure it's not something else, I went back to Clang 13 to test it:
1581.76user 93.84system 4:14.75elapsed 657%CPU (0avgtext+0avgdata 1916380maxresident)k
153912inputs+2316696outputs (41891major+27245569minor)pagefaults 0swaps
So yes, it's real, and it's the compiler. It also suggests that there was an improvement also between Clang 11 and Clang 13, although not as noticeable as this.
I have no idea why that is, it seems too big of a difference to be just something random, but I see nothing relevant in the release notes (and it's not DWARF5, I tested that one). I also have no idea if it's a code change or if it's the compiler being faster because it generates faster code and is self-built. But hey, it's nice. I still vaguely remember the times when I was trying to avoid full Calc rebuilds like a plague, but that seems like a long time ago.
We’re continually contributing improvements to the LibreOffice code-base as a member of the community (Collabora Online Forum). Here are a few highlights of the last week’s work on behalf of our customers.
“Collabora is a commercial organisation; of course we serve the needs of our paying customers, but it is a real pleasure to be able to contribute alongside the development community to LibreOffice,” said Michael Meeks, General Manager of Collabora Productivity. “It, not only, helps us offer our customers business values and benefits other companies can’t, but it provides us with an incredibly robust development and support resource.”
There’s a lot going on in the community and here are few current projects that demonstrate what people are hacking.
Enabling Calc support for 16384 columns by default
Over the last couple of weeks Luboš Luňák (Llunak) has been working for Collabora on the 16k columns support in Calc. There’s been a lot of work on this already by Noel Grandin and others, but so far this has been hidden behind the experimental option, and normally documents open only with the “normal” 1024 columns support. The goal of this work is to finish the 16k support stable enough for it to be the default, so that people who need this many columns can finally get them without any complications.
If all goes well, and so far Luboš doesn’t see why it shouldn’t, LibreOffice 7.4 will ship with 16k columns being the default. Calc users will then be able to get a lot more columns to work with.
This work is funded/sponsored by DEVxDAO as part of its mission to support Open Source and transparent research and development of emerging technologies and frameworks. Interestingly finishing this work was also a project that was proposed by to be funded by TDF, and ranked as one of the top requested features, it is great that this budget can now be re-applied to another task.
If you have ever been bitten by the “too many columns” dialog box then, why not find out more about what Luboš is working on.
Word-style border fixes in Writer: pages, tables and paragraphs
Miklos Vajna (vmiklos) has been looking at Writer and how it can better render Word-style borders around pages, tables and paragraphs.
Word users expect to able to import their documents to Writer and experience high-fidelity rendering. This means Writer has to support the way page / table / paragraph borders are painted according to the OOXML model as well. This is all done conditionally, so existing ODF documents are left unchanged.
As a result of this work, Writer now has a set of improvements to better render Word-style borders around pages, tables and paragraphs.
Thanks must go to Docmosis and TUBITAK that have made this work by Collabora possible.
Find out more and take a look at some of the improvements that have been made.
Sparklines in Calc
Sparklines are mini charts available in OOXML (XLSX) documents …
The latest user guides from the LibreOffice documentation team are LibreOffice 7.3 Getting Started and LibreOffice 7.3 Writer, available in free PDF, ODT, or to read in a browser. Low-cost printed copies are available from Lulu.com.
Visit the Documentation page on the LibreOffice website for links.
One of the trending UX features right now is dark mode. According to one study, 58% of Americans experience digital eye strain from using computers. One of the factors causing it is blue light radiation from the screen. That's where the possible idea of a screen that slows down your tired eyes more comes from.
Windows, as one of the biggest consumer desktop platforms, does not escape the dark mode feature. Since Windows 10, dark mode can be enjoyed by its users. Unfortunately, LibreOffice which is on the GNU/Linux platform has remarkable stand at following this trend thanks to its ability to blend in with system themes which has been a bitter pill to swallow over the past few years.
Let's say huge thanks to Caolán McNamara, one of the LibreOffice developers from Redhat who is usually on the UX/UI side of improving LibreOffice integration with GTK, for sending a patch so that LibreOffice for Windows can now enjoy dark mode.
Actually, this article wants to discuss the presence of the dark variant of the Colibre icon theme, but somehow after I sent the dark variant of the Colibre theme patch to the core, Caolán actually fulfilled the expectations of many years later.
Basically, apart from following the interface of the system in which it is installed, LibreOffice supports custom themes via Firefox personas, but unfortunately not all parts of the interface are changed with this Firefox persona. Only the standard toolbar can be themed, while the sidebar let alone the tabbed UI are completely untouched.
Half-hearted theme:
It getting worse with Tabbed UI:
Initially I wanted to make this Colibre variant dark icon theme as a trigger so that the dark mode in Windows is immediately materialized. It turned out that not long after that my wish was granted. To enable it, first thing first you must enable dark mode in OS level, then in LibreOffice, enable experimental features in Tools > Options > LibreOffice > Advanced. Check "Enable experimental feature (may be unstable)". LibreOffice will ask for restart and then automatically switch the UI to dark mode along with Colibre dark icon after restart.
Here is what dark mode looks like on my Windows 11. 
The Start Center looks very promising, the title bar got dark also.