Yes, it has started! Check out the conference website for live streams and more information – and a big thanks to the organisers, sponsors and supporters.
Here’s to a great event 
Ahmed Gamal Eltokhy
Baole Fang
Bayram Çiçek
Björn Michaelsen
Caolán McNamara
LibreOffice Dev Blog
LibreOffice QA Blog
Michael Meeks
Miklos Vajna
Official TDF Blog
Last updated:
September 24, 2023 08:01 AM
All times are UTC.
Powered by:
Imprint
Privacy Policy
Yes, it has started! Check out the conference website for live streams and more information – and a big thanks to the organisers, sponsors and supporters.
Here’s to a great event
LibreOffice Conference 2023 will be hosted by the Universitatea Națională de Știință și Tehnologie Politehnica București, Facultatea de Automatică și Calculatoare (National University of Science and Technology, Polytechnic University of Bucharest, Faculty of Automation and Computer Science) at the PRECIS building from Wednesday 20 September to Saturday 23 Septembe. On Wednesday, the community will gather for the usual community meeting to discuss localisation and marketing activities at the local level. The conference will open on Thursday morning and continue with talks and workshops until Saturday lunchtime (schedule). Alongside this, there will be a technical workshop focusing on LibreOffice development.
The conference is sponsored by Collabora Office and Allotropia (main sponsors), dvloper.io and 1&1, with a significant contribution from The Document Foundation, and the technical support of IT Genetics. The event has been organized by a local team of volunteers, backed by 1&1 and supported by the team at The Document Foundation with the help of local NGOs Rosedu and Tech Lounge. More information on the conference website.
This year, LibreOffice was once again a mentoring organization in the Google Summer of Code (GSoC), a global program focused on bringing more student developers into free and open source software development. Five projects were finished successfully. Students and mentors enjoyed the time, and here we present some of the achievements, which should make their way into LibreOffice 24.2 in early February 2024!
You can experiment with the new features by using daily builds and report any problems in our bug tracker.
Mentors: Thorsten Behrens (allotropia), Heiko Tietze (TDF), Hossein Nourikhah (TDF)
LibreOffice can encrypt documents using OpenPGP public key cryptography by making use of external applications such as gpg4win, GPGTools and gnupg. Thanks to Ahmed’s work, it is now easier to manage and search keys and faster to navigate large keyrings.
Learn more about the encryption experience improvements in the final report.
Mentors: Thorsten Behrens (allotropia), Stéphane Guillou (TDF), Christian Lohmaier (TDF)
This project was inspired by Mozilla’s work on Firefox’s continuous integration. There is now a system in place that makes predictions on the test failure possibility of submitted code changes and decides the most efficient way to build the changes. As this kind of machinery is very new to everyone, we expect many tweaks to follow.
Learn more about the machine learning project in the final report.
Mentors: Andreas Heinisch, Heiko Tietze (TDF)
Searching through options is pretty standard in applications these days, so it is about time LibreOffice learned how to do it!
Learn more about the search feature in the final report.
Mentors: Tomaž Vajngerl (Collabora), Xisco Faulí (TDF)
The idea here was to reduce the dependency on Java during the LibreOffice build process. Half of the tests for Writer were converted.
Learn more about the test conversion project in the final report.
Mentors: Tomaž Vajngerl (Collabora)
APNG is short for Animated Portable Network Graphics. It is not an official extension to PNG, but nevertheless has broad support in web browsers these days. Thanks to Paris’s work, LibreOffice now fully supports this format.
Learn more about the APNG feature in the final report.
Many thanks to all contributors who spent their summer time improving LibreOffice. You are awesome! And special thanks also to the mentors who always put so much love and energy into these tasks. That’s what makes LibreOffice rock.
Now we are looking forward to next year’s GSoC. If you are interested, why not prepare early? Learn more at out wiki page where some ideas are listed.
Participating in GSoC is a great way to build your skills, and show future employers what you’re capable of!
Berlin, September 14, 2023 – LibreOffice 7.6.1 Community, the first minor release of the 7.6 family of the volunteer-supported free office suite for desktop productivity, for Windows (Intel/AMD and ARM processors), macOS (Apple and Intel processors) and Linux is immediately available from www.libreoffice.org/download.
LibreOffice is the only open source office suite for personal productivity which can be compared feature-by-feature with the market leader. LibreOffice offers the highest level of compatibility in the office suite market segment, with native support for the Open Document Format (ODF) – beating proprietary formats for security and robustness – to superior support for MS Office files, along with filters for a large number of legacy document formats, to return ownership and control to users.
Based on the advanced features of the LibreOffice Technology platform for personal productivity on desktop, mobile and cloud, the LibreOffice 7.6 family provides a large number of improvements and new features targeted at users sharing documents with MS Office or migrating from MS Office. These users should check new releases of LibreOffice on a regular basis, as the progress is so fast, that each new version improves dramatically over the previous one.
LibreOffice 7.6 Community Highlights
GENERAL
WRITER
CALC
IMPRESS & DRAW
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.
(PeerTube version of this video.)
LibreOffice for Enterprises
For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners – for desktop, mobile and cloud – with a large number of dedicated value-added features and other benefits such as SLA (Service Level Agreements): www.libreoffice.org/download/libreoffice-in-business/.
Every line of code developed by ecosystem companies for their enterprise customers is shared with the community on the master code repository, and improves the LibreOffice Technology platform.
Products based on LibreOffice Technology are available for major desktop operating systems (Windows, macOS, Linux and ChromeOS), for mobile platforms (Android and iOS), and for the cloud.
Migrations to LibreOffice
The Document Foundation has developed a Migration Protocol to support enterprises moving from proprietary office suites to LibreOffice, which is based on the deployment of an LTS (long-term support) version from the LibreOffice Enterprise family, plus migration consultancy and training sourced from certified professionals who offer value-added solutions and services in line with proprietary offerings. Reference: www.libreoffice.org/get-help/professional-support/.
Indeed, LibreOffice – thanks to its mature codebase, rich feature set, strong support for open standards, excellent compatibility and LTS options from certified partners – is the ideal solution for businesses that want to regain control of their data, and free themselves from vendor lock-in.
Availability of LibreOffice 7.6.1 Community
LibreOffice 7.6.1 Community is available from www.libreoffice.org/download/. Minimum requirements for proprietary operating systems are Microsoft Windows 7 SP1 and Apple macOS 10.15. LibreOffice Technology-based products for Android and iOS are listed here: www.libreoffice.org/download/android-and-ios/.
For users who don’t need the latest features, and prefer a version that has undergone more testing and bug fixing, The Document Foundation maintains the LibreOffice 7.5 family, which includes some months of back-ported fixes. The current version is LibreOffice 7.5.6 Community.
The Document Foundation does not provide technical support for users, although they can get it from volunteers on user mailing lists and the Ask LibreOffice website: ask.libreoffice.org
LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at www.libreoffice.org/donate.
LibreOffice has a database application called Base. It can connect to various database management systems, and is integrated with two internal database engines: Firebird and HSQLDB. Here I discuss how to add catalog and schema support for SQL functions in LibreOffice Base.
SQL window
One can use SQL to create and use internal functions. For example, with Firebird:
CREATE FUNCTION F(X INT) RETURNS INT AS BEGIN RETURN X+1; END;
To run this, you can use “Tools > SQL…”, and then write the above SQL query. To see the result, you need to run this query:
SELECT F(5) FROM RDB$DATABASE;
On the other hand, support for SQL commands is limited. For example, as the issue tdf#95174 describes, SQL parser of LibreOffice parser currently does not handle catalog and schema in function names:
Currently, this command works fine:
SELECT function_name(a, b) FROM C
But this one does not:
SELECT schema_name.function_name(a, b) FROM C
The goal is to make the second one also work in LibreOffice Base.
To add the support for catalog and schema in function names, you should refer to the Yacc rule for the SQL Parer.
Lionel, the experienced Base developer describes what to do in the first comment. In the file connectivity/source/parse/sqlbison.y, you can find this rule
function_name:
string_function
| date_function
| numeric_function
| SQL_TOKEN_NAME
Here, you should add two new cases, like:
| SQL_TOKEN_NAME '.' SQL_TOKEN_NAME
{$$ = SQL_NEW_RULE;
$$->append($1);
$$->append(newNode(".", SQLNodeType::Punctuation));
$$->append($3);
}
| SQL_TOKEN_NAME '.' SQL_TOKEN_NAME '.' SQL_TOKEN_NAME
{$$ = SQL_NEW_RULE;
$$->append($1);
$$->append(newNode(".", SQLNodeType::Punctuation));
$$->append($3);
$$->append(newNode(".", SQLNodeType::Punctuation));
$$->append($5);}
After that, one should invoke this command:
git grep -E '(function_name|set_fct_spec)'
to find parts of the code that use them.
If the code is examining one of the above nodes, it expects a single token at the function_name. The code should be changed to expect a token or a node to handle the schema_name and function_name.
An implementation should be accompanied with a test to make sure that the code actually works, and will remain fine in the future changes. To see other discussed EasyHacks, follow the EasyHacks tag in this blog.
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
478 bugs, 59 of which are enhancements, have been reported by 274 people.
Top 10 Reporters
471 bugs have been triaged by 78 people.
Top 10 Triagers
603 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
215 bugs have been fixed by 35 people.
Top 10 Fixers
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
This post is part of a series to describe how Writer now gets a feature to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the sixth post for the previous part.
The current post features sub-tasks for the multi-page floating table work that is around an explicit table overlap control that Word has (and Writer lacked so far), compatible border rendering of split tables and having footnotes in floating tables, which was not working previously.
Regarding testing, the core.git repository has 60 files now which are focusing on correct
handling of floating tables (filename matching floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where the anchor paragraph of a floating table had some autotext (e.g. "dt", which stands for dummy text), and pressing the relevant shortcut (F3) expands that autotext with the actual content. This includes changing the anchor position of the floating table, which lead to overlapping text. (A multi-page floating table has multiple anchors, we have to make sure we don't set all of them to the new value as-is.)
The next screenshot shows a case where two tables are positioned in a way that they would overlap. Word has a flag that asks the layout to still re-position the second table so the overlap doesn't happen, and now Writer supports this as well.
This screenshot shows a bug where the anchor text on the first page was also duplicated on the second page. Now we properly start the anchor text on the last page of the floating table, like Word does.
What you can see is a floating table that has 2 pages, but simply a split of the table would result in no bottom border on the first page and no top border for the second, like perhaps you would expect it, matching Word. This is now fixed, the layout infers the border style in those cases correctly.
The last screenshot shows a mini-feature: it was possible to float tables and to have footnotes in tables, but not both at the same time. The screenshot shows a case where a floating table is needed, so a specific paragraph is above the table. But we couldn't float the table, because it had a footnote and that would be lost as-is. Now you can have a correct position for that paragraph and the footnote is there as well, at the same time.
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 small changes:
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.2).
Without enough space, one may face data corruption, which is really a terrible thing that can possibly happen for someones important data. In order to avoid falling into such a situation, it is good idea to give warning to the users in advance.
To implement such a feature in LibreOffice, first place to look is this file sfx2/source/doc/sfxbasemodel.cxx.
The method to query the free space method should be added to the sal/osl folder in LibreOffice core source code. To add OS specific code, one may use unx and w32 folders inside it.
Please note that LibreOffice needs to know the disk space on different devices, so passing a vector containing path and free disk space is a good suggestion here.
You should know that guessing the required disk space to save the file is not easy. So, the idea is to have several megabytes free to avoid facing problems. That is in cases the file is not actually very huge. It is possible to add that limit as an option, placed in Tools > Options. These days, even 100-200 megabyte is not that much when comparing it to the very fast disk consumption by different applications like browsers and other similar huge software that people use regularly.
Another nice feature to implement is a handler that runs with low priority every several seconds and checks the available temporary space. That will help avoiding problems with saving images in that specifc temp directory.
One needs to create a test environment to actually test the patch in action. Using a small RAM drive, it is possible to do that. These commands are useful to create a 20 MB partition for testing:
mkdir /tmp/small sudo /bin/mount -t tmpfs -o size=20m,mode=0700,uid=$USER,gid=$GROUP /dev/shm /tmp/small
After invoking the above instructions and filling the disk space, you can invoke LibreOffice with the below command to use temp drive. As a result, you will get the below error message:
No disk space error
But, no warning message is shown when you have some small disk space which is < 1 MB.
$ instdir/program/soffice -env:SAL_USE_VCLPLUGIN=gen -env:UserInstallation=file:///tmp/small /tmp/small/1.pptx
While having < 1 MB disk space, you will get this warning in the terminal, but not when the space is between 1 and 2 MBs.
warn:configmgr:57868:58063:configmgr/source/components.cxx:190: error writing modifications com.sun.star.uno.RuntimeException message: "cannot write to file:///tmp/small/user/nnePqE at ~/Projects/libreoffice/core/configmgr/source/writemodfile.cxx:109"
Please note that both the profile and the opened file were inside /tmp/small.
The above issue is tdf#60909. If you like it, just follow the Bugzilla link to see more information.
To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:
LibreOffice Base is part of LibreOffice productivity suite that makes it possible to work with databases. It is an alternative to MS Access. One of the proposed enhancement for Base is to add a “Find and replace” dialog. Right now, a “Find” dialog is available, but it is not possible to do the replacement with the LibreOffice Base dialogs. This issue is filed as tdf#32506.
This was requested for a long time ago, but until now no developer has put time to make it a reality. This feature request has is a difficutlyIntersting EasyHack, which means it is among the EasyHacks that need more work compared to the difficutlyBeginner and difficutlyMedium ones.
I will describe the details of the task, and if you find it interesting, you can start working on it. Solving difficutlyIntersting EasyHacks is among the criterias for selecting GSoC candidates, so it worth trying if you want to be among next year GSoC candidates.
It is worth mentioning that MS Office provide a comparable functionality in “Find and replace” dialog for MS Access. Thus, it would be helpful for the people migrating from Access to Base.
Enrique, which proposed this enhancement, also provided a design for the “Search and replace” dialog.
Proposed design for LibreOffice Base Find and Replace dialog
As described, this enhancement will be extending the search functionality of Base with the ability to do replacement, which is not currently available from dialogs. It is however possible to use SQL queries to do the replacement. Then, the task would be extending the search dialog, and then adding the required methods that use SQL to do search and replacement.
Lionel, a LibreOffice Base developer, has suggested this path, which I have updated:
The discussed dialog is instantiated in this C++ file
dbaccess/source/ui/browser/brwctrlr.cxx:1798:
pDialog = pFact->CreateFmSearchDialog(getFrameWeld(), sInitialText, aContextNames, 0, LINK(this, SbaXDataBrowserController, OnSearchContextRequest)); pDialog->SetActiveField( sActiveField ); pDialog->SetFoundHandler( LINK( this, SbaXDataBrowserController, OnFoundData ) ); pDialog->SetCanceledNotFoundHdl( LINK( this, SbaXDataBrowserController, OnCanceledNotFound ) ); pDialog->Execute(); pDialog.disposeAndClear();
As the SetFoundHandler() uses OnFoundData, we search the same file for "OnFoundData", and find it in the line 2347:
IMPL_LINK(SbaXDataBrowserController, OnFoundData, FmFoundRecordInformation&, rInfo, void)
{
...
}
This function is called, when a match is found.
The comment above the function SetFoundHandler() describes the idea of “found handler”s:
/** The found-handler gets in the 'found'-case a pointer on a FmFoundRecordInformation-structure
(which is only valid in the handler; so if one needs to memorize the data, don't copy the pointer but
the structure).
This handler MUST be set.
Furthermore, it should be considered, that during the handler the search-dialog is still modal.
*/
void SetFoundHandler(const Link<FmFoundRecordInformation&, void>& lnk)
{
...
}
In the above mentioned file, brwctlr.cxx, this is the start of handler function:
Reference< css::sdbcx::XRowLocate > xCursor(getRowSet(), UNO_QUERY);
This "xCursor" is the form object. The brwctlr.cxx is only for grid (table) controls. For other controls, one should look into svx/source/form/fmshimp.cxx:1544:
SvxAbstractDialogFactory* pFact = SvxAbstractDialogFactory::Create(); ScopedVclPtr<AbstractFmSearchDialog> pDialog( pFact->CreateFmSearchDialog( m_pShell->GetViewShell()->GetViewFrame().GetFrameWeld(), strInitialText, aContextNames, nInitialContext, LINK(this, FmXFormShell, OnSearchContextRequest_Lock) )); pDialog->SetActiveField( strActiveField ); pDialog->SetFoundHandler(LINK(this, FmXFormShell, OnFoundData_Lock)); pDialog->SetCanceledNotFoundHdl(LINK(this, FmXFormShell, OnCanceledNotFound_Lock)); pDialog->Execute(); pDialog.disposeAndClear();
The corresponding OnFoundData is line 2150:
IMPL_LINK(FmXFormShell, OnFoundData_Lock, FmFoundRecordInformation&, rfriWhere, void)
{
if (impl_checkDisposed_Lock())
return;
DBG_ASSERT((rfriWhere.nContext >= 0) && (o3tl::make_unsigned(rfriWhere.nContext) < m_aSearchForms.size()),
"FmXFormShell::OnFoundData : invalid context!");
Reference< XForm> xForm( m_aSearchForms.at(rfriWhere.nContext));
DBG_ASSERT(xForm.is(), "FmXFormShell::OnFoundData : invalid form!");
...
}
And then we can use the form object to implement the required change to fulfill the request.
It is important not to cause troubles with the keys, both foreign keys and primary keys. The idea is to allow find and replace in primary and foreign keys, but then it would be the role of the underlying database engine to see if the replacement is actually possible, or not, and then raise an error message.
Also, it would be the responsibility of the users to make sure that the search and replace they issue is a meaningful one. But, anyway the developer should handle the errors from the underlying database engine.
To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:
LibreOffice is a complex application with a large and growing number of options. It is not easy to find the right needle in the haystack. Like most other complex applications, it will be valuable and useful enhancement to add a search field to the “Tools > Options” dialog that iterates over the various tabs and filters where the search text is found. The Search Field in Options project aims to provide this search functionality in “Tools > Options” page.
GetAllStrings() method to fetch strings from 69 dialogs step by stepsalhelper::Thread - asynchronously)_) and Tilde (~) symbols from fetched strings to make the search function work correctlyDuring 13 weeks GSoC program, I added a search field in Options dialog and included the node names and their .ui strings into searching. Since sub-dialogs under the Options are not initialized at startup of Options dialog, it was not possible to access their .ui strings. To overcome this issue we had two options:
When I felt that Option A is just wasting my time (~5 weeks); I switched to Option B where I can -at least- make some progress. The main issue in Option B was initializing all dialogs which takes about 4-8 secs. I tried to initialize them at background but there was some errors on Win10 that I don’t reproduce the issue on my linux machine. Then I tried to see the errors on Win10 with a virtual machine, but it was too slow to test. Therefore I uninstalled Manjaro/Linux (which I’ve been using it more than 1.5 years) from my computer and had to install Win10 (which I last used 6 years ago) on my machine to see the problems in there. There was some visual inconsistencies while initializing sub-dialogs using salhelper::Thread at background.
After working long hours for weeks meanwhile the time was running out, I decided to initialize almost half of them at Options dialog startup and the remaining ones at the time of searching. In that way, time of initializing process is divided by ~2 which can be acceptable time in some degree in terms of user experience.
There is a single patch on Gerrit for this project: https://gerrit.libreoffice.org/c/core/+/152519. The patch has more than 30 patchsets and includes “+2255 -47” changes.
The most challenging part was implementing GetAllStrings() function for every ~69 dialogs step by step. Current implementation may not be the best solution for user experience, but at least searching through the numerous options is now possible.
Following tasks are left and can be implemented after GSoC:
salhelper::Thread - asynchronously)I’m very happy that we all reached the end of GSoC. During that time, I know that I had a responsibility for doing everything that I can. Therefore I worked hard and tried to complete as much tasks as I can.
I learned a lot of things during the GSoC. Although GSoC is finished, I will definitely continue to contribute to LibreOffice. I am really happy to be a part of the LibreOffice community and Google Summer of Code. I’m really thankful to LibreOffice and Google for providing us this such a great opportunity which helped me gain this amazing experience!
I always tried to be active on IRC #libreoffice-dev channel, and I want to thank for everybody who helped me about my questions.
And most importantly, greatly thankful to Andreas Heinisch and Heiko Tietze who were my mentors throughout the GSoC period. They always guided me everything about my questions. Thank you endlessly for your time and effort. I appreciate that you always motivating and encouraging me in all that I attempt and do. I can never truly express how grateful I am. Your guidance, reviews, help and shared experiences have been invaluable. Thank you very much for everything.
I’d like to express my gratitude to everyone in the LibreOffice community for their help and kindness. They always tried to answer my questions on IRC. I fell very lucky to work with this amazing community. I have learned a lot from you and I will never forget this wonderful experience.
Regards,
Bayram Çiçek
All weekly GSoC reports:
Useful links:
Writer supports Small Caps, but Impress and drawing shapes in general never fully supported Small Caps. The option was available, and the character dialog provided a preview, but Small Caps was rendered the same as All Caps, as seen here.
This has lingered for years and it's not easy as a user to try and manually workaround with varying font sizes because underline/overline/strike-through decorations won't link up, as seen in this example:
to:
Also noticed during all of this was the wrong width scaling used for the red wave line underneath incorrect spelling in impress when the text is superscript or subscript so the line didn't stretch over the whole text, as seen here:
Now corrected as:
and finally added was a missing implementation in the RTF export of shape text to allow the small caps format to be copy and pasted into other applications from impress.
When I wrote Quo vadis with The Document Foundation? a month ago, that was mostly a side product of sorting out my thoughts on open source governance in general, and on LibreOffice in particular. And while that sparked some discussion on the identity of the LibreOffice project, mostly here on Board Discuss, it ultimately was preparation for a talk Thorsten and me had submitted for a vacation on Chaos Communication Camp 2023. Our preparation was somewhat chaotic -- because both Thorsten and me decided to get very creative about the "dont come by car" suggestion by the organizers and our talk being scheduled on the first day of the event -- so we ended up honouring the LibreOffice tradition of finishing slides only hours before the scheduled slot.
The session itself did not seem to have suffered too much by this -- it was more free form, which might actually have been a bonus. We ended up even being allowed to use some extra time for Q&A as there was quite some interest for that in the audience.
The video recording can be found on media.ccc.de and describes both bits of the history of the LibreOffice fork a decade ago and lessons learned that are still relevant for open source communities forking (or otherwise reorganizing themselves) today.
A huge thank you to all the volunteers that made #CCCamp23 (and therefore this talk) happen, especially c3voc for the recording and c3cert who did a great job in checking a minor injury I suffered due to my own stupidity during the event.
Comments? Feedback? Additions? Most welcome here on the fediverse 
!
Thanks to my ‘Search Field in Options’ project mentors Andreas Heinisch and Heiko Tietze for their time and guidance.
A lot of new patchsets submitted (between patchset 10 and 19): https://gerrit.libreoffice.org/c/core/+/152519
We decided to implement Plan B(initialize all strings at Options dialog start-up) instead of “extracting strings at build-time” approach.
all (visible) strings of 69 dialogs included in searching. Currently:
TODO: add accessible-names, accessible-descriptions and tooltip-texts into searching.
GetAllStrings() function returns all visible strings. e.g.:OUString ScTpFormulaOptions::GetAllStrings()
{
OUString sAllStrings;
OUString labels[] = { "label1", "formulasyntaxlabel",
"label3", "label6",
"label7", "label8",
"label2", "label4",
"label9", "label10" };
for (auto& label : labels)
{
if (m_xBuilder->weld_label(label)->is_visible())
sAllStrings += m_xBuilder->weld_label(label)->get_label() + OUString(' ');
}
OUString radioButton[] = { "calcdefault", "calccustom" };
for (auto& radio : radioButton)
{
if (m_xBuilder->weld_radio_button(radio)->is_visible())
sAllStrings += m_xBuilder->weld_radio_button(radio)->get_label() + OUString(' ');
}
OUString button[] = { "reset", "details" };
for (auto& btn : button)
{
if (m_xBuilder->weld_button(btn)->is_visible())
sAllStrings += m_xBuilder->weld_button(btn)->get_label() + OUString(' ');
}
// check button
if (mxCbEnglishFuncName->is_visible())
sAllStrings += mxCbEnglishFuncName->get_label() + OUString(' ');
return sAllStrings.replaceAll("_", "");
}
***
Patch: https://gerrit.libreoffice.org/c/core/+/152519
Project Mentors: Andreas Heinisch and Heiko Tietze (Thanks for their time and guidance)
GSoC project page: https://summerofcode.withgoogle.com/programs/2023/projects/IKtSHIH1
Enhancement request on Bugzilla: https://bugs.documentfoundation.org/show_bug.cgi?id=49895
In large computer displays, it is somehow hard to track the active cell, and the associated row and column. One of the solutions provided to fix this problem is to highlight the row and column. The proposed solution is visible in tdf#33201:
This is requested for a long time, but until now no developer has put time to make it a reality. This feature request has is a difficutlyIntersting EasyHack, which means it is among the EasyHacks that need more work compared to the difficutlyBeginner and difficutlyMedium ones.
I will describe the details of the task, and if you find it interesting, you can start working on it. Solving difficutlyIntersting EasyHacks is among the criterias for selecting GSoC candidates, so it worth trying if you want to be among next year GSoC candidates.
Highlighting the row and column in Calc
One of the contributors have created the above mock-up to show that how the implementation should look like. As you can see, it is somehow similar to a combination of the situations where you select a row, and a column. This can provide an insight on the possible path to the actual implementation. The only difference is that the actual color of the selected cell should be different.
Eike, an experienced LibreOffice developer, suggests that one should look intoScTabView::MarkRows() and ScTabView::MarkColumns(). These functions are called for .uno:SelectRow and .uno:SelectColumn. As described previously, the selected cell should have a different color.
To do the implementation, one should add HighlightOverlay to the OverlayManager. As a similar implementation, SelectionOverlay is updated from InitBlockMode() as ScGridWindow::UpdateSelectionOverlay(), for example like UpdateHighlightOverlay().
Rafael, another active community member, suggests looking into these files, and add a new sdr::overlay::OverlayObjectList to handle the new highlight overlay:
sc/source/ui/inc/gridwin.hxx sc/source/ui/view/gridwin.cxx sc/source/ui/view/gridwin4.cxx
Heiko, the UX mentor for LibreOffice, has mentioned that this feature should be optional. He suggested to use this path in options:
Tools > Options > Calc > View: “[x] Highlight col/row <Blue>
To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
439 bugs, 65 of which are enhancements, have been reported by 254 people.
Top 10 Reporters
461 bugs have been triaged by 73 people.
Top 10 Triagers
551 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
208 bugs have been fixed by 43 people.
Top 10 Fixers
List of critical bugs fixed
List of high severity bugs fixed
Now, the testfailure model no longer considers author features.
LibreOffice 7.6 will be released as final in mid-August 2023 (check the Release Plan), with LibreOffice 7.6 Release Candidate 2 (RC2) the forth pre-release since the development of version 7.6 started in mid December, 2022. Since the previous release, LibreOffice 7.6 RC 1, 100 commits have been submitted to the code repository and 62 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 7.6 RC2 can be downloaded for Linux, macOS and Windows, and it will replace the standard version.
In case you find any problem in this pre-release, please report it in Bugzilla (you just need a legit email account in order to create a new account).
For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Click the banner below to download and test – and thanks for testing!
…
Previously, jenkins only uses testfailure results to decide whether the patch will pass or fail. Since it is not very accurate and testselect is accurate, a better algorithm using its prediction is used to pass or fail a patch.
testoverall is proposed to integrate testselect’s predictions into testfailure. Compared to testfailure, its failure recall significantly increases from 54% to 71%, while pass recall slightly drops from 70% to 65%. Since failure recall is much more important than pass recall, the model is a huge improvement.
Due to testoverall outstanding performance, it replaces testfailure in inference.
Besides, a new condition is added to decide whether the patch should pass or fail. Originally, it only looks at whether the overall failing probability has reached a threshold (0.4). Now, the number of failed unit tests are counted. If it reaches the threshold (10), then the patch is also considered to be failed. With the improved algorithm, the inference is able to recall 91% failures, while reducing computation by 57%.
Currently, the model is integrated into Jenkins job gerrit_master_ml. It first runs the machine learning model to predict whether the patch will pass or fail. If the patch is likely to fail, then the fast track will be run. If it is likely to fail, then the normal build will be run.
Writer now has continued steps to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the fifth post for background.
The previous post finished with an "almost done" state for overlapping tables: this is a cluster of problems where tables are allowed to overlap, but various other formatting make them not overlap in practice in Word, but they do overlap in Writer. In this post, we'll see what was necessary so an initial set of old documents now render perfectly, which started to work during the past month.
The feature is enabled by default and the DOCX/DOC/RTF import makes use of it.
On the positive side, core.git repository has has 49 files now which are focusing on correct
handling of floating tables (filename matching floattable-|floating-table-). Also, there are
additional tests that quickly build a specific multi-page floating table in the memory and do some
operation on it, e.g. delete the last row and assert what happens.
Here are some screenshots from the fixes this month (right click, open image in new tab for larger size):
The first case is about a document where the bottom of the page had a floating table, where the position (relative to the anchor) was a negative vertical offset. In this case Writer used to move the floating table to the next page, but now matches Word: the space in the previous page is used for the floating table. This fixed overlapping text on the next page.
The next case is about floating tables in footnotes, the anchor needs to have no visible margins to provide the correct layout.
This case was about an unwanted overlap of floating tables. Incorrect handling of the vertical offsets meant that the second floating table was rendered on top of the first one, making the text in the first floating table unreadable. Now we shift down the second floating table, so no overlap happens.
This document had a layout loop on load. The problem was specific to the case when the anchor text of a floating table started with a newline character, which has its own position in the document model, but doesn't really have a width at a layout level, so needs special handling. This is now fixed, the document loads and renders fine.
This document had only 4 pages, but lots of floating tables, carefully positioned to not overlap in Word. You can see how the old Writer rendering result was hard to read and it now looks correct.
Writer used to hide floating tables anchored inside hidden paragraphs, but Word shows them all the time, now we match this behavior.
The next document first had all of its tables in the first page, now fixed.
A remaining problem was that the second table and the footer area could still overlap. This is now fixed: Word sometimes does allow such an overlap, but it depends on the baseline of the anchor position, so in the current case we can detect that such an overlap is not wanted.
The last problem with this document was a poor split of the floating table, the first half row of the second table still went to the first page. Now we correctly detect that such a split is not wanted and simply start the second floating table on the second page, which results in a pretty good rendering of this document.
And that's where we stand. Certainly more work is needed to fix rough edges, but we get there step by step -- the theme is slowly transitioning from overlap problems right after load to unexpected rendering problems during editing.
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 small changes:
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (7.6).
If you have ever tried to build LibreOffice code, you know that it can take a lot of time. LibreOffice has ~6 million lines of C++ and some Java code (<280k). But, there are tools that can help you build LibreOffice from source code much faster, if you do it repeatedly! Here I discuss how to use one of these tools: “ccache”.
Even with a fast computer, compiling huge amount of C/C++ code takes a lot of time. Compiling 6 million lines of C/C++ code in LibreOffice will take you several minutes (if not hours) with a decent computer with fast CPU and a lot of RAM.
But, people who work on developing LibreOffice need to build it from the source repeatedly. Because only a fraction of the code changes each time, there is a big chance that one can re-use the compiled objects, and that’s where ccache (and similar tools) come in. It caches the compiled objects, and before trying to re-compile the code, searches inside the cache to see if a previously compiled objects are usable.
The caching mechanism speeds up the process a lot, so that instead of for example 1 hour, you get a full re-build in 5 minutes or so, depending the speed of your machine, if everything is untouched. In case files are changed, you may wait more, but eventually a lot less than the previous build time. Please note that this 5 minutes build is on my machine, so you may have longer (or even shorter time) on your system, depending on the hardware, OS, etc. that you are using.
You have to install ccache binaries on your platform to be able to use it. On Linux, you may install it through the distribution package manager. On macOS and Windows, you have to get the binaries from ccache github release page.
Please note that on Windows, there is also a ccache binary from the Cygwin that is not useful. You have to get the binaries from the Github to get reasonable speedup.
The speed up is not as good compared to Linux, but I could reduce the compilation time from 30 minutes to 18 minutes, which helps considerably when you do LibreOffice development. Some developers have reported that using PCH is faster compared to using ccache on Windows.
There are other tools for speeding up the build beyond ccache. For example, icecream is a distributed alternative for ccache.
Also, pre-compiled headers (PCH) are useful to reduce the build time. Please have in mind that combining PCH and ccache/icecream might not always be possible on each and every platform. PCH usage is described in TDF Wiki article, building LibreOffice on Linux:
Precompiled headers:
Passing--enable-pchtoautogen.shenables use of precompiled headers (PCH), which reduce build time at the expense of more disk space and more source files possibly rebuilt when a header changes. The option has several levels (system, base, normal, full), the higher level the higher possible gain but also disk space usage and chance for larger rebuilds on changes.
If you like further optimizing the build time, this LibOCon 2022 presentation by Luboš Luňák can be interesting for you:
"Where do you want to go today?"
At the Document Foundation -- the entity behind LibreOffice -- the board is currently considering introducing a staff policy, and is asking for ideas, comments and feedback.
tl;dr: Starting from the foundations statutes and organizational setup, I will be pointing out some easy to make common mistakes (some literally lost in translation) in finding the foundations core values. I believe only with that, a constructive discussion of how trustees, board and staff of the foundation can improve their interactions and alignment. I also made a concrete proposal on board-discuss to start a discussion on possible concrete measures there -- this post provides the more abstract background going along with that.
There seems to be quite some confusion about how the different bodies of the foundation should interact with each other. The different bodies being:
To summarize as short as I can: The trustees are those who contributed to the projects of the foundation and thus gain active voting rights. The membership committee has been elected by the trustees to be the judges on those contributions: they decides who is and will continue to be a trustee. The board of directors is elected by the trustees too. This grants them special privileges and duties: The most important privilege is to control the foundation resources, consisting mainly of two groups: funds created from donations and salaries to pay staff. While staff or directors not being trustees is possible, for the most part they are likely privileged trustees: Unlike other trustees staff are paid for their contributions and directors can allocate the foundations resources.
Now, one might think both the board and the staff are purely bound by the statutes of the foundation and their conscience. However, for directors this is clearly not the only limit on their decisions, at least if they want to be reelected by the trustees again. For the staff, there are also limits: The directors -- who have the duty to control the resources of the foundation need to be convinced that spending donations on staff salaries is the best use for the goals of the foundation as set in the statutes and understood by the trustees.
Now, the foundation is older than a decade by now and its goal are both quite broad and ... partially outdated. This makes "statutes and conscience" alone not a good guideline to achieve focused progress. What to focus on?
As a starting point, lets have a look at the preamble of the foundations statutes, which starts with this paragraph:
The objective of the foundation is the promotion and development of office software available for use by anyone free of charge. The foundation promotes a sustainable, independent and meritocratic community for the international development of free and open source software based on open standards.
This is one of the shortest possible descriptions of the foundations goal. And even with this it requires some explanation and amendments:
The second paragraph is mostly redundant: It clarifies what "office software" means ("repertoire ... of tools") and what "open source" means ("openly available for free use") and also talks about "distribution" ... which is a bit funny as software distribution mostly stopped being a problem quickly even while foundation was created: even Canonical stopped shipping Ubuntu CDs in 2011 and today everyone can distribute software of epic sizes via Docker hub or quay.io or ghcr.io.
Ok, so ... the first paragraph of the statutes of the foundation (mostly the second sentence) are a great starting point to define the goals of the foundation. Good! Does this mean using this as a first principle means trustees, board members and staff are aligned and focused on the same goal? Unfortunately not.
Even with the extensive comments given above, the goals of the foundation are so broad compared to the resources of it, that they will never ensure alignment by themselves -- much less an strong focus and effective effort. Do not get me wrong: Compared to other open source NGOs, the Document Foundation is quite rich -- but its goals are still overwhelmingly broad and diverse. Is this a problem? In a way, yes: It means two trustees can work on the goals of the foundation and still consider the work of the other ... not that important.
Between volunteers that might be somewhat acceptable: who is to judge contributions of others if they were volunteered? But with both directors and staff its ... different. Both have been trusted by the other trustees with additional privileges: The staff with the privilege to be -- unlike others -- to be paid for their project contributions. The directors are mostly graced with the privilege allocate funds (which ultimately includes staff salaries). So both directors and staff need to answer to a higher standard than other volunteers (who are judged by the membership committee). And here is where a need for alignment and focus comes in.
And that brings me back to the opening of this post: staff policy. I wonder if transparency about the focus, alignment of goals and allocation of resources (namely: funds and work time) would be helpful when it allows:
This alone would not solve all problems with alignment, but it would be a start. One medium to bring about such transparency could be Objectives and Keyresults (OKRs).
How would OKRs help at TDF? Well, OKRs should generally be set in a way that they are assumed to be on average 70% complete by the end of the period. Evaluation at the end of the period will allow to:
A concrete draft proposal for how that could be implemented has been suggested here.
Comments? Feedback? Additions? Most welcome here on the fediverse !
(*) Urgh, long footnote incoming on why I will leave aside discussing these latter two hot button topics in this post as (in summary):
To improve model performance, the model based on grouped unit tests is implemented. Originally, the model is trained to predict on the level of around 700 unit tests, which is too much. To reduce the number of predictions, unit tests are grouped into 80 groups based on their folder parents and functions in mapping.py. The performance has improved to:
| Fail (Predicted) | Pass (Predicted) | |
|---|---|---|
| Fail (Actual) | 3860 | 203 |
| Pass (Actual) | 191593 | 1109768 |
testselect is now able to recognize 95% (94% previously) of all failures, while reducing computation by 85% (84% previously).
To mark the occasion of Noel's merge of Convert internal vcl bitmap formats transparency->alpha to align LibreOffice's internal concept of color opacity with everything else's.
This work, "Urgent VCL Mission", is adapted from "Urgent Mission" by Randall Munroe, used under CC BY-NC 2.5, and licensed under same by me.
Amazingly there exists, not one, but two fonts based on Randall's handwriting.
Onward and upward to the end of split-Alpha.
Every time Jenkins runs the model, the inference results will be saved to probability.csv, which is archived by Jenkins.
The model is integrated into a master job. In this job, the model will first be run to decide whether the commit is likely to fail. If it is, then run gerrit_linux_clang_dbgutil first. If it fails, then return -1, else run the rest builds. If the model predicts that the commit is unlikely to fail, then run all the build in parallel like before.
by Popa Adrian Marius (noreply@blogger.com) at July 16, 2023 11:28 AM
by Popa Adrian Marius (noreply@blogger.com) at July 16, 2023 11:26 AM
by Popa Adrian Marius (noreply@blogger.com) at July 16, 2023 11:12 AM
LibreOffice 7.6 will be released as final in mid-August 2023 (check the Release Plan), with LibreOffice 7.6 Release Candidate 1 (RC1) the third pre-release since the development of version 7.6 started in mid December, 2022. Since the previous release, LibreOffice 7.6 Beta 1, 354 commits have been submitted to the code repository and 151 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 7.6 RC1 can be downloaded for Linux, macOS and Windows, and it will replace the standard version.
In case you find any problem in this pre-release, please report it in Bugzilla (you just need a legit email account in order to create a new account).
For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Click the banner below to download and test – and thanks for testing!
…
Currently, the model is integrated into Jenkins. The average build duration is around 15s, and it is able to support 5 builds in parallel.
Its output log mainly contains the probability of a patch to fail a unit test and its overall probability to fail any test. The overall probability is shown in the build summary page.
| Imprint Privacy Policy | |
|
The Document Foundation is not responsible for the content on planet.documentfoundation.org. However - if you have any concerns about content please contact Uwe Altmann for moderation. Copyright information: Unless otherwise specified in the author's blog, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). |
|